ietf-822
[Top] [All Lists]

Returned mail: User unknown

1991-09-28 06:21:50
   ----- Transcript of session follows -----
550 hansen(_at_)pegasus(_dot_)PEGASUS(_dot_)COM(_dot_)(_dot_)(_dot_) User 
unknown

   ----- Unsent message follows -----
Received: by pegasus.com (5.51/PEGASUS-2.2)
        id AA22615; Sat, 28 Sep 91 02:44:10 HST
From: 
humu!(_at_)att(_dot_)att(_dot_)com:owner-ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Received: from att.att.com by humu.nosc.mil (5.61/1.35)
        id AA26913; Sat, 28 Sep 91 02:09:36 -1000
Received: from att by att.att.com; Sat, 28 Sep 1991 08:11 EDT
Received: by att.att.com; Sat Sep 28 08:10:24 EDT 1991
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) 
        id AA22374; Sat, 28 Sep 91 07:05:06 EDT
Received: from CBROWN.CLAREMONT.EDU by dimacs.rutgers.edu 
(5.59/SMI4.0/RU1.4/3.08) 
        id AA22370; Sat, 28 Sep 91 07:04:58 EDT
Received: from HMCVAX.CLAREMONT.EDU by HMCVAX.CLAREMONT.EDU (PMDF #11000) id
 <01GB3O8F5K0CAJKKRN(_at_)HMCVAX(_dot_)CLAREMONT(_dot_)EDU>; Sat, 28 Sep 1991 
04:04 PDT
Date: Sat, 28 Sep 1991 04:04 PDT
Original-From: "Ned Freed, Postmaster" 
<NED(_at_)hmcvax(_dot_)claremont(_dot_)edu>
Subject: Re: New-ish idea on non-ascii headers
To: Craig_Everhart(_at_)transarc(_dot_)com
Cc: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Message-Id: <01GB3O8F5K0CAJKKRN(_at_)HMCVAX(_dot_)CLAREMONT(_dot_)EDU>
X-Vms-To: IN%"Craig_Everhart(_at_)transarc(_dot_)com"
X-Vms-Cc: IN%"ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu"
Content-Type: text
Content-Length: 5985

I've been sitting on this reply for a while since the discussion of this stuff
had been replaced with a discussion of whether we should be having this
discussion ;-), but rather than lose it entirely I figured I'd better post it
now. Please keep in mind that this is an open issue that does NOT have to reach
closure for RFC-XXXX.

Craig Everhart writes:

Even if you disagree about mnemonic, you cannot possibly make this case
stick with quoted-printable. Quoted-printable will decrease the use of
special RFC822 quoting unconditionally, and if it is adopted I plan to
use it just for this reason!

Doesn't quoted-printable start its special sequences with the special
character ':'?

A colon is not an RFC822 quoting character. It is special only in that it
cannot appear in an atom. You do not have to do anything special to a colon to
use it in a quoted string. Unless you're going to claim that RFC822 handlers
are so broken that they cannot parse quoted strings of _any_ kind properly? If
so, well, I'm afraid I don't have much sympathy for them. There is a certain
miminal functionality I have to expect of all operational systems. Handling
quoted strings falls into this class. While you can argue that handling

  "\"\\\"\""

is problematic, I claim that the handling of

  ":0A"

is not.

Of course we could always change the quote character to one that could appear
in an atom. I don't think this is a useful thing to do, however.

I've already addressed this in previous messages -- please read them.

Could you offer a simple reminder to those of us who are making honest
attempts to remember?  I have indeed followed this list.  My short-term
memory doesn't go back 5 megabytes.  I honestly don't remember this
point being driven to closure.

This point has not been driven to closure, which is precisely my point! But I
did examine in detail what parts of an RFC822 header should be covered by
mnemonic and which should not. I put forth a proposal. I will recap it now. The
parts of an RFC822 header I see as being possible candidates for mnemonic
encoding are:

(1) Entire lines that contain unstructured information.
(2) Certain instances of quoted strings. Specifically, quoted strings
    in phrases that appear before a route-addr. The Keywords: header
    should also be looked at.
(3) Comments.

Of these, the first is the easiest to deal with, and I don't think there is any
real problem with mnemonic encoding for them. The only headers of this type I
could identify are Comments: and Subject:. Since then someone added
Content-Description:. That's fine with me!

The second is a little harder to deal with. John Klensin has pointed out that
some mailer use the phrase before the routing address as an active part of
the address. Keeping in mind that this model is fundamentally broken, and
also that there's nothing that's going to force you to use these new
extensions, I don't think this particular piece of brokeness is worthy 
of our concern. This is an engineering assessment, of course -- others may
feel differently about it.

I don't think Keywords: is a major problem, but the big users of this
one are people dealing with NetNews. Would any of the NetNews folks care to
comment on this?

The third case is one that I originally thought would work, but you pointed
out, correctly, that comments may be inserted by a routing MTA that may know
nothing about encodings. Keeping in mind that mnemonic is a display methodology
only, and thus does not imply any loss of functionality if someone who's not
aware of what's going on does insert something that does not jibe with mnemonic
usage. Sure, something may get displayed incorrectly, but I just don't see this
as a major problem. We live with this problem now, given that we have all sorts
of messages floating around in national variant character sets that for me have
| and { and } characters in them. I don't think this is what the users of
these variants intended ;-)

In other words, if a comment gets inserted that happens to contain a character
that triggers improper display, so what? They are comments, after all. A
comment has to be considered to be even less active, protocol-wise, than a
phrase in front of a routing-addr.

On the other hand, we can avoid this problem quite easily by not modifying the
display of comments in any way. I'm presently leaning to the "let's not change
the display of comments" position, since I don't think it is as essential as
other things. People that use comments instead of phrases for their names in
messages may have a problem with it, however.

Note that we can pick an unlikely character as the mnemonic sequence
introduction character, and this will go a long way towards solving the
problem. My choice would be &. I don't see this character much in comment
strings.

I'll summarize. I propose that we adopt a standard header that tells use what
character set has been used in the "headers" and what encoding has been applied
to this character set. I further propose that mnemonic with an introductory
character of & be the character set/encoding of choice, but that (at least) the
8859-X variants also be allowed, and the use of a different intro character
should be allowed. (10646 is out of it for me until there's some sign of
closure in the area. Preliminary results from a working group are not closure.)

By "headers" I propose that this apply to the Subject: header, the Comments:
header, and the Content-Description: header. The NetNews folks may wish to list
additional headers -- I want to hear that from them. It will also apply to the
phrase before a route-addr (as defined in RFC822). It will not apply to RFC822
comments.

As I recall, this discussion (header encodings) resumed as you
complained that nobody had responded to an old ``position paper''
message you sent.  You have your discussion.  Is it wrong to ask for a
recap?

Well, now we have a recap, and a discussion can ensue.

                                Ned


<Prev in Thread] Current Thread [Next in Thread>