Re: ISO/IEC 10646 as Document Character Set

>I'm not arguing for 2022.  If it were up to me, I'd specify UTF-8 as
>the default.

I think that would be unacceptable to the Europeans.  Latin-1 and UTF-8
are incompatible.


>1. We need language in the RFC that specifies what to do in the default
>case that the CHARSET parameter is not present in the Content-Type response.

I'm happy with a default of iso-8859-1, but with additional hand-wavy
wording saying something like:

  NOTE: Some servers omit the charset parameter even though the document
  is not in iso-8859-1.  This behavior is considered non-conforming, but
  implementors should be aware of this fact.


>Alternatively,
>give the user the option of choosing between a number of default encodings.

This is exactly what Netscape 1.1 does.  However, we are not happy with
this.  We want people to use the charset parameter (or equivalent).


>I recall quite clearly when the ARPANET converted from NCP to TCP/IP.  I
>was the host manager at a site which had 4 hosts connected to the ARPANET
>(that was a large number of connected hosts in those days).
>The way it worked is that a date was decided as the cutoff date for
>switch over; if you didn't have TCP/IP up by then you were just out of luck.

Things have changed since then.  The net is much larger.  I think many
people now believe that cutoff dates don't work.

For evidence, just look at MIME.  It was designed very, very carefully
to be compatible with the current email infrastructure because many people
in the working group believed that cutoff dates wouldn't work.

If I'm not mistaken, TELNET or FTP also introduced new features by
negotiating.  ESMTP is also SMTP plus negotiation, I think.  I'd be
surprised if the Next Generation IP group was contemplating cutoff
dates in the sense you mention above.


Erik

Received on Wednesday, 3 May 1995 20:25:28 UTC