W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1998

Re: non-ascii user name & password

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Fri, 25 Sep 1998 21:02:20 -0700
To: Chris Newman <Chris.Newman@innosoft.com>
Cc: http-wg@hplb.hpl.hp.com
Message-Id: <9809252102.aa22491@paris.ics.uci.edu>
>> How do you think the average
>> user will feel about all of his current password-enabled services being
>> broken just to support a potential mismatch between system charsets?
>
>Programs that rely on private agreements to interoperate deserve to break
>(and occasionally do break in practice).

Yes, they do. That doesn't change the definition of the protocol.  
The username and password were defined as ISO-8859-1 when the 
authentication fields were invented and deployed.  Except for the
usual charset politics, that definition worked just fine.

>I know in email protocols the IETF has held a hard line and never
>permitted unlabeled 8-bit text in a standard.  Is there something about
>http that justifies breaking this precedent?  What do other people think? 
>Is this a case where correct international interoperability has to be
>sacrificed due to the localized private-agreement installed base?

In email protocols, specifications that contrast with reality have
traditionally been ignored by almost all developers and resulted in
interoperability failures when some poor sap actually attempted to comply
with the RFC.  HTTP does not allow that.  HTTP has a version number 
whose minor number is supposed to change whenever compatible changes
are introduced, and a major number that is supposed to change whenever
incompatible changes are introduced.

I have no problem with defining a new protocol in the HTTP family that
cures the hundred-odd problems leftover from the installed base and
eventually progresses on the standards track.  I have a huge problem
with such a protocol masquerading as HTTP/1.x when we have carefully
designed the protocol for forward compatibility.  The problem is that
the IETF standards-track process interferes with good protocol design
by not allowing progress along delineated branches.

It is high time that the IETF started thinking in terms of protocol
families and planning for evolution rather than making standards
decrees and hoping the installed base gets sucked into the void.

....Roy
Received on Friday, 25 September 1998 21:04:45 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:24 EDT