Re: [EAI] Call for agenda items

[Chris Newman <[e-mail]>]

[if you respond to the technical content of this on the list, please change 
the subject]

While I haven't finished my AD review of eai-downgrade, there are a couple 
issues I'd like the WG to discuss so we have a rough consensus:

Topic: New address header format introduced by downgrade:
----
Section 3.1:

>downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS]
>                                     "<" Mailbox ">" [FWS] CRLF
>downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS]
>                                     "<" Mailbox ">" [FWS] CRLF

This ABNF introduces yet-another new address format.  I think that's a bad 
idea and a topic the WG should discuss further prior to progressing this. 
The alternative I would suggest is to use a subset of the same syntax used 
in other UTF-8 address headers so that the same parser can be reused:

downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
        FWS "<" Mailbox ">" ">" [CFWS]
----

Topic: Overlong 2047 encoded-words on downgrade.
----
Section 3.3:

>   2.  Encode the generated header field value according to [RFC2047]
>       with charset='UTF-8'.

This is problematic because 2047 can't be applied to all structured fields. 
How about the following:

   2. Treat the generated header field content as if it were unstructured,
      and then apply [RFC2047] encoding with charset UTF-8 as necessary so
      the result is ASCII.

>        To preserve space characters, the whole
>       header field value which include space characters SHOULD be
>       encoded.

This second sentence is also problematic.  RFC 2822 says lines SHOULD be 78 
characters.  The new SHOULD is contradictory to that statement, and thus 
problematic.  The simple solution would be to simply delete that sentence. 
An alternative would be to say something like:

  While RFC 2047 has a specific algorithm to deal with whitespace in
  adjacent encoded-words, there are a number of deployed implementations
  that fail to implement the algorithm correctly.  As a result, whitespace
  behavior is somewhat unpredictable in practice when multiple encoded words
  are used.  While RFC 2822 states that implementations SHOULD limit lines
  to not more than 78 characters, implementations MAY choose to allow
  overlong encoded words in order to work around faulty RFC 2047
  implementations.  Implementations that choose to do so SHOULD have an
  optional mechanism to limit line length to 78 characters.

I'm not sure it's worth that much text in the specification just to cater 
to software that mis-implemented RFC 2047.  What do others think?
----

Topic: Completeness of downgrade for standards track headers

We have several standards track headers that are not included in the lists 
for downgrading but can be downgraded relatively easily.  Of particular 
note are "Auto-Submitted" since we have a BCP recommending Internet 
software generate it, and "Content-Language" which is simple since it only 
requires comment downgrading.  Is what we have "good enough" for the 
working group, should we add BCP/IETF "recommended" headers to the list, 
and/or should we evaluate all standards-track mail headers in the registry 
for inclusion?

		- Chris

--On November 8, 2008 7:19:37 +0100 Harald Alvestrand 
<[e-mail]> wrote:

> I now discover that I as a chair have not done my duty as of a month ago
> and posted an agenda and a proposed workplan for this meeting.
>
> On the principle of "better late than never", I am calling for anyone who
> wishes to raise something with the WG to post a note here.
>
> The ones I intend to add are:
>
> - Status and plans for next round
> - Downgraded-display
> - Experience (yao-eai-deployment, dainow-eai-email-clients)
> - IMAP
>
> Possible issues (if someone wants to discuss these, I'll add):
>
> - POP (no updated draft, no discussion, no agenda slot)
> - draft-ellermann-spf-eai
> - draft-ietf-eai-mailto
>
> Anything else people want on the agenda?
>
>                   Harald
>
>
>
>
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima
>




_______________________________________________
IMA mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ima