Subject: [EAI] draft-ietf-eai-framework-03.txt

From: John C Klensin <[email-masked]>
Date: Fri, 10 Nov 2006 10:40:04 -0500

Document is now in the posting queue.

As Harald indicated in the WG meeting yesterday, please review 
to be sure that all issues in the tracker have been 
appropriately dealt with.  In addition, please check to verify 
that none of the many editorial changes and clarifications have 
made things worse.

     john

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

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 11 Nov 2006 19:14:14 +0100

> Document is now in the posting queue.

Here's a diff:

http://tools.ietf.org/rfcdiff?url2=http%3A%2F%2Ftools.ietf.org%2Fid%2Fdraft-ietf-eai-framework-03.txt&difftype=--hwdiff

> please check to verify that none of the many editorial
> changes and clarifications have made things worse.

1)

In 1.1 there's an "anchor1 placeholder" to the history of
EAI, is that to a planned new section of the I-D ?  Some
historical background is often interesting to read, if
that's what you have in mind.

At the end of 1.2 a "do" was deleted, but I think you want
"do not have" or "have no" (CTE).

In 1.3 4th paragraph you have now 'an address is "non-ASCII",
or a "UTF8SMTP" address'.  In the 6th paragraph you define
that the set of "UTF8SMTP" addresses is the union of the
"all-ASCII" and the "non-ASCII" addresses.  Based on that
"UTF8SMTP" is not a synonym for "non-ASCII", but in the 4th
paragraph it sounded like a synonym.  Something's odd, maybe
only a lack of caffeine on my side.

Still in 1.3 8th paragraph you introduce the "i18mail user",
should that now be "UTF8SMTP user" ?  There are only three
uses of "i18mail" in the draft, all in this paragraph.  The
added last sentence could be removed again if you change the
two other occurences of "i18mail" to "UTF8SMTP".

Do we need a definition of "mailing list" (10th paragraph) ?
The new 11th paragraph (reject vs. NDN) is good.  

3)

In bullet 3 you added "conceptual process...called an MDA".
Apparently you don't like that acronym.  IMO you could get
rid of it, it's not used or needed elsewhere in the draft.

4)

In 4.1 point 1 "whatever encoding" (on both sides), are we
sure about that ?  Or could there be legit cases of an UTF-8
local part with an IDNA domain ?  Point 2 issue 1389: it's
okay.

At the end of 4.1 there's still the old "_if_ the system
implements IMAP it conforms to IMAP spec, ditto for POP.???"

How about this:  "if the system supports IMAP it has to
conform to [EAI-imap], and if it supports POP to [EAI-pop]".
And if it uses say squirrelmail they will upgrade this, too.
That's issue #1390 (4.1 "POP") in Harald's list.

In 4.3 "presumably using UTF-8" strike "presumably", UTF-8
is a decade beyond the stage when that was an open question.
[[WP:AWW]] unless you think that UTF-7 or BOCU-1 are cute :-)

5)

5.1: s/rejected, or non-delivery/rejected, or a non-delivery/
5.2: s/will be always be capable/will be always capable/ (?)
     s/emails or specifically/emails, or specifically/
     s/If this done/If this is done/
     That's a very interesting SHOULD in 5.2, and I like it.

6)

6.4, what caused the---strange---effect, an xml2rfc &mdash; ?
     Maybe use "an - ordinary - hyphen-minus".

6.6: s/Non-standard/Traditional/ (?)  Otherwise I like 6.6.
     For 6.5 I'm not sure, delete it if you don't like 6.5,
     that's #1393 in Harald's list.

9)

Maybe replace 1 of 2 [RFC 4690] by I-D.klensin-idnabis-issues,
or better replace [Net-Unicode] by idnabis-issues.  In the
references that's listed as net-utf8-00 instead of ...-02 (?)

12)

Kind of stupid, but there's a trick to get rid of the "work
in progress" blurb if that's obviously not the case:  Insert
(instead of transclude) the complete <reference> element,
and then remove "-Draft" in the seriesInfo="Internet-Draft",
here for I-D.hoffman-imaa

Nothing substantial, only minor editorial nits, ready to go.

Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 13 Nov 2006 16:17:00 +0900

> only a lack of caffeine on my side.

"Non-ASCII address" and "UTF8SMTP address" are not
synonyms. Quite recently, most of "i18n-something"
occurrences are replaced with "UTF8SMTP-something".
During this process, this one seems to be replaced
erroneously.

> Do we need a definition of "mailing list" (10th paragraph) ?

Do we have a definition of it in other RFCs?

> rid of it, it's not used or needed elsewhere in the draft.

Original intent was (as far as I know) to clarify
that some UTF8SMTP related jobs (e.g. down/up
grading) can happen outside of SMTP process as
shown in section 5. Since section 5 is self
explanatory, we may remove this definition if
it looks redundant.

> local part with an IDNA domain ?  Point 2 issue 1389: it's

OOPs. I am starting to confuse. ACE and UTF8 are encodings
at different layers. For MTAs, IDNA domains are just in
ASCII encoding that is also valid UTF8 encoding.

>      Maybe use "an - ordinary - hyphen-minus".

Nothing strange. That is exactly how original text looks like.
If you don't like it, hmmmmm...

> Nothing substantial, only minor editorial nits, ready to go.

Thanks for careful review.

---

From: Philip Guenther <[email-masked]>
Date: Mon, 13 Nov 2006 01:17:54 -0700

>     Maybe use "an - ordinary - hyphen-minus".

Ugh.  If people find "---" as the plain ascii version of an em-dash to be 
ugly or distracting, then I would suggest rephrasing to avoid it.  In this 
case, simply dropping the set-off phrase completely seems best: given the 
rest of the paragraph, it probably doesn't need to be explicitly called 
out that EAI-upgrade includes RFC 2047 decoding.  I would much prefer that 
over using plain '-' where an em-dash is needed.

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 13 Nov 2006 05:19:51 -0800

John C Klensin wrote:

> As Harald indicated in the WG meeting yesterday, please review to be 
> sure that all issues in the tracker have been appropriately dealt 
> with.  In addition, please check to verify that none of the many 
> editorial changes and clarifications have made things worse.

 >4.2. Transmission of Email Header Fields in UTF-8 Encoding

>   There are many places in MUAs or in user presentation in which email
>   addresses or domain names appear.  Examples include the conventional
>   From, To, or Cc header fields; In-Reply-To fields that may contain
>   addresses or domain names; Message-ID fields that normally contain
>   domain names (but that may be a special case); and in message bodies.

The In-Reply-To should be mentioned together with the Message-Id?
Suggested replacement (also changed "fields" to "header fields"):

>4.2.  Transmission of Email Header Fields in UTF-8 Encoding
>
>   There are many places in MUAs or in user presentation in which email
>   addresses or domain names appear.  Examples include the conventional
>   From, To, or Cc header fields; Message-ID and In-Reply-To header fields that normally contain
>   domain names (but that may be a special case); and in message bodies.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Nov 2006 16:29:16 +0100

Philip Guenther wrote:

> I would much prefer that over using plain '-' where an em-dash is needed.

There simply is no &mdash; in text/plain US-ASCII, maybe you could
emulate it with -- like this -- or similar.  Let's see what xml2rfc
1.32pre2 does:

| Something -- like this -- or similar.  But--plaease not--this.

Source:
|        <t>Something &mdash; like this &mdash; or similar.
|           But&mdash;plaease not&mdash;this.</t>

With that you'd get a proper &mdash; in the HTML output of xml2rfc, and
only two hyphens in the I-D and future RfC.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 13 Nov 2006 16:57:31 +0100

> Do we have a definition of it in other RFCs?

Yes, RFCs 1123 5.3.6(b) and 2821 3.10.2 define it wrt SMTP.  

Nothing is wrong with the definition in section 1.3, but the 
term "mailing list" is not needed anywhere in the document.

>> local part with an IDNA domain ?
[...]
> ASCII encoding that is also valid UTF8 encoding.

Here's an example (please pretend that my Latin-1 is UTF-8 :-)

To: "F. Möller" <[email-masked]>
Cc: "G. Müller" <[email-masked]>

Is the Cc: "illegal" in some way, because it didn't use "öko" ?

 [aaa---bbb ccc---ddd]
> If you don't like it, hmmmmm...

See another article, xml2rfc would write aaa -- bbb ccc -- ddd

Frank

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Nov 2006 16:58:07 -0500

--On Monday, 13 November, 2006 05:19 -0800 Alexey Melnikov
<[email-masked]> wrote:

>> As Harald indicated in the WG meeting yesterday, please
>> review to be  sure that all issues in the tracker have been
>> appropriately dealt  with.  In addition, please check to
>> verify that none of the many  editorial changes and
>> clarifications have made things worse.
> 
>>   There are many places in MUAs or in user presentation in
>>   which email addresses or domain names appear.  Examples
>>   include the conventional From, To, or Cc header fields;
>>   In-Reply-To fields that may contain addresses or domain
>>   names; Message-ID fields that normally contain domain names
>>   (but that may be a special case); and in message bodies.
> 
>>   There are many places in MUAs or in user presentation in
>>   which email addresses or domain names appear.  Examples
>>   include the conventional From, To, or Cc header fields;
>>   Message-ID and In-Reply-To header fields that normally
>>   contain domain names (but that may be a special case); and
>>   in message bodies.

First, everyone, please remember that "for example" or "examples
include" is intended to convey "this is not a comprehensive
list".  Always putting "header" in front of fields is ok, but
has not been our conventional usage.  If we do it, someone
(presumably the co-chairs) need to remember to advise the RFC
Editor to not change what may seem to them to be uncomfortable
language.

Second, and more important, the previous version was more like
the above than the current one.  Someone complained about it
because (they said) In-Reply-To fields may actually contain
addresses, not just domain names.   So, I'm happy to make this
change if others agree, but I don't want to keep cycling on this
text.

     john

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Nov 2006 17:04:40 -0500

--On Monday, 13 November, 2006 01:17 -0700 Philip Guenther
<[email-masked]> wrote:

> Ugh.  If people find "---" as the plain ascii version of an
> em-dash to be ugly or distracting, then I would suggest
> rephrasing to avoid it.  In this case, simply dropping the
> set-off phrase completely seems best: given the rest of the
> paragraph, it probably doesn't need to be explicitly called
> out that EAI-upgrade includes RFC 2047 decoding.  I would much
> prefer that over using plain '-' where an em-dash is needed.

(1) FWIW, the _very_ standard typographic convention for an
em-dash is "--", not "---" and certainly not "-".  There is
controversy among style manuals whether it should be typed as 
   foo--bar
or as
   foo -- bar
The source now (just corrected) uses the latter consistently.
XML2RFC will do whatever it does.

(2) Also FWIW, there is no "&mdash;" construction in the XML
text.  The "---" actually appeared, presumably as the result of
a typographical error, or too-broad find-and-replace operation,
sometime.  It has been fixed.

(2) Trying to fine-tune this is a waste of time: the RFC Editor
will apply whatever conventions they are using when the document
gets to them.

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Nov 2006 17:07:28 -0500

> term "mailing list" is not needed anywhere in the document.

Someone told me/us to put it in.  If there is consensus, we can
remove it, but we are getting down rather far into the nits here.

> Is the Cc: "illegal" in some way, because it didn't use "öko"

No.  It is not.  I might be silly, but there is nothing illegal
or invalid about it.  It is also impossible to prohibit, which
has been said many times.   If someone really believes this is
worth fixing, suggest text (and get a new issue number from
Harald).

>...

Dealt with; see other note.

    john

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Nov 2006 19:19:54 +0100

John C Klensin wrote:

> we are getting down rather far into the nits here.

Yes, ignore what you don't need, I just read it top down using
a fine comb for anything attracting my attention - from serial
comma over typos and unused definitions and mdash oddities up
to one remotely substantial question:

>> To: "F. Müller" <[email-masked]>
>> Cc: "G. Möller" <[email-masked]>

> or invalid about it.

Good...

> It is also impossible to prohibit

...better.

> which has been said many times.

I missed that, and the "whatever encoding" distracted me, like the
"presumably" in another paragraph.  (Just checking BCP 18 again -
the ultimatum for worldwide UTF-8 runs out in about 41 years... ;-)

Maybe say "can and reasonably should be applied to both" LHS + RHS,
instead of only "should be applied to both".  A bit more verbose,
but IMO clearer.  The short form could tempt readers to hallucinate
an uppercase SHOULD.

Frank

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Nov 2006 18:43:42 -0800

> remove it, but we are getting down rather far into the nits here.

I believe it came in when we decided to fold the terminology section from 
the scenarios doc into the framework doc; the scenarios doc does need the 
term.

              Harald