Subject: [EAI] Call for agenda items

From: Harald Alvestrand <[email-masked]>
Date: Sat, 08 Nov 2008 07:19:37 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Chris Newman <[email-masked]>
Date: Tue, 11 Nov 2008 13:32:10 -0800

[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 
<[email-masked]> wrote:

> 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.
>

---

From: Ernie Dainow <[email-masked]>
Date: Tue, 11 Nov 2008 17:12:36 -0500

There were a few comments on this document leading up to the 
Philadelphia meeting (John K, Randy G) but we were waiting for a bit 
more discussion before doing an update.

I won't be in Minneapolis but would like to see this document advance. 
There are a number of places marked TBD. It would be good if others can 
provide some input on these in particular.

Ernie

Harald Alvestrand 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.
>

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 12 Nov 2008 10:51:59 -0000

On Tue, 11 Nov 2008 21:32:10 -0000, Chris Newman <[email-masked]>  
wrote:

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

Done!

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

Yes, I think that is better. For sure that was the intent, and I thought  
we had managed to get <unstructured> into the syntax in the proper places  
to make it clear. Tne only oddity is that the body of the Downgraded  
header is not all <unstructured>. The first part of that body is the name  
of the header, which is followd by the <unstructured>. So we have a  
structured header which contains an <unstructured> within it, and it is  
only that <unstructured> portion which I would expect to be 2047-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:

I think it would be simpler just to add a further sentence of the form:

    "Note that [RFC2047] requires header field lines containing  
<encoded-word>s to be folded so as the keep their length to within 76  
characters; if done correctly, this enables the original spacing to be  
restored upon decoding."

> 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?

I think specifications for other headers should be encouraged to define  
explicit downgrading extensions to our document for such headers wherever  
they feel it beneficial to do so. Having said that, I have no problem if  
somone wants to go through the list of registered headers and pick out  
candidates that we should deal with at this stage.

Note that, where some other document _does_ provide such an extension for  
some new header, existing implementations may continue to just use the  
Downgraded form alone. I see no problem with that.

-- 
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
_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: [email-masked]
Date: Thu, 13 Nov 2008 21:06:46 +0900 (JST)

> From: Chris Newman <[email-masked]>
> 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:
> 
> 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:
> 

This syntax is easy to understand. But it is different from SMTP command.
(The original format is also different from SMTP command.)
I have one another idea.
downgraded-envelope-addr = [FWS] uPath 1*[FWS] "ALT-ADDRESS=" ALT-ADDRESS-value [FWS]

Which is better, "<nonASCII> <ASCII>", "<nonASCII <ASCII>>" or "<nonASCII> ALT-ADDRESS=ASCII ?

> From: "Charles Lindsey" <[email-masked]>
>
> > This is problematic because 2047 can't be applied to all structured fields. How about the following:
> >
> Yes, I think that is better. For sure that was the intent, and I thought we had managed to get <unstructured> into the syntax in the proper places to make it clear. Tne only oddity is that the body of the Downgraded header is not all <unstructured>. The first part of that body is the name of the header, which is followd by the <unstructured>. So we have a structured header which contains an <unstructured> within it, and it is only that <unstructured> portion which I would expect to be 2047-encoded.

Section 3.1 and 3.2 have same issue. (I missed RFC 2047 encoding in section 3.1).

> > 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:
> 
>     "Note that [RFC2047] requires header field lines containing <encoded-word>s to be folded so as the keep their length to within 76 characters; if done correctly, this enables the original spacing to be restored upon decoding."

This is simple and enough.

> > 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?
>
> I think specifications for other headers should be encouraged to define explicit downgrading extensions to our document for such headers wherever they feel it beneficial to do so. Having said that, I have no problem if somone wants to go through the list of registered headers and pick out candidates that we should deal with at this stage.
> 
> Note that, where some other document _does_ provide such an extension for some new header, existing implementations may continue to just use the Downgraded form alone. I see no problem with that.

I agree. Newly extended or defined header fields which contain UTF-8
non-ASCII characeters require definitions for downgrading.

If there are some missing header fields which are allowed to use
UTF-8 non-ASCII characters in RFC 5335, please inform me.

The "Auto-Submitted" header field may contain UTF-8 characters in CFWS.
It is covered in "COMMENT downgrading" in section 5.
But it is not listed in Section 5.1.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>
_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Nov 2008 18:31:21 +0000

>>                                     "<" Mailbox ">" [FWS] CRLF
If uPath is expanded, this becomes:

downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" "<" [ A-d-l ":" ] 
uMailbox ">" ">"
   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:
>

Right, so this is basically the first part of <angle-addr> from RFC 5335:

   angle-addr     =/ [CFWS] "<" utf8-addr-spec [ alt-address ] ">"
                     [CFWS] / obs-angle-addr

I like that a lot.

---

From: Chris Newman <[email-masked]>
Date: Mon, 17 Nov 2008 13:49:42 -0600

--On November 13, 2008 21:06:46 +0900 [email-masked] wrote:
>> 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:
>>
>> > downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">"
>> 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:
>>

I have a slight preference to keep the SMTP parser and the Message Format 
parsers separate.  Thus I prefer a syntax that reuses the Message Format 
syntax for EAI downgrade headers rather than the SMTP syntax.

		- Chris