Subject: [EAI] Minutes from Chicago - first draft

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Aug 2007 20:37:42 +0200

Thanks to Andrew Sullivan for these very well-written minutes.

Comments ASAP, please!

           Harald Alvestrand
_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 15 Aug 2007 14:17:51 +0100

> Thanks to Andrew Sullivan for these very well-written minutes.

OK, a few remarks.

    e. DOWNGRADE is in a reasonable state, but there are issues to
    discuss (in particular, "unknown header" handling, multiple
    Downgrade: headers, and downgraded no-Alt cases)

Agreed. I raised a host of minor issues, but they are mostly accepted by  
the editor. Main thing needed is clear explanation of how to downgrade  
message/utf8smtp (and maybe even message/rfc822).

    b.  If DSN cannot be delivered on the next hop, then what?  there
    are three options: 7 bit, downgrade, or discard.  Eric Allman
    observed that it is important not to make downgrade an implicit
    requirement, because it's possible not all implementations will do
    downgrade.  Some remarks to the effect that detailed design in the
    meeting is not a good idea.  After considerable discussion, the
    Chair asked for a hum on the suggestion that downgrading was off
    the table, but that some versions of encoding are possible.  There
    was a noticeable response in favour, and silence opposed.

But discard is also highly undesirable (especially as there is usually no  
Return-Path to send it back to). So downgrade it has to be.

   b.  There remains an issue with UTF8 addresses with no alternate.
    There were previous suggestions merely to bounce the mail, but that
    seemed unsatisfactory, which is why there has been a suggestion for
    group syntax.  The editor asked for feedback.  General sense seemed
    to be that MUAs would not mishandle empty groups, and that the
    important thing was not to require too complete behaviour lest the
    feature be completely unimplemented.

Yes, I like the group syntax idea, as in the latest downgrade draft.

   c.  Unknown header fields discussion.  There seem to be two
    options: either a field is processed as Downgrade: [old field], or
    it gets a special Downgraded-* prefix for every field.  The
    room seemed to converge on documenting the problem and moving on,
    but no clear statement seemed to garner clear support.  the Area
    Director pointed out that, to the extent this issue impinged upon
    DKIM, it would need to be addressed, though he did not have a
    recommendation on how to proceed.  The Chair observed that
    Downgrade: fieldname: value received no remarks in favour, but
    Downgrade-fieldname: value was preferred by 7 participants.

I much prefer 'Downgrade: fieldname: value', which is essentially what we  
have had in our drafts all along. I dislike the idea that new header field  
names can be invented 'on the fly', or that the form of a header field  
name should itself convey any semantic information. And all valid header  
field names are now supposed to be registered with IANA as soon as they  
are invented, which means that every existing header field name will now  
require a matching Downgrade-* to be registered for it.

9.      Working Group timeline

    a.  The Chair plans to issue a 2-week Working Group Last Call on
    SMTP, UTF8, and DSN in August.  If that goes well, it should be
    possible to go to the IESG in September.  WGLC for Downgrade in
    September, going to the IESG in October.  Then remaining additional
    drafts can be discussed in the December meeting in Vancouver.

The four 'core' documents UTF8, SMTP, DSN and DOWNGRADE are all so  
dependent on each other that it would be unwise to submit them to the IESG  
other than as one complete package to be considered together.

I agree that the others could follow later.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 15 Aug 2007 10:21:28 -0400

> >Thanks to Andrew Sullivan for these very well-written minutes.

[. . .]

Just to be clear, your remarks were on the _content_ of the minutes,
and not the _accuracy_?  If the latter, I don't think I understood
what alterations you thought were needed.

A

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Aug 2007 19:03:32 -0400

--On Wednesday, 15 August, 2007 14:17 +0100 Charles Lindsey
<[email-masked]> wrote:

>...
> I much prefer 'Downgrade: fieldname: value', which is
> essentially what we have had in our drafts all along. I
> dislike the idea that new header field names can be invented
> 'on the fly', or that the form of a header field name should
> itself convey any semantic information. And all valid header
> field names are now supposed to be registered with IANA as
> soon as they are invented, which means that every existing
> header field name will now require a matching Downgrade-* to
> be registered for it.

Harald, I don't know if putting more of the discussion into the
minutes is worthwhile, but, at least for Charles's information...

Charles, just to explain the other point of view, there are a
number of MUAs that don't like duplicate field names in the same
set of headers.  If one has a legacy MUA, "Downgrade: From:" is
not different from "Downgrade: To:".  It is, instead, either a
pair of syntax errors ("field-name: atom: ..." is unusual
although not actually prohibited) or two duplicate/redundant
header fields named "Downgrade:".  If the MUA canonicalizes the
information, and many do, there is considerable risk that 
   Downgrade: From: stuff
   Downgrade: To: otherstuff
will either be turned into 
   Downgrade: From: stuff [,] To: otherstuff

or...
all Downgrade: header fields will be dropped entirely, since
there would be no rule for how to create the union (e.g., in the
above, whether to put in that comma or not) 
or...
the MUA will choose one of them to retain (most likely the first
or last one) and discard all of the others.

Since none of those are good options and not being able to
predict which one would be chosen is not predictable across
MUAs, some of us ended up being persuaded that "Downgrade-foo:"
was the better choice despite sharing your misgivings and
distaste about that form.

     john

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 16 Aug 2007 08:41:34 +0200

John C Klensin wrote:
>> .
If you think something was said at the meeting on this point, please 
suggest words so that we can get it into the minutes. I'd like to have 
the minutes reflect what was discussed - but we can't add that much 
explanation if that explanation didn't occur in the meeting.

And Charles - if you want to discuss the issues rather than the minutes, 
CHANGE THE SUBJECT LINE!

                  Harald

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 17 Aug 2007 17:21:48 +0100

On Thu, 16 Aug 2007 21:49:13 +0100, John C Klensin <[email-masked]> wrote:

Oops! I replied to John only instead of to the list. So I am repeating the  
whole of his reply here, with my added comments.

> --On Thursday, 16 August, 2007 13:10 +0100 Charles Lindsey
>> On Thu, 16 Aug 2007 00:03:32 +0100, John C Klensin
>> <[email-masked]> wrote:
>>
>>> number of MUAs that don't like duplicate field names in the
>>> same set of headers.
>>
>> Well such MUAs are clearly non-compliant with the existing
>> standard (e.g. RFC 2822 specifically allows multiple instances
>> of several header, such as Comment, Keywords, Received, and
>> all of Resent-*; and RFC 822 allowed even more). So I have
>> little sympathy with a man who uses a non-compliant agent and
>> then finds it does not work.
>
> If I recall, 2822 also provides a model for combining multiple
> forward-pointing address headers and prohibits their use.

It provides a method for a few specific headers, for use when interpreting  
obs-syntax only. Evidently some MUAs have implemented this (which is fine,  
and might even be useful when generating Reply-to-all and the like). But  
it seems some of them apply it to other headers for which it is  
inappropriate :-( .

>  Also,
> among the above, Received and Resent-* are considered trace
> headers and hence fall into a special category, leaving the
> somewhat dubious for processing purposes and rarely-used Comment
> and Keywords headers.  The question is what happens with
> something unknown and that is, well, unknown... not a violation
> of the spec.  There is also the little matter that 2822 doesn't
> specify what MUAs do, only what the headers and format are.

But there is nothing in RFC 2822 which says that multiple occurrences of  
the same header are disallowed, except for cases where it explicitly says  
so. Therefore they are allowed. The headers we are talking about here come  
under the classification of optional-headers so far as 2822 is concerned.
>
>>> ...  If one has a legacy MUA, "Downgrade: From:" is
>>> header fields named "Downgrade:".  If the MUA canonicalizes
>>> the information, and many do, there is considerable risk that
>>>    Downgrade: From: stuff
>> Actually, there might be some mileage in making that the
>> official form of the header. The only problem would be to find
>> a delimiter sufficiently unlikely to occur within a header in
>> its own right. Something like
>>
>>     Downgrade: ----
>>         From: stuff ----
>>         To: stuff ----
>>
>> where the first '----' defines the delimiter that will be used
>> in the subsequent lines (a little bit like the 'boundary' in
>> multiparts).
>
> You may think that is a good idea.  If so, we will probably have
> to agree to disagree.  FWIW, note that we need to assume that
> any MUA receiving a downgraded message will itself have never
> heard of those headers -- in any form or syntax-- so that
> syntactic tricks aren't going to help it much.  There will be
> exceptions, of course.

An MUA which refuses to display an unknown header, even when the user  
requests to see "all headers", is severely broken. But any such agent that  
declines to show the "Downgrade:" header I have proposed would equally  
decline to show any of the "Downgrade-Foo" headers that you prefer. So  
that argument is neutral as between the two proposals.

As to whether such an agent would be kind enough to display in decoded  
form any RFC 2047 stuff it encountered in such headers, that too would  
presumably happen, or not happen, under both proposals. It does not matter  
that such agents will not recognise delimeters such as "----". The most  
one can expect such agents to do is to display these headers in a form  
that the reader can read.

Only agents extended following our drafts would be able to use those  
headers in order to do full upgrading (that would include extended POP and  
IMAP systems, of course). The only disadvantage I can see with my proposal  
is that the position of the original pre-downgrade headers in the header  
section will be lost, so the upgrade mechanism will not be able to  
reproduce the original headers in their original order.
>>> MUAs, some of us ended up being persuaded that
>>> "Downgrade-foo:" was the better choice despite sharing your
>>> misgivings and distaste about that form.
>>
>> My dislike of Downgrade-foo is less than my dislike of
>> non-compliant systems, so count me still in favour of our
>> current Downgrade header (unless my delimiter hack above can
>> be made to work).
>
> You had best register this comment on-list.  Telling me doesn't
> help very much, especially since I was just trying to report on
> the conversation in this subject in and around the meeting
> rather than trying to strongly advocate a position.

Indeed. That comment is now on-list, and hence also on-the-table.