Re: Warnings, RFC 1522, and ISO-8859-1

Martin J. Duerst:
>
>On Mon, 16 Dec 1996, Koen Holtman wrote:
>
>> Martin J. Duerst:
>> >
>> >Hello Koen,
>
>> >> The TEXT encoding was US-ASCII in HTTP/1.0 (RFC1945),
>> >
>> >Not true. RFC1945 explicitly allows octets from character sets
>> >other than US-ASCII (which means octets with the 8th bit set).
>> 
>> Yes, but it does not tell you how to interpret octets with the 8th bit set.
>> So the bottom line is that you can depend on US-ASCII and nothing else.
>
>If that's the bottom line, why was the ISO-8859-1 default introduced?

US-ASCII is the bottom line for HTTP/1.0.  I told you before that we
introduced ISO-8859-1 in HTTP/1.1.  Different protocols, different defaults.

[...]
>> I'm not an expert on this small draft business, but I think it will be
>> difficult to have a small draft which changes HTTP/1.1 semantics (instead of
>> just adding to semantics or clarifying semantics) without also having a
>> procedural delay.  I believe it is ultimately up to the IESG, though.
>
>If that is a problem, there is an easy way out: We just don't tell
>the IESG about the changes we want to make until after the big
>HTTP/1.1 is out.

I don't think we are allowed to do that.  It would be kind of dishonest
anyway.

Look, it all boils down to procedural matters.  HTTP/1.1 is at a procedural
stage where we do not want to change it anymore.  It does not really matter
that the change would be trivial.  Trivial changes which reverse design
choices are not permitted if delays are to be avoided:  only huge bugs may
be fixed.

We may also add notes like "This Warning header is a very bad example of how
to do i18n; please avoid constructs like this in future protocols, and do X
instead", but we cannot change the mechanisms in the spec itself.

> Anybody know any more details?

See RFC1602.

[...]
>In an earlier mail, you have mentionned that there is always
>a new version. Now you say that stability is more important.

The stability of the 1.1 document is important at the current stage.  People
are implementing it now, and we don't want these people to tear up code they
have already written because the document changed.  This is why the
procedure does not allow changes.

>If you cite stability already at this point, won't you stress
>it much more when the issue will be raised again when going
>to a new version?

No, absolutely not.  I'm against it for 1.1 because of procedural issues.
If people want it in 1.2 or 2.0 or NG or whatever, that would be fine with
me.

>Regards,	Martin.

Koen.

Received on Wednesday, 18 December 1996 00:41:32 UTC