Subject: I-D ACTION:draft-brezak-spnego-http-00.txt

From: Garrett Wollman <[email-masked]>
Date: Tue, 25 Sep 2001 12:27:26 -0400 (EDT)

<<On Tue, 25 Sep 2001 11:11:10 -0400, [email-masked] said:

> This document describes how Microsoft\306s Internet Explorer 5.0 and 

This announcement continues a disturbing trend of MicrosoftSCII
appearing in what are supposed to be ASCII text documents.  It's
particularly egregious in this announcement, since there is no
Content-Type header indicating in what character set the \306 should
be rendered.  (In my system's default encoding, it's a capital
ae-ligature.)  The document itself also contains \373 characters as
well (seen as u-circumflex).

-GAWollman

---

From: Stephen Casner <[email-masked]>
Date: Tue, 25 Sep 2001 12:25:52 -0700 (PDT)

On Tue, 25 Sep 2001, Garrett Wollman wrote:

> appearing in what are supposed to be ASCII text documents.

I've observed this disturbing trend also.  Triggered by the formatting
problems and non-US-ASCII characters of a different draft, on Friday I
sent a message to the I-D administrator asking if she (and other
powers that be) would you be willing to institute a policy that draft
submissions that don't conform to the formatting guidelines would be
rejected.  My suggestion would be to provide a little program that
would look for these illegal characters and check the number of
characters per line and lines per page, and tell report whether the
submission passes or does not pass.  Alternatively, if the only
problem was the illegal quote and dash characters, it could simply
replace them.  [But one thing that puzzles me about these characters
is that sometimes they are in the range \221 - \227 where they appear
in the Windows character map and don't conflict with ISO-Latin-1, and
other times they are like \364 and \366 for double quotes which could
conflict with valid ô and ö characters in someone's name.]

She thanked me for my suggestion, but seemed not to be interested in
my offer to supply the format checking program.

I have a couple of questions regarding format policy:

  - Are unpaginated drafts acceptable?  I think they probably should
    be (and have been accepted in the past) because I-D's are supposed
    to serve for quick proposals as well as finished documents.  But
    if a draft does contain pagination, then it should be limited to
    58 lines as in the I-D guidelines and RFC 2223.

  - Is it accurate that I-D's and RFCs are supposed to contain only
    the US-ASCII (7-bit) character set?  Or are we supposed to allow
    for ISO-Latin-1 characters in people's names, etc.?  I thought I
    saw a document somewhere that answered this question (and said
    US-ASCII only), but RFC 2223 only says "The character codes are
    ASCII" which may not be specific enough.  The difficulty with
    allowing anything other than US-ASCII is that there is no place
    for a character set indication to go (this normally is placed in a
    MIME header, for example, and there is none on a plain text
    document).

I also noted that the I-D guidelines page itself does not conform to
the formatting requirements, with some lines much longer than 72
characters.  I provided a rejustified version, which might find its
way to the web site eventually.
							-- Steve

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Sep 2001 16:39:14 -0700

>my offer to supply the format checking program.

hmmm.  would not be difficult to have a "submit this file as an I-D" web 
page, which would do the checking automatically and forward the file to the 
I-D czar.  If it became popular, I suspect they would be glad to have it 
work from the I-D page.

>     be (and have been accepted in the past) because I-D's are supposed

Strongly agree.

>     58 lines as in the I-D guidelines and RFC 2223.

yes.

>     ASCII" which may not be specific enough.

There are many unprintable characters that are, nonetheless, US-ASCII.  We 
probably need to be more precise about legal/illegal.

Equally, it is clear that the strongly international quality to the IETF 
requires permitting at least SOME encoding of non-ASCII.  As you note, at 
least being able to encode a person's name properly would seem more than 
appropriate.

>   The difficulty with

Well, actually, we do have some techniques available, for inline encoding 
of brief strings.  They are ugly, but they work.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: stanislav shalunov <[email-masked]>
Date: 25 Sep 2001 20:31:50 -0400

-----BEGIN PGP SIGNED MESSAGE-----

Dave Crocker <[email-masked]> writes:

> Equally, it is clear that the strongly international quality to the
> IETF requires permitting at least SOME encoding of non-ASCII.

I would say that to the contrary, the strongly international nature of
IETF (with different default character sets, different sets of fonts,
various national conventions, etc.), dictates using a lowest common
denominator of US-ASCII for the documents (in much the same way that
diversity of computing environments encourages plain text documents).

> As you note, at least being able to encode a person's name properly
> would seem more than appropriate.

The "proper" encoding of my name is óÔÁÎÉÓÌÁ× ûÁÌÕÎÏ× (in KOI8-R; the
Russian language has at least four character sets in active use).  Can
you read that?  I thought so.  That's why I write it in US-ASCII in
English-language documents (such as I-Ds).

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Beware of Programmers who carry screwdrivers.    -- Leonard Brandwein

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Sep 2001 17:51:16 -0700

>English-language documents (such as I-Ds).

Let me be more explicit about the ability to encode names.

Having an ASCII reprsentation is important, for the reason you 
demonstrate.  This is merely the standard argument in favor of ASCII for 
IETF documents.  That benefit is far too strong to challenge, nevermind change.

However, there is no harm -- and there is some benefit, if only as a matter 
of courtesy -- in permitting you to ADD a string that can be decoded to 
your native form.

The only issue is HOW.

d/

----------

---

From: [email-masked]
Date: Wed, 26 Sep 2001 01:45:28 -0400

> least being able to encode a person's name properly would seem more than 

If we're allowing non-ascii, it has to be able to encode the string:
Valdis Kl=?iso8859-4?Q?=BA?=tnieks  (or utf-8/unicode/etc equivalent).

Yes, 8859-4, not -1.  I'm getting tired of "solutions" that only work
for 8859-1, or for only one 8859-X at a time. ;)

This however *does* raise a ettiquette/stylebook question:

My mail software is able to deal with 2022-encoded text, and I've often
gotten mail that starts off with:

On Wed, 5 Sep 2001... <kanji or kana string here> said:

Now, that *displays* just fine for me, but I have to admit being unable
to look at a string of kanji and decide "recognized name" or "never heard
of this person before" the way I can for roman-based names.  Do we
want to encourage those whos names are non-roman-based include a roman
transliteration for the linguistically challenged, or do I need to
just learn how to deal?

This is probably a different aspect of how to downgrade for those of us
who dont have supra-ASCII display ability.  For instance, the problematic
character in my name is an 'e' with a short horizontal bar over it -
I've gotten used to having it smashed to an ascii 'e'.  I admit having NO
idea what to do for those of us who use Cyrillic, or Hebrew, or Arabic,
or Kanji, etc....

/Valdis (who knows full well this sort of thing is why we decided on ASCII
the *last* time this issue came up ;)

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Sep 2001 16:34:27 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Stephen" == Stephen Casner <[email-masked]> writes:

    Stephen> I've observed this disturbing trend also.  Triggered by the formatting
    Stephen> problems and non-US-ASCII characters of a different draft, on Friday I
    Stephen> sent a message to the I-D administrator asking if she (and other
    Stephen> powers that be) would you be willing to institute a policy that draft
    Stephen> submissions that don't conform to the formatting guidelines would be
    Stephen> rejected.  My suggestion would be to provide a little program that

...
    Stephen> She thanked me for my suggestion, but seemed not to be interested in
    Stephen> my offer to supply the format checking program.

  I too would like to see such a policy.

  Perhaps it has to come from the IETF Chair.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [