Re: [EAI] Minutes from Chicago - first draft

["Charles Lindsey" <chl at clerew.man.ac.uk>]

On Tue, 14 Aug 2007 19:37:42 +0100, Harald Tveit Alvestrand  
<harald at alvestrand.no> wrote:

> Thanks to Andrew Sullivan for these very well-written minutes.
>
> Comments ASAP, please!

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: chl at clerew.man.ac.uk      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


_______________________________________________
IMA mailing list
IMA at ietf.org
https://www1.ietf.org/mailman/listinfo/ima