headers
Alexey Melnikov | 1 Aug 2011 03:28
Favicon

Re: I-D Action: draft-ietf-eai-5738bis-01.txt

Hi Chris,

Chris Newman wrote:
> --On July 11, 2011 3:04:44 -0700 internet-drafts <at> ietf.org wrote:
>>     Title           : IMAP Support for UTF-8
>>     Author(s)       : Pete Resnick
>>                           Chris Newman
>>                           Sean Shen
>>     Filename        : draft-ietf-eai-5738bis-01.txt
>>     Pages           : 16
>>     Date            : 2011-07-11
> I re-read this and tried putting on my somewhat dusty "IMAP 
> implementer hat" rather than my "protocol designer" hat. This 
> unfortunately resulted in a lot of substantive issues :-(
>
> There is one change I feel would be most helpful to make. I have 
> learned that LIST extended is quite difficult to implement in a 
> distributed server deployment and I believe that requirement will be a 
> barrier to deployment of this extension. I suggest the document be 
> changed so that the UTF8 LIST selection and return options can be used 
> without requiring full implementation of the LIST extended extension. 
> If the working group has rough consensus to go this direction, then I 
> can provide the ABNF and text so that capability can be provided with 
> or without the LIST extended extension.
>
> This benefits servers because servers that make simpler implementation 
> choices (such as UTF-8-only mailboxes) would no longer be forced to 
> implement the entire LIST extended structure to allow 
> interoperability. It also removes a "conditional" from the client (the 
> code the client uses presently has to be different based on the
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin J. Dürst | 1 Aug 2011 12:06
Picon
Gravatar

Re: Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too?

Hello Mark,

Many thanks for your quick answer.

On 2011/08/01 10:52, Mark Davis ☕ wrote:
> I'm glad you're submitting this; a thoughtful analysis, as I'd expect from
> you.
>
> The UTC will be discussing this during this week, but I thought I'd say a
> few things now.
>
> On the bidi algorithm issues:
>
>     - first, the committee approaches the UBA very carefully -- it has proven
>     to be quite sensitive, and any changes have to be done carefully. I expect
>     any actions at this meeting to still be in a proposal state. The earliest
>     possible point for any release is U6.1, which is in February. There are 2
>     F2F meetings before then.

Good to hear. I really think this needs time.

>     - we've seen a number of major companies extending or wanting to extend
>     the BIDI algorithm for display.
> http://unicode.org/reports/tr9/#HL3permits this, but what we really
> don't want to happen is for the extensions
>     to be incompatible. That's really what is driving this; and probably any
>     change would be in the form of a defined extension, which would have a more
>     or less strong recommendation (depending on what the committee decides). It
>     may be cast as 'experimental' -- we'll just have to see.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Yee | 1 Aug 2011 16:56

Re: I-D Action: draft-ietf-eai-5738bis-01.txt

Hi Chris, Alexey and all,

joseph ENABLE HAT=IMPELMENTOR

On 2011-07-31, at 9:28 PM, Alexey Melnikov wrote:

> Hi Chris,
> 
> Chris Newman wrote:
>> --On July 11, 2011 3:04:44 -0700 internet-drafts <at> ietf.org wrote:
>>>    Title           : IMAP Support for UTF-8
>>>    Author(s)       : Pete Resnick
>>>                          Chris Newman
>>>                          Sean Shen
>>>    Filename        : draft-ietf-eai-5738bis-01.txt
>>>    Pages           : 16
>>>    Date            : 2011-07-11
>> I re-read this and tried putting on my somewhat dusty "IMAP implementer hat" rather than my "protocol
designer" hat. This unfortunately resulted in a lot of substantive issues :-(
>> 
>> There is one change I feel would be most helpful to make. I have learned that LIST extended is quite
difficult to implement in a distributed server deployment and I believe that requirement will be a
barrier to deployment of this extension. I suggest the document be changed so that the UTF8 LIST selection
and return options can be used without requiring full implementation of the LIST extended extension. If
the working group has rough consensus to go this direction, then I can provide the ABNF and text so that
capability can be provided with or without the LIST extended extension.
>> 
>> This benefits servers because servers that make simpler implementation choices (such as UTF-8-only
mailboxes) would no longer be forced to implement the entire LIST extended structure to allow
interoperability. It also removes a "conditional" from the client (the code the client uses presently
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Newman | 1 Aug 2011 20:17
Picon
Favicon

Re: I-D Action: draft-ietf-eai-5738bis-01.txt

--On July 31, 2011 21:28:18 -0400 Alexey Melnikov 
<alexey.melnikov <at> isode.com> wrote:
> I might be agreeable to this change, but I would like to see a bit more
> details before unconditionally supporting it. Can you suggest some
> text/show an example on how this would look like?

Basically, I'd copy a subset of the LIST EXTENDED support into the draft 
and say that subset is activated by UTF8=ACCEPT even if LIST EXTENDED is 
not advertised.

That subset would not include multiple list patterns, remote, childinfo, or 
recursivematch. I think the subset would have to include SUBSCRIBED to 
avoid mucking with LSUB.

So the result would be syntactically upwards-compatible with list extended 
(the client could send commands within the subset regardless of whether 
LIST-EXTENDED was advertised), and would support the SUBSCRIBED, UTF8 and 
UTF8ONLY selection options and the UTF8 and SUBSCRIBED return options.

>> 3. Remove the UTF8=APPEND capability. This is a direct
>> server-implementer vs. client-implementer tradeoff. Not having that
>> capability and requiring servers to support this in any mailbox that
>> supports SELECT/EXAMINE UTF8 makes things simpler and more predictable
>> for clients, but at the expense of the server implementer. In
>> hindsight, I think this is one where the server implementers should
>> suffer to make things easier for the clients and to make the protocol
>> look simpler.
> Just to clarify: are you saying that this functionality should always be
> supported by compliant servers? If yes, do you also propose to remove the
> UTF-8 signaling in the APPEND command?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Newman | 1 Aug 2011 20:51
Picon
Favicon

Re: I-D Action: draft-ietf-eai-5738bis-01.txt

--On August 1, 2011 10:56:08 -0400 Joseph Yee <jyee <at> afilias.info> wrote:
> I would assume "UTF8=USER" meant to notify client about SASL on username
> & password rather than support of UTF8 on username & password.
>
> If it's about SASL, I think we are safe to remove the tag, with client
> needs to check the SASL tag.  If it's about supporting UTF8 in username &
> password, then I think it's ok to remove "UTF8=USER", but only stating
> "UTF8=ACCEPT" MUST imply the support of UTF8 to username & password.

The IMAP AUTHENTICATE command already supports UTF-8 if the SASL mechanism 
selected does. The PLAIN mechanism supports UTF-8.

So UTF8=USER was only about the IMAP LOGIN command. So I'd replace section 
5 with something like:

5.  LOGIN Command

   If the "UTF8=ACCEPT" capability is advertised, that indicates the
   server understands UTF-8 user names and passwords in the LOGIN
   command. This is not a guarantee that they underlying identity
   system will allow the creation of accounts with UTF-8 user names
   and/or passwords. However, if the identity system does allow such
   accounts, then the server MUST apply SASLprep [RFC4013] to both
   arguments of the LOGIN command. The server MUST reject UTF-8 that
   fails to comply with the formal syntax in RFC 3629 [RFC3629] or
   if it encounters Unicode characters disallowed by SASLprep.

		- Chris
Permalink | Reply | 1 comment |
headers
Mark Davis ☕ | 1 Aug 2011 03:52

Re: Unicode's PRI #185 & EAI: should the UBA be revised to handle bidi email addresses better too?

I'm glad you're submitting this; a thoughtful analysis, as I'd expect from you.
The UTC will be discussing this during this week, but I thought I'd say a few things now.

On the bidi algorithm issues: 
  • first, the committee approaches the UBA very carefully -- it has proven to be quite sensitive, and any changes have to be done carefully. I expect any actions at this meeting to still be in a proposal state. The earliest possible point for any release is U6.1, which is in February. There are 2 F2F meetings before then.
  • we've seen a number of major companies extending or wanting to extend the BIDI algorithm for display. http://unicode.org/reports/tr9/#HL3 permits this, but what we really don't want to happen is for the extensions to be incompatible. That's really what is driving this; and probably any change would be in the form of a defined extension, which would have a more or less strong recommendation (depending on what the committee decides). It may be cast as 'experimental' -- we'll just have to see.
On the feedback issue: One area where the ed committee has been moving to is using the Unicode forum, which provides for much nicer archival and searching than an email list. 

We could do a lot more, and also make it clearer that we want discussion to go on via email and forum discussions, but then want specific proposals that sum up different viewpoints to be submitted for the committee.

Mark
— Il meglio è l’inimico del bene —


On Fri, Jul 29, 2011 at 03:35, "Martin J. Dürst" <duerst <at> it.aoyama.ac.jp> wrote:
[This is a copy of a comment that I submitted via the Unicode Review Form and posted on the member-only Unicode mailing list. I'm sending it here to have a public record, because this's the mailing list where most of the discussion about this draft in the IETF happened, as far as I'm aware of.]


Context
=======

I'm an individual Unicode member, but I'll paste this in to the reporting form because that's easier. Please make a 'document' out of it (or more than one, if that helps to better address the issues raised here). I apologize for being late with my comments.


Substantive Comments
====================

On substance, I don't agree with every detail of what Jonathan Rosenne, Behdad Esfahbod, Aharon Lanin and others have said, I agree with them in general. If their documents/messages are not properly submitted, I include them herewith by reference.

The proposal is an enormous change in the Bidi algorithm, changing its nature in huge ways. Whatever the details eventually may look like, it won't be possible to get everything right in one step, and probably countless tweaks will follow (not that they necessarily will make things better, though). Also, dealing with IRIs will increase the appetite/pressure for dealing with various other syntactical constructs in texts.

The introduction of the new algorithm will create numerous compatibility issues (and attack surfaces for phishing, the main thing the proposal tries to address) for a long period of time. Given that the Unicode Consortium has been working hard to address (compared to this issue) even extremely minor compatibility issues re. IDNs in TR46, it's difficult for me to see how this fits together.


Taking One Step Back
====================

As one of the first people involved with what's now called IDNs and IRIs, I know that the problem of such Bidi identifiers is extremely hard. The IETF, as the standards organization responsible for (Internationalized) Domain Names and for URIs/IRIs, has taken some steps to address it (there's a Bidi section in RFC 3987 (http://tools.ietf.org/html/rfc3987#section-4), and for IDNs, there is http://tools.ietf.org/html/rfc5893).

I don't think these are necessarily sufficient or anything. And I don't think that the proposal at hand is completely useless. However, the proposal touches many aspects (e.g. recognizing IRIs in plain text,...) that are vastly more adequate for definition in another standards organization or where a high-bandwidth coordination with such an organization is crucial (roughly speaking, first on feasibility of various approaches, then on how to split up the work between the relevant organizations, then on coordination in details.) Without such a step back and high-bandwidth coordination, there is a strong chance of producing something highly suboptimal.

(Side comment on  detail: It would be better for the document to use something like
http://tools.ietf.org/html/rfc3987#section-2.2 rather than the totally obscure and no longer maintained http://rfc-ref.org/RFC-TEXTS/3987/chapter2.html, in the same way the Unicode Consortium would probably prefer to have its own Web site referenced for its work rather than some third-party Web site.)


Taking Another Step Back
========================

I mention 'high-bandwidth' above. The Unicode "Public Review" process is definitely not suited for this. It has various problems:
- The announcements are often very short, formalistic, and cryptic
 (I can dig up examples if needed.)
- The announcements go to a single list; forwarding them to other
 relevant places is mostly a matter of chance. This should be improved
 by identifying the relevant parties and contacting them directly.
- To find the Web form, one has to traverse several links.
- The submission is via a Web form, without any confirmation that the
 comment has been received.
- The space for comments on the form is very small.
- There is no way to make a comment public (except for publishing it
 separately).
- There is no official response to a comment submitted to the Web form.
 One finds out about what happened by chance or not at all.
 (compare to W3C process, where WGs are required to address each
  comment formally, and most of them including the responses are
  public)
- The turnaround is slow. Decisions get made (or postponed) at UTCs
 only.
Overall, from an outsider's point of view, the review process and the review form feel like a needle's ear connected to a black hole.

[I very much understand that part of the reason the UTC works the way it works is because of its collaboration with ISO/IEC committees. And I don't think any other standards organization has a perfect process. But what's appropriate for one part of the UTCs work may not be appropriate for other parts of its work (such as the matter at hand).]



Conclusion
==========

I herewith very strongly recommend that the UTC, besides using the upcoming meeting to advance discussion on the technical issues that the proposal raises,
a) Postpone the decision to adopt any of the proposed changes, independent of details, until such time as point b) is implemented and executed.
b) Swiftly take the necessary steps for a much better, high-bandwith coordination of this topic and the various issues it encompasses, both using the existing liaison mechanism and using public discussion on an appropriate forum (e.g. one of the relevant IETF mailing lists (idna/eai/iri)).
c) Seriously work on improving the process for soliciting and addressing comments from the public and relevant stakeholders.


Regards,    Martin.
_______________________________________________ 

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Permalink | Reply | 1 comment |
headers
Joseph Yee | 2 Aug 2011 03:55

Announcement: WG Consensus reached from IETF81 Quebec City

Hi All,

The WG had made the following tentative consensus calls during meeting at IETF 81 Quebec City.  These
results are considered final unless new substantive argument are raised on the list by August 8, 17:00 US
Pacific Time.

(1)
WG Consensus on Message-ID header field:
Message-ID allows UTF-8 in any part of its value.

(2)
WG Consensus on Commentary Materials in RFC5335-bis:
RC5335bis will keep the draft's commentary materials in appendix section.

Best,
Joseph, co-chair of EAI
Permalink | Reply | 2 comments |
headers
Jiankang Yao | 2 Aug 2011 04:18
Picon

81 IETF EAI meeting minutes

Dear all,


Pls see the initial 81 IETF EAI meeting minutes below or attached.

Pls kindly give your comments before 8 Aug.


Jiankang Yao

------------------------------------------- 
Meeting 
 
Email Address Internationalization (EAI) WG minutes 
 
IETF 81, Tuesday, July 26, 2011
0900-1130 
Room: 2103
Chairs: John Klensin  
       Joseph Yee
Scribe: Andrew Sullivan
Minutes: Jiankang Yao
 

Agenda Bashing 
- none 
 
Discussion Summary 
 
SMTP-bis (draft-ietf-eai-rfc5336bis-11): 
a)This draft needs a little refinement but is nearly
   ready for Working Group Last Call
b)New version of this draft should be submitted before 11 Aug.
c)The Working Group Last Call will be issued around 11 Aug.
 
Header-bis (draft-ietf-eai-rfc5335bis-11): 
a) Tentative consensus results:
- General support for UTF-8 in Message-IDs
- General support for including important commentary
  material from earlier versions in one or more appendices
  to the current organization of the draft.
**NOTE**
These results will be considered final if objections are
not raised on the list with new substantive arguments
before 8 August
b) New version of this draft (-12) should be submitted
around 11 Aug assuming that the consensus isn't
overturned by the possible objection 
c) Barry committed to review after revision -12 is up 
d) The Working Group Last Call will be issued around 11
Aug.

 
DSN-bis (draft-ietf-eai-rfc5337bis-dsn-03): 
a) No known issues
b) More extensive reviews are needed by more people
c) Chris Newman committed to review it
d) The Working Group Last Call will be issued around 11 Aug.
 
POP-bis (draft-ietf-eai-rfc5721bis-02): 
a) No known issues 
b) editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)


IMAP-bis (draft-ietf-eai-rfc5738bis-01): 
a) editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)

b) The ABNF syntax in section 2 needs some updates
c) few editorials issues remain
d) few participants are concerned about IMAP complexity, and would love to have working 

implementation to back the draft


Post-delivery Message Downgrading for Internationalized Email Messages 
(draft-ietf-eai-popimap-downgrade-02) 
a) Fujiwara presented slides on EAI consensus from IETF Beijing meeting and the new ABNF in 

current draft
b) Editors need more inputs for next revision
c) The WG discussed how to proceed to incorporate a provision
for group syntax (and hence no usable addresses for replies) at
backward pointing address.  There are two logical possibilities:
- (1) create a narrowly-focused update to 5322 outside
EAI, get it approved, and then have popimap-downgrade
refer to it.
- (2) update 5322 as part of the EAI work

There was general agreement that it was appropriate and
efficient to make the changes within the EAI WG effort. 
Chairs will discuss procedures with ADs offline as needed.

d) Chairs will have offline discussion (with IESG) regarding Downgraded-* headers
e) Editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)

f) John Klensin committed to help draft the initial text regarding Message-ID

 
 
A.O.B
a)ISOC Quebec chapter president offers some remarks about culture & internationalized 
 
environment and thanks the work of EAI
 

reminder: 
Anyone who committed to review docs 
should do so as promised. 
----------------------------------------
------------------------------------------- 
Meeting 

Email Address Internationalization (EAI) WG minutes 

IETF 81, Tuesday, July 26, 2011
0900-1130 
Room: 2103
Chairs: John Klensin  
       Joseph Yee
Scribe: Andrew Sullivan
Minutes: Jiankang Yao

Agenda Bashing 
- none 

Discussion Summary 

SMTP-bis (draft-ietf-eai-rfc5336bis-11): 
a)This draft needs a little refinement but is nearly
   ready for Working Group Last Call
b)New version of this draft should be submitted before 11 Aug.
c)The Working Group Last Call will be issued around 11 Aug.

Header-bis (draft-ietf-eai-rfc5335bis-11): 
a) Tentative consensus results:
- General support for UTF-8 in Message-IDs
- General support for including important commentary
  material from earlier versions in one or more appendices
  to the current organization of the draft.
**NOTE**
These results will be considered final if objections are
not raised on the list with new substantive arguments
before 8 August
b) New version of this draft (-12) should be submitted
around 11 Aug assuming that the consensus isn't
overturned by the possible objection 
c) Barry committed to review after revision -12 is up 
d) The Working Group Last Call will be issued around 11
Aug.

 
DSN-bis (draft-ietf-eai-rfc5337bis-dsn-03): 
a) No known issues
b) More extensive reviews are needed by more people
c) Chris Newman committed to review it
d) The Working Group Last Call will be issued around 11 Aug.

POP-bis (draft-ietf-eai-rfc5721bis-02): 
a) No known issues 
b) editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)

IMAP-bis (draft-ietf-eai-rfc5738bis-01): 
a) editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)
b) The ABNF syntax in section 2 needs some updates
c) few editorials issues remain
d) few participants are concerned about IMAP complexity, and would love to have working implementation to
back the draft

Post-delivery Message Downgrading for Internationalized Email Messages 
(draft-ietf-eai-popimap-downgrade-02) 
a) Fujiwara presented slides on EAI consensus from IETF Beijing meeting and the new ABNF in current draft
b) Editors need more inputs for next revision
c) The WG discussed how to proceed to incorporate a provision
for group syntax (and hence no usable addresses for replies) at
backward pointing address.  There are two logical possibilities:
- (1) create a narrowly-focused update to 5322 outside
EAI, get it approved, and then have popimap-downgrade
refer to it.
- (2) update 5322 as part of the EAI work

There was general agreement that it was appropriate and
efficient to make the changes within the EAI WG effort. 
Chairs will discuss procedures with ADs offline as needed.

d) Chairs will have offline discussion (with IESG) regarding Downgraded-* headers
e) Editors need more review from WG (http://www.ietf.org/proceedings/81/slides/eai-2.pdf)
f) John Klensin committed to help draft the initial text regarding Message-ID

 

A.O.B
a)ISOC Quebec chapter president offers some remarks about culture & internationalized 

environment and thanks the work of EAI

reminder: 
Anyone who committed to review docs 
should do so as promised. 
----------------------------------------

_______________________________________________
IMA mailing list
IMA <at> ietf.org
https://www.ietf.org/mailman/listinfo/ima
Permalink | Reply | 5 comments |
headers
John Levine | 2 Aug 2011 17:23

Re: 81 IETF EAI meeting minutes


>Header-bis (draft-ietf-eai-rfc5335bis-11): 
>a) Tentative consensus results:
>- General support for UTF-8 in Message-IDs
>- General support for including important commentary
>  material from earlier versions in one or more appendices
>  to the current organization of the draft.

I think there was support for my request to reword sec 3.4 a little to
clarify that it's OK to use message/global for messages that would be
valid message/rfc822, although for maximum backward compatibility it's
preferable not to do so.

R's,
John
Permalink | Reply | 4 comments |
headers
John C Klensin | 2 Aug 2011 19:15

Re: 81 IETF EAI meeting minutes

Agreed.

The text should parallel the text that describes the use of the
UTF8SMTPbis parameter when the contents of the message or
envelope are not known to require EAI (i.e., non-ASCII)
capability.  That means that those who are concerned about that
type of advice should check the existing text carefully to be
sure it reflects WG agreements about the matter.

   john

--On Tuesday, August 02, 2011 15:23 +0000 John Levine
<johnl <at> taugh.com> wrote:

> 
>> Header-bis (draft-ietf-eai-rfc5335bis-11): 
>> a) Tentative consensus results:
>> - General support for UTF-8 in Message-IDs
>> - General support for including important commentary
>>  material from earlier versions in one or more appendices
>>  to the current organization of the draft.
> 
> I think there was support for my request to reword sec 3.4 a
> little to clarify that it's OK to use message/global for
> messages that would be valid message/rfc822, although for
> maximum backward compatibility it's preferable not to do so.
> 
> R's,
> John
> _______________________________________________
> IMA mailing list
> IMA <at> ietf.org
> https://www.ietf.org/mailman/listinfo/ima
Permalink | Reply | 0 comments |

Gmane