Subject: [EAI] Second Last Call - EAI protocol core documents

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 19 Nov 2007 23:21:46 +0100

This is the second Last Call for the following documents:

draft-ietf-eai-utf8headers-08.txt
draft-ietf-eai-dsn-05.txt
draft-ietf-eai-smtpext-09.txt

As is common for a second Last Call, the question that is being asked is 
whether or not the changes done resolved the issues raised, or if the 
changes have raised new issues. This is not a call for opening new issues 
with the unchanged text of the documents.

We know that some people (notably Frank and Charles) disagree with some of 
the resolutions in these documents. In order to verify that the consensus 
is with the documents as presented, I'm asking people who have reviewed the 
changes and agree with them to say so, rather than just going by "silence 
is consent".

This second Last Call will last for one week, ending on November 26, 2007. 
We will take advantage of the WG meeting in Vancouver to discuss any issues 
for which we don't have resolution on the mailing list.

If there are no such issues, we may send the documents to the IESG asking 
for an IETF-wide Last Call even before the meeting.

                  Harald, acting as WG chair

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 09:33:09 +0100

> draft-ietf-eai-utf8headers-08.txt

That still uses UTF8-xtra-char, using UTF8-non-ascii 
everywhere would be clearer. 

There's an unresolved "note" at the end of 4.1.

In 4.3 <utf8-text> hardwires control characters %d1-9
etc. intead of using a reference to RFC 2822 <text>.

In 4.3 <qtext> with NO-WS-CTL is a _copy_ from 2822
instead of a _reference_

There's an obsolete "note" near the end of 4.3.

In 4.4 the <angle-addr> ABNF apparently contains a
stray backslash.

In 4.4 the <alt-address> contains an invalid 1*FWS
instead of just FWS or whatever it's supposed to be.

AFAIK new MIME subtypes like message/global need a 
review on the "types" list at some point in time (?)

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 10:04:34 +0100

> draft-ietf-eai-dsn-05.txt

Looking at the diff I think that I-D is ready.

Maybe (later) add an informative reference to
ID.klensin-unicode-escapes about the
<EmbeddedUnicodeChar> business.

Section 4 introduces <UTF8-non-ascii>, this
construct could be already used in section 3
to simplify <QUCHAR>.  Or not, just an idea.

I still think this draft deserves some examples.

IFF new MIME types need a review on the "types"
list it would obviously also affect this draft.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 10:33:03 +0100

> draft-ietf-eai-smtpext-09.txt

Quite a lot of changes, but the reason for 
"updates 4952" isn't obvious for me.

In 2.7.3 the "anchor11" should be transformed
into proper text, proposal:

| Note: The FOR parameter has been changed to
| match the definition in RFC2821bis,
                          an successor of RFC2821,
| permitting only one address in the For clause.

| The group working on that document reached
| mailing list consensus that the syntax in
[...]
<shudder />  How about this:
+ The syntax in RFC 2821 that permitted more than
+ one address is considered as mistake.

"Anchor 7" tells the RFC editor that they should
replace 5.6.x and 5.6.z by the final codes.  They
should also replace 5.6.y and 2.6.y.

What's the state of the art with the registry I-D(s) ?
The informative reference ID.klensin-smtp-code-registry
should be ID.hansen-4468upd-mailes-registry, shouldn't
it ?  (No, Harald, that's not a "new" nit... ;-)

 Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Nov 2007 13:01:09 +0100

> "updates 4952" isn't obvious for me.
Read Appendix A.
> + one address is considered as mistake.
But EAI can't say that - it's out of charter.

Question: Is that a normative dependency on 2821bis?
> it ?  (No, Harald, that's not a "new" nit... ;-)
No, it was a missed one :-(
Thank you!

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 20 Nov 2007 13:43:57 +0100

Harald Alvestrand wrote:

>> How about this:
>> + The syntax in RFC 2821 that permitted more
>> + than one address is considered as mistake.
   
> But EAI can't say that - it's out of charter.

The WG *tries* to update *MIME* out of charter.

Why can't it offer an opinion about a 2821 detail
in a draft supported by John (the editor of 2821,
also the author of 4952 and 2821bis) ?

It's not really a 2821 erratum, and I've already 
exhausted my "process experiment" tolerance with
<http://rfc-editor.org/errata_search.php?rfc=1123>
for today.

> Is that a normative dependency on 2821bis?

More like an experimental 2821 update, but that's
what the draft anyway does.

Found appendix A, thanks, I forgot to return to 
"diff view" after checking the registry reference.

 Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Nov 2007 18:22:05 +0000

>There's an obsolete "note" near the end of 4.3.
+1.

>In 4.4 the <angle-addr> ABNF apparently contains a
Indeed, please change:

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

To

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

>instead of just FWS or whatever it's supposed to be.
I vaguely remember that we've settled on 1*FWS

>review on the "types" list at some point in time (?)
EAI documents don't change MIME type registration procedure. So yes, you 
are correct, but I don't think anything needs to be changed in the document.

I don't have any other issues with the document, so I support its 
publication.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 22 Nov 2007 07:44:48 +0100

> I vaguely remember that we've settled on 1*FWS

That's the known LWSP issue, we can't have more than
one FWS in a row, it would match "apparently empty"
lines and cause havoc.  Just FWS already allows more
than one SP or HT, still limited to at most one CRLF.

 Frank

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Nov 2007 11:08:14 +0000

Alexey Melnikov wrote:

> I've reviewed the latest draft-ietf-eai-smtpext-09.txt and all my 
> issues were addressed. So I support its submission to IESG.

One nit:

   Assuming that the server advertises UTF8SMTP and 8BITMIME, and

", BINARYMIME" is missing after UTF8SMTP

   receives at least one non-ASCII address, with or without ALT-ADDRESS,
   the precise interpretation of "No 'Body' parameter", "BODY=
   8BITMIME", and "BODY= BINARYMIME" in the MAIL command is:

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Nov 2007 11:03:56 +0000

> draft-ietf-eai-smtpext-09.txt

I've reviewed the latest draft-ietf-eai-smtpext-09.txt and all my issues 
were addressed. So I support its submission to IESG.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Nov 2007 08:49:57 -0500

Dear colleagues,

> draft-ietf-eai-utf8headers-08.txt

I have read this draft.  I didn't have any previous objections, but I
think that the changes are consistent with addressing the objections
that were raised.  I support advancing the document.

A few nits follow.

I note that in section 4.1, on page 5, the following text:

   [Note in draft: Whether normalizing is needed or not will be place
   in here.]

Should that be removed before advancement?  I presume the decision
has been made by the WG?

I see a similar note in section 4.3 on page 7:

   [NOTE IN DRAFT: If any header needs to be restricted to disallow
   this, please raise the issue on the mailing list.]

and again in section 5, on page 10:

   [Note in draft:
   Whether this non-requirement is adequate is a subject for debate].

Best regards,
Andrew

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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Nov 2007 09:02:25 -0500

Dear colleagues,

> draft-ietf-eai-dsn-05.txt

I have read that document.  I raised no objection in the previous
last call, but I believe the changes are consistent with addressing
the issues that were raised by others.  I support advancing the
draft.

Best regards,

Andrew

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 23 Nov 2007 13:38:22 +0900

> draft-ietf-eai-utf8headers-08.txt

I have read the document and support it be sent to IESG. Followings are 
trivial typos I found.

 > Use of this SMTP extension helps prevents the introduction of such

... helps preventing ...

 > described in [RFC1652]., an encoding may be applied to the message;

described in [RFC 1652], an ...

 > Below list a few possible <mailbox> representation as example.

a few possible <mailbox> representations ...

 > use of the new uFor syntax. UTF-8 information in needed in Received

... UTF-8 information is needed in Received

 > This will not break the rule of trace fied integrity, because it is

... trace field ...

And, I suggest downconvert (or down-convert) to downgrade to make it 
more consistent with the downgrade I.D.

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 23 Nov 2007 14:58:29 +0900

> draft-ietf-eai-smtpext-09.txt

I have read these two IDs and support them be forwarded.

Following a trivial typo I found in smtpext doc.

 > but receives a the UTF-8 string in a reply, it may not be able to

... receives a UTF-8 string ...

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 23 Nov 2007 10:29:09 -0000

> Should that be removed before advancement?  I presume the decision

Actually, I am not sure we ever did discuss this in detail. Persnally, I  
am all in favour of normalising things, especially where they form part of  
addressing information.

So perhaps a quick heads up if anyone else wants to pursue this further.  
Otherwise the Note should come out.

-- 
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: John C Klensin <[email-masked]>
Date: Fri, 23 Nov 2007 12:16:52 -0500

--On Friday, November 23, 2007 10:29 AM +0000 Charles Lindsey 
<[email-masked]> wrote:

>>    [Note in draft: Whether normalizing is needed or not will
>>    be place in here.]
>>
>> Should that be removed before advancement?  I presume the
>> decision has been made by the WG?
>
> Actually, I am not sure we ever did discuss this in detail.
> Persnally, I am all in favour of normalising things,
> especially where they form part of addressing information.
>
> So perhaps a quick heads up if anyone else wants to pursue
> this further. Otherwise the Note should come out.

Charles,

While it is a gray area, normalization of addresses violates the 
"only the delivery MTA and systems beyond it can interpret the 
local part" rule, just as case-mapping does.  I believe we are 
better off leaving it alone (i.e., not normalizing) and then 
recommending to operators of such MTAs that it would be wise to 
treat all normalized and unnormalized forms of the same string 
as equivalent, just as we now advise them to treat upper and 
lower case forms as equivalent.   If they want to use a specific 
form as a trap for the unwary, it is up to them.

But I agree with you in that I don't think the WG has reached a 
clear decision on this.

    john

---

From: "Debbie Garside" <[email-masked]>
Date: Fri, 23 Nov 2007 18:20:57 -0000

Hi

Quick question with regard to
http://www.ietf.org/internet-drafts/draft-ietf-eai-utf8headers-08.txt

On page 10 the draft states this:

"Encoding considerations:  Any content-transfer-encoding is permitted.
      The 8-bit or binary content-transfer-encodings are recommended
      where permitted."

On page 11 the draft states this:

"Restrictions on usage:  This is a structured media type which embeds
      other MIME media types.  The 8-bit or binary content-transfer-
      encoding MUST be used unless this media type is sent over a 7-bit
      only transport."

This use of "recommended" and "MUST" seem somewhat contradictory.

Best regards

Debbie Garside

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 26 Nov 2007 08:21:05 +0100

[...]
 
> This use of "recommended" and "MUST" seem somewhat contradictory.

Guessing:  The lower case "recommended" addresses the general case,
"if it's a message/global mail use 8bit (or binary), stay away from
7bit, QP, B64".  But they're still allowed, in the corner case where
the message/global is also a message/rfc822 (ASCII).  And for the
more important case where it must be somehow sent over a 7-bit hop
(relevant for delivery status notes, when message/global senders
 somehow managed that they can receive their DSNs over a 7-bit hop).

The later MUSTard limits the QP and B64 damage to necessary cases, 
DSNs over 7bit to confused senders.  They (EAI) use an unreported
2045 erratum for this required stunt, or rather they try to update
MIME, we'll see if that flies... ;-)

 Frank

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 Nov 2007 14:30:11 -0500

Dear colleagues,

> draft-ietf-eai-smtpext-09.txt

I apologise that I did not make the deadline for the second LC, and
that I have not had time to perform a complete review of the above
document.  I did not raise objections in the last round.  

For the record, I have re-read those objections that were raised and
the differences between -08 and -09, and I believe the changes are a
reasonable response to the objections that were raised.  I therefore
have no objection to the document advancing.

Best regards,

A

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 27 Nov 2007 10:27:23 -0000

> This use of "recommended" and "MUST" seem somewhat contradictory.

"SHOULD" would seem about right.