headers
Bjoern Hoehrmann | 1 Feb 2012 05:11
Picon

Re: RE: Encoding charset of HTTP Basic Authentication

* David Lee wrote:
>What shocks *me* is that the intent of base64 is stated to allow more
>characters then HTTP headers allow but then due to the lack of
>encoding/charset specification allows precious few.
>A lot of work for almost nothing.  A simple insertion of the text "UTF8
>encoded prior to base64" would have nailed it.

The distinction between bytes and characters is a fairly recent develop-
ment. When I bought my first computer in the 1990s it came with Windows
3.11 and MS-DOS 6.22, and the german versions of those use different
"code pages", meaning plain text files with Umlauts that I created in
DOS did not work right under Windows and vice versa.

Some years later when I got an Internet connection at home I chatted
with an egyptian girl living egypt over ICQ. She wanted to send me a
letter and asked for my address, and she asked about the characters in
my name and address and I tried hard to explain umlauts and that I use
"oe" in my "nickname" as transliteration... and eventually I got her
letter containing mojibake where the umlauts should have gone.

It's not something that was wired into people's heads at the time, and
we are still suffering from that. If I put my proper name into the From
header I will without a doubt see my name mangled in replies or online
archives shortly after. Heck, in back in 2004 I filed comments on W3C's
Character Model for the World Wide Web specification, developed by the
I18N Working Group there, through an online form they developed, and my
name came out as mojibake in the list archive where the comments were
copied to.

Note that this is in part due to missing infrastructure, in the DOS/Win-
(Continue reading)

Permalink | Reply | 30 comments |
headers
Michael Kay | 1 Feb 2012 09:39
Favicon
Gravatar

Re: RE: Encoding charset of HTTP Basic Authentication

 >The distinction between bytes and characters is a fairly recent 
development. When I bought my first computer in the 1990s it came with 
Windows 3.11 and MS-DOS 6.22, and the german versions of those use 
different "code pages"...

In the Computer Science Tripos at Cambridge University they always used 
to ask a few open-ended questions, and I remember one from the early 
1970s along the lines "Why is character encoding such a difficult thing 
to get right?" Forty years on, getting it right hasn't become any easier.

However, I think any student answering that question would have been 
expected to understand the difference between characters and the bytes 
used to represent them.

Michael Kay
Saxonica

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
(Continue reading)

Permalink | Reply | 29 comments |
headers
Tei | 1 Feb 2012 12:22
Picon
Gravatar

Re: RE: Encoding charset of HTTP Basic Authentication

On 30 January 2012 15:44, David Lee <dlee <at> calldei.com> wrote:
> Were back to the problem that SSL doesn't solve the problem (today)  it was
> originally intended to solve.   But it happens to solve *this* problem (as
> long as you ignore the fact that both ends may be insecure - in which case
> all bets are off).
>
> But yes the crux is that Authentication in pure HTTP is either insecure or
> hard.
> That's just the way it is (as far as I know).
>
> <rant>
> This is why a particular annoyance of mine is the false-sense-of-security of
> CA signed certificates.
> If browsers didn't put up an ugly warning about how scary a self-signed
> certificate was then more people would use SSL and the internet would be
> more secure.
> But if you use plain HTTP you don't get a warning - just insecurity.
> Why is it like this ? My only guess ... "Follow the money ..." ?
>
> </rant>
>

Security conscient people seems to not like this idea, because MITM
attacks are easy with selfsigned certs.

Then recently some rogue certificates where generated, for google and
other domains.   The next time you pay something with Paypal, you
could be using some mitm Iranian server, or perhaps some CIA server.

For two years USA was reading Megavideo CEO emails. So storage is
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Lee | 1 Feb 2012 12:50

RE: RE: Encoding charset of HTTP Basic Authentication

===> Tei sez 
Security conscient people seems to not like this idea, because MITM
attacks are easy with selfsigned certs.
<====

Of course its not perfect, practically nothing is.
But my point is using SSL with self-signed certificates is more vastly more secure than using HTTP with
plain text. But the browsers give a Horrendously scary warning if you use SSL with self-signed
certificates and say nothing at all for plain text HTTP (except the lack of a microscopic lock icon).
This leads many (most?) web site developers to just stick to plain HTTP.  Thus decreasing security overall
I simply don't understand that.

-David

----------------------------------------
David A. Lee
dlee <at> calldei.com
http://www.xmlsh.org

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lee | 1 Feb 2012 13:08

RE: RE: Encoding charset of HTTP Basic Authentication

Agree with Michael.
Character encoding is *not* a recent problem.  It may still be hard, but its
not recent.  Back when I was getting my Amateur Radio License (1970ihs?) I
remember a strong petition to the FCC to try to allow amateur teletype to
use ASCII instead of BAUDOT.  'Everyone' knew IBM machines used EBCIDIC ...
(and lets not talk about Morse Code, an early multi-bit character encoding).
Even those old DOS boxes had 'CodePages'.    People talk about DOS a lot but
really most of the early internet machines were Unix.    Of course Unix (now
Linux) still doesn't solve character encoding issues very well.    

Encoding still is a hard problem but I can't accept that Ignorance was the
cause of it missing from the HTTP specs. 

----------------------------------------
David A. Lee
dlee <at> calldei.com
http://www.xmlsh.org

-----Original Message-----
From: Michael Kay [mailto:mike <at> saxonica.com] 
Sent: Wednesday, February 01, 2012 3:40 AM
To: xml-dev <at> lists.xml.org
Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication

 >The distinction between bytes and characters is a fairly recent 
development. When I bought my first computer in the 1990s it came with 
Windows 3.11 and MS-DOS 6.22, and the german versions of those use 
different "code pages"...

In the Computer Science Tripos at Cambridge University they always used
(Continue reading)

Permalink | Reply | 28 comments |
headers
Tei | 1 Feb 2012 15:44
Picon
Gravatar

Re: RE: Encoding charset of HTTP Basic Authentication

On 1 February 2012 13:08, David Lee <dlee <at> calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.

--

-- 
--
ℱin del ℳensaje.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Permalink | Reply | 27 comments |
headers
David Lee | 1 Feb 2012 15:53

RE: RE: Encoding charset of HTTP Basic Authentication

But the funny thing is that ASCII wasnt what the browsers and servers actually implemented typically it was ISO-8859-1

Oh well the past is the past.
Now we just have to pile on higher to reach higher

----------------------------------------
David A. Lee
dlee <at> calldei.com
http://www.xmlsh.org

-----Original Message-----
From: Tei [mailto:oscar.vives <at> gmail.com] 
Sent: Wednesday, February 01, 2012 9:44 AM
To: xml-dev <at> lists.xml.org
Subject: Re: [xml-dev] RE: Encoding charset of HTTP Basic Authentication

On 1 February 2012 13:08, David Lee <dlee <at> calldei.com> wrote:
...
>
> Encoding still is a hard problem but I can't accept that Ignorance was the
> cause of it missing from the HTTP specs.
>

Using ascii was a adecuate solution. Solved the problem at the time,
for the people that needed a solution. Maybe not for everyone forever,
but that can be solved by new protocols.

--

-- 
--
ℱin del ℳensaje.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Richard Salz | 1 Feb 2012 16:01
Picon
Favicon

Re: RE: Encoding charset of HTTP Basic Authentication

> > Encoding still is a hard problem but I can't accept that Ignorance was 
the
> > cause of it missing from the HTTP specs.

Nobody really questioned the belief that "netascii" was required for 
maximum interop.

You want to call that Ignorance, go ahead.  I'd just say "we didn't know."

        /r$

--
STSM, WebSphere Appliance Architect
https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Permalink | Reply | 17 comments |
headers
Michael Kay | 1 Feb 2012 16:21
Favicon
Gravatar

Re: RE: Encoding charset of HTTP Basic Authentication

On 01/02/2012 14:44, Tei wrote:
> On 1 February 2012 13:08, David Lee<dlee <at> calldei.com>  wrote:
> ...
>> Encoding still is a hard problem but I can't accept that Ignorance was the
>> cause of it missing from the HTTP specs.
>>
> Using ascii was a adecuate solution. Solved the problem at the time,
> for the people that needed a solution. Maybe not for everyone forever,
> but that can be solved by new protocols.
>
Well, for some of the people that needed a solution, anyway.

More to the point, the Europeans were locked in debate over ideal 
standards like X.400 and ODA that solved every requirement under the 
sun, while the Americans just hacked together something that worked; and 
most of the Americans had never met anyone with an umlaut in their name. 
Cheap and cheerful won the day, and we are all still paying the price.

Michael Kay
Saxonica

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe <at> lists.xml.org
subscribe: xml-dev-subscribe <at> lists.xml.org
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mukul Gandhi | 1 Feb 2012 16:54
Picon

Re: Creating Context-Dependent Data Models

Hi Roger,
   Nice examples.

Here are possibly two more approaches that may be possible for this
use case (these are XSD 1.1 specific). Both of these use the wild-card
element to specify variable nature of the content, and restricting the
content possibilities via assertion.

a)

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

     <xs:element name="suitcase">
	    <xs:complexType>
		   <xs:sequence>
		         <xs:any minOccurs="3" maxOccurs="3"/>
		   </xs:sequence>
		   <xs:assert test="deep-equal(*/name(),
('shorts','Hawaiian-shirts','sunglasses'))
		                                or
					    deep-equal(*/name(), ('dress-shirt','tie','jacket'))"/>
		</xs:complexType>
	 </xs:element>
	
	 <xs:element name="shorts" type="xs:string" />

	 <xs:element name="Hawaiian-shirts" type="xs:string" />

	 <xs:element name="sunglasses" type="xs:string" />
(Continue reading)

Permalink | Reply | 0 comments |

Gmane