Frank Ellermann | 7 Sep 2011 13:26
Picon
Picon

Re: I-D Action: draft-duerst-eai-mailto-01.txt

Hi,

draft-duerst-eai-mailto intends to obsolete RFC 6068, I'll
use 6068bis as a shorthand.  In section 2 you write that
<addr-spec-enc> excludes the RFC 5322 <comment>.

I think you actually exclude <comment> *and* <FWS>, i.e.,
(1) you get rid of any <CFWS> or <FWS> in <domain-literal>
    by directly using "[" *dtext-no-obs "]"
(2) you get rid of any <CFWS> or <FWS> in any <dot-atom> on
    both sides by directly using an encoded <dot-atom-text>
    with the name <dot-atom-text-enc>
(3) somehow <quoted-string-enc> avoids the <CFWS> before
    and after <quoted-string>, and it avoids <FWS> within
    <quoted-string>

Points (1) and (2) already solve all CFWS issues in syntax.
For (3) this is also possible:  As for (1) define a new
<qcontent-no-obs-enc> excluding <obs-qp> and <obs-qtext>.

After that 6068bis can improve what might be a subtle bug
in RFC 6068 1.3.  While there is no CFWS or FWS in mailto:
URIs, a space in a <quoted-pair> is okay, but of course it
has to be encoded:  mailto:%22joe%5C%20blogger%22 <at> example

The last example in section 6.2 already covered that, but
a less convoluted <quoted-pair> example might be clearer,
"joe\ blogger" <at> example (ok.), "joe blogger" <at> example (bad).

If the latter is really "bad" in RFC 5322, section 3.2.4
(Continue reading)

Joseph Yee | 14 Sep 2011 14:43

UTF-8 in Message-IDs consensus

All,

Below are consensus statement following the discussion thread UTF-8 in Message-IDs whether allowing
UTF-8 or not:

Message-ID can contain UTF-8 encodings in both formal syntax (ABNF) and general text.

----
Some note and observation
(1) There may be hiccups during transition period, but no convincing cases demonstrating Internet or
Email will be "broken badly"
(2) With encouragement of using domain as value of id-right in practice,  the WG majority preference (from
past discussion, not just the email thread mentioned above) is using U-label rather than A-label
(3) Regarding the concern of leak,  maybe we want to add some RECOMMEND text for MAIL FROM (or EAI capable MTA)
check? [personal opinion]
(4) The "SHOULD NOT use ASCII" could be used in advice doc explaining the advantage of being more
conservative [this is personal opinion, not as chair]

----

Again, sorry that I can't send this early enough.

Thanks
Joseph
Tony Hansen | 14 Sep 2011 15:05
Picon
Favicon

Re: UTF-8 in Message-IDs consensus

On 9/14/2011 8:43 AM, Joseph Yee wrote:
> All,
>
> Below are consensus statement following the discussion thread UTF-8 in Message-IDs whether allowing
UTF-8 or not:
>
> Message-ID can contain UTF-8 encodings in both formal syntax (ABNF) and general text.
>
> ----
> Some note and observation
> (1) There may be hiccups during transition period, but no convincing cases demonstrating Internet or
Email will be "broken badly"
> (2) With encouragement of using domain as value of id-right in practice,  the WG majority preference (from
past discussion, not just the email thread mentioned above) is using U-label rather than A-label
> (3) Regarding the concern of leak,  maybe we want to add some RECOMMEND text for MAIL FROM (or EAI capable
MTA) check? [personal opinion]
> (4) The "SHOULD NOT use ASCII" could be used in advice doc explaining the advantage of being more
conservative [this is personal opinion, not as chair]

Did you get #4 wrong? Is that supposed to read

     SHOULD NOT use UTF-8

?

     Tony Hansen

> ----
>
>
(Continue reading)

Joseph Yee | 14 Sep 2011 15:11
Picon

Re: UTF-8 in Message-IDs consensus

Yes, my mistake.

Thanks for noticing that.

Revised #4
(4) The "SHOULD NOT use UTF-8" could be used in advice doc explaining
the advantage of being more conservative [this is personal opinion,
not as chair]

Thanks
Joseph

On Wed, Sep 14, 2011 at 9:05 AM, Tony Hansen <tony <at> att.com> wrote:
> On 9/14/2011 8:43 AM, Joseph Yee wrote:
>>
>> All,
>>
>> Below are consensus statement following the discussion thread UTF-8 in
>> Message-IDs whether allowing UTF-8 or not:
>>
>> Message-ID can contain UTF-8 encodings in both formal syntax (ABNF) and
>> general text.
>>
>> ----
>> Some note and observation
>> (1) There may be hiccups during transition period, but no convincing cases
>> demonstrating Internet or Email will be "broken badly"
>> (2) With encouragement of using domain as value of id-right in practice,
>>  the WG majority preference (from past discussion, not just the email thread
>> mentioned above) is using U-label rather than A-label
(Continue reading)

Shawn Steele | 14 Sep 2011 21:17
Picon
Favicon

Re: UTF-8 in Message-IDs consensus

I'm happy with this; I'm fine with any extra text being in the advice doc, unless it is very simple &
quibble-proof :)

-Shawn
Arnt Gulbrandsen | 14 Sep 2011 23:06
Picon
Favicon
Gravatar

Re: UTF-8 in Message-IDs consensus

On 09/14/2011 09:17 PM, Shawn Steele wrote:
> I'm happy with this; I'm fine with any extra text being in the advice doc, unless it is very simple& 
quibble-proof :)

"Implementers of message-id generation algorithms may prefer to restrain 
their output to ASCII since that has a few minor advantages, such as 
when constructing References fields in mailing-list threads where some 
senders use EAI and others not."

Arnt
John C Klensin | 14 Sep 2011 23:27

Re: UTF-8 in Message-IDs consensus


--On Wednesday, September 14, 2011 19:17 +0000 Shawn Steele
<Shawn.Steele <at> microsoft.com> wrote:

> I'm happy with this; I'm fine with any extra text being in the
> advice doc, unless it is very simple & quibble-proof :)

With the understanding that this should not affect the consensus
call results, could people clarify which "advice document" they
have in mind?  From a quick look at the charter, there are four
possibilities:

(1) Reopen draft-ietf-eai-frmwrk-4952bis (now in the RFC Editor
queue) and put text there.

(2) Advice for non-ASCII & ASCII addresses
(3) Advice for MUA implementors
(4) Advice for EAI deployment

Note that no I-Ds for any of the last three documents have been
posted, indeed, the WG hasn't made a formal decision to move
forward with any (much less all) of them.  We have decided to
not make that decision until the protocol documents are under
control and we can appraise how much actual energy there is to
complete the work.

    john
Shawn Steele | 14 Sep 2011 23:30
Picon
Favicon

Re: UTF-8 in Message-IDs consensus

I don’t care which one, except don’t reopen the queued one, not high priority for me, just don’t want a
lot of back and forth.

-----Original Message-----
From: John C Klensin [mailto:klensin <at> jck.com] 
Sent: ᏦᎢᏁᎢᎦ, ᏚᎵᏍᏗ 14,2011 2:28 PM
To: Shawn Steele; ima <at> ietf.org
Subject: Re: [EAI] UTF-8 in Message-IDs consensus



--On Wednesday, September 14, 2011 19:17 +0000 Shawn Steele <Shawn.Steele <at> microsoft.com> wrote:

> I'm happy with this; I'm fine with any extra text being in the advice 
> doc, unless it is very simple & quibble-proof :)

With the understanding that this should not affect the consensus call results, could people clarify which
"advice document" they have in mind?  From a quick look at the charter, there are four
possibilities:

(1) Reopen draft-ietf-eai-frmwrk-4952bis (now in the RFC Editor
queue) and put text there.

(2) Advice for non-ASCII & ASCII addresses
(3) Advice for MUA implementors
(4) Advice for EAI deployment

Note that no I-Ds for any of the last three documents have been posted, indeed, the WG hasn't made a formal
decision to move forward with any (much less all) of them.  We have decided to not make that decision until
the protocol documents are under control and we can appraise how much actual energy there is to complete
(Continue reading)

John C Klensin | 14 Sep 2011 23:49

Re: UTF-8 in Message-IDs consensus


--On Wednesday, September 14, 2011 21:30 +0000 Shawn Steele
<Shawn.Steele <at> microsoft.com> wrote:

> I don't care which one, except don't reopen the queued
> one, not high priority for me, just don't want a lot of back
> and forth.

Shawn (and others),

I'm asking for two main reasons:

(1) I think  there is a real possibility that the "advice"
documents will get lost, or at least deferred for a long time,
after we extrapolate from current levels of activity in the WG
to the likelihood of taking on new documents and getting them
done in a reasonable period.  IMO, the odds go up somewhat if we
handle those documents as Applicability Statements and can get
WG and IESG consensus for publishing versions at Proposed
Standard without broad consensus that all issues have been
addressed and all nits picked, but I don't know how realistic
that is.   In any event, if the WG decides that the text should
go into an "advice document" that has not yet been put on the
agenda, we need to be prepared to abandon that text if the WG
shuts down before that advice document is published.

(2) There has been a brief discussion of another option, which
would be to attach this sort of material as an appendix to
5335bis.  That has several disadvantages, including some risk of
5335bis being delayed while we quibble about text.
(Continue reading)

Shawn Steele | 14 Sep 2011 23:50
Picon
Favicon

Re: UTF-8 in Message-IDs consensus

Yes, I realize there's a risk of  the advice getting lost, however I'd rather take that risk than delaying or
risking the existing docs

-----Original Message-----
From: John C Klensin [mailto:klensin <at> jck.com] 
Sent: Wednesday, September 14, 2011 2:49 PM
To: Shawn Steele; ima <at> ietf.org
Subject: RE: [EAI] UTF-8 in Message-IDs consensus

--On Wednesday, September 14, 2011 21:30 +0000 Shawn Steele <Shawn.Steele <at> microsoft.com> wrote:

> I don't care which one, except don't reopen the queued one, not high 
> priority for me, just don't want a lot of back and forth.

Shawn (and others),

I'm asking for two main reasons:

(1) I think  there is a real possibility that the "advice"
documents will get lost, or at least deferred for a long time, after we extrapolate from current levels of
activity in the WG to the likelihood of taking on new documents and getting them done in a reasonable
period.  IMO, the odds go up somewhat if we handle those documents as Applicability Statements and can get
WG and IESG consensus for publishing versions at Proposed Standard without broad consensus that all
issues have been addressed and all nits picked, but I don't know how realistic
that is.   In any event, if the WG decides that the text should
go into an "advice document" that has not yet been put on the agenda, we need to be prepared to abandon that
text if the WG shuts down before that advice document is published.

(2) There has been a brief discussion of another option, which would be to attach this sort of material as an
appendix to 5335bis.  That has several disadvantages, including some risk of 5335bis being delayed while
(Continue reading)


Gmane