Nabble - IETF - IMA

SPAM 11.038 (5) Re: EAI WG status and rechartering

2009-12-17T18:32:41Z

----- Original Message -----
From: "Alexey Melnikov" <alexey.melnikov@...>
To: <ima@...>
Sent: Saturday, November 21, 2009 2:08 AM
Subject: [EAI] EAI WG status and rechartering

> Greetings,
>
> Here is what I think remains to be done under the current WG charter:
>
> 1).
> draft-ietf-eai-downgraded-display
> draft-ietf-eai-imap-utf8
>
> I am awaiting for updated versions of these documents before getting
> them approved.
>
> 2). The following document is the last deliverable needed before
> rechartering (I think):
>
> draft-ietf-eai-mailinglist
>
> Currently it is expired. Reissuing the document and sending it to WGLC
> (if ready), would be nice.
>

I just check the status of these 3 documents.

draft-ietf-eai-downgraded-display is in the IESG Evaluation::AD Followup
draft-ietf-eai-imap-utf8 is in the RFC Ed Queue
draft-ietf-eai-mailinglist is expired but in the status of AD Evaluation::Revised ID Needed

Randall, could you kindly update your draft about draft-ietf-eai-mailinglist?

the current version of this draft was finished on November 20, 2008.

We may start recharter discussion after finishing these 3 documents as it is suggestd by Alexey.

Yao Jiankang
CNNIC

>
> While I am waiting for the 3 documents, I think the WG can start
> discussion about whether the group should shut down or recharter. In
> case there is consensus to recharter, I would like to see if updated
> charter text can be agreed on.
>
> If the WG has enough energy to recharter, I would also like to ask the
> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
> additional deliverable.
>
> Note that I also would be looking for at least 1 new WG chair. If you
> want to volunteer yourself or somebody else, please send me an email
> message with details directly.
>
> Best Regards,
> Alexey, Apps AD.
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Appointment of the EAI WG Secretary

2009-12-14T12:59:28Z

Dear WG,
After talking to chairs and receiving feedback from several active WG
members I've decided to appoint Jiankang Yao <yaojk@...> as the EAI
WG Secretary.

Best Regards,
Alexey Melnikov, as an Apps Area Director.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: ´ð¸´: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-14T03:04:11Z

Barry Leiba wrote:

>>>>>The last paragraph refer to "security considerations" in rfc5504 and
>>>>>rfc4952. But the security considerations in those documents are more about
>>>>>security issues for downgrading mechenisms. I suppose the security
>>>>>consideratioins in this document focuses more on downgraded-display. This
>>>>>should be clarified.
>>>>>
>>>>>
>>>It's common to reference security considerations in related documents,
>>>to make sure that readers understand those as well. I don't see that
>>>anything needs to be changed here.
>>>
>>>
>>It is right to refer to security considerations in 5504 and 4952. I am saying the
>>security considerations in different documents focus on different aspects, it's
>>better to explicitly say that: this section focus on security issues of displaying
>>downgraded messages, for security considerations for downgrading mechanism
>>please see ....
>>
>>
>OK, I see. Yes, fair enough. Alexey, would you add one more RFC Editor note?:
>
>Section 4:
>OLD:
> See "Security considerations" section in [RFC5504] and [RFC4952] for
> more discussion.
>NEW:
> We have focused, here, on issues with displaying downgraded messages. For
> more discussion of downgraded and internationalized messages in general, see
> the "Security considerations" sections in [RFC5504] and [RFC4952].
>
>

Ok, added.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: 答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-13T19:02:52Z

>> >> The last paragraph refer to "security considerations" in rfc5504 and
>> >> rfc4952. But the security considerations in those documents are more about
>> >> security issues for downgrading mechenisms. I suppose the security
>> >> consideratioins in this document focuses more on downgraded-display. This
>> >> should be clarified.
>>
>> It's common to reference security considerations in related documents,
>> to make sure that readers understand those as well. I don't see that
>> anything needs to be changed here.
>
> It is right to refer to security considerations in 5504 and 4952. I am saying the
> security considerations in different documents focus on different aspects, it's
> better to explicitly say that: this section focus on security issues of displaying
> downgraded messages, for security considerations for downgrading mechanism
> please see ....

OK, I see. Yes, fair enough. Alexey, would you add one more RFC Editor note?:

Section 4:
OLD:
See "Security considerations" section in [RFC5504] and [RFC4952] for
more discussion.
NEW:
We have focused, here, on issues with displaying downgraded messages. For
more discussion of downgraded and internationalized messages in general, see
the "Security considerations" sections in [RFC5504] and [RFC4952].

Barry
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-13T18:44:14Z

Sorry for the delayed response:

> 发件人: ima-bounces@... [mailto:ima-bounces@...] 代表 Barry
> Leiba
> 发送时间: 2009年12月5日 23:06
> 收件人: ima@...
> 主题: Re: [EAI] I-D Action:draft-ietf-eai-downgraded-display-03.txt
>
> > Sean Shen 沈烁 wrote:
> >
> >> Also I noticed that "above" and "below" are used in a few places. These
> >> are not necessary when you already clearly refer to the exact sections.
>
> Clarity is helpful; the use of "above" and "below", here, makes the
> English flow better.
>
> >> section 4
> >> The first paragraph describes a scenario that "Downgraded-From" header
> >> field can not be reconstructed. But it's not clear then what will happen. Any
> >> security effects?
>
> Hm. I think we might have lost a small bit in the re-writing. The
> intent is that downgraded header fields that can't be reconstructed be
> left as they are, and might possibly be subject to the next paragraph,
> about emphasizing reconstruction problems. I think I'd like to add
> this back in as a paragraph in section 3.1, "Considerations". How's
> this, as a third paragraph in 3.1?:
>
> In any case where reconstruction of a particular downgraded header field
> fails, both fields (the "downgraded-X" field and the "X" field) SHOULD be
> left in the message as they are. The MUA MAY choose to communicate
> the situation to the user (see Security Considerations).

[Sean] Thanks, that answered my concern.

> >> The last paragraph refer to "security considerations" in rfc5504 and
> >> rfc4952. But the security considerations in those documents are more about
> >> security issues for downgrading mechenisms. I suppose the security
> >> consideratioins in this document focuses more on downgraded-display. This
> >> should be clarified.
>
> It's common to reference security considerations in related documents,
> to make sure that readers understand those as well. I don't see that
> anything needs to be changed here.
It is right to refer to security considerations in 5504 and 4952. I am saying the security considerations in different documents focus on different aspects, it's better to explicitly say that: this section focus on security issues of displaying downgraded messages, for security considerations for downgrading mechanism please see ....

Best,

Sean

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-05T07:05:39Z

> Sean Shen 沈烁 wrote:
>
>> Also I noticed that "above" and "below" are used in a few places. These
>> are not necessary when you already clearly refer to the exact sections.

Clarity is helpful; the use of "above" and "below", here, makes the
English flow better.

>> section 4
>> The first paragraph describes a scenario that "Downgraded-From" header
>> field can not be reconstructed. But it's not clear then what will happen. Any
>> security effects?

Hm. I think we might have lost a small bit in the re-writing. The
intent is that downgraded header fields that can't be reconstructed be
left as they are, and might possibly be subject to the next paragraph,
about emphasizing reconstruction problems. I think I'd like to add
this back in as a paragraph in section 3.1, "Considerations". How's
this, as a third paragraph in 3.1?:

In any case where reconstruction of a particular downgraded header field
fails, both fields (the "downgraded-X" field and the "X" field) SHOULD be
left in the message as they are. The MUA MAY choose to communicate
the situation to the user (see Security Considerations).

>> The last paragraph refer to "security considerations" in rfc5504 and
>> rfc4952. But the security considerations in those documents are more about
>> security issues for downgrading mechenisms. I suppose the security
>> consideratioins in this document focuses more on downgraded-display. This
>> should be clarified.

It's common to reference security considerations in related documents,
to make sure that readers understand those as well. I don't see that
anything needs to be changed here.

Barry
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-05T05:47:41Z

YAO Jiankang wrote:

>----- Original Message -----
>From: "Shawn Steele" <Shawn.Steele@...>
>To: <ima@...>
>Sent: Thursday, December 03, 2009 8:37 AM
>Subject: Re: [EAI] I-D Action:draft-ietf-eai-downgraded-display-03.txt
>
[...]

>>I'm not sure if downgraded display is required for the charter? I'd thought yes, but it doesn't seem to be in the
>>1.6 Deliverables section?
>>
>>
>I think that downgraded display is not proper for the recharter. but I am not sure whether the current charter allow it. The co-chairs can decide it.
>
I think downgraded-display falls under "Advice for MUA implementors".

Earlier WG Chairs have asked if downgraded-display should be adopted as
a WG document and there was rough consensus for adopting it.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-05T05:31:13Z

Sean Shen 沈烁 wrote:

>Hi, EAI WG and Authors,
>
Dear Sean,

>I read the draft and have the a few comments.
>
Thank you for the comments.

>#1
>Usually the "Abstract" is after "Status of this Memo" and "Copyright
>Notice", right before the "Table of Contents". I went back to check previous
>versions and found that 01 and 02 is in right order. Wondering why this
>modification happened.
>
The order of sections in drafts has changed recently, so this change was
intended.

>#2
>section 3.2.2
>Proper alignments are needed for procedure description part. Usually no
>first line indent is needed for each step.
>In step 1, substeps are numbered as step 1.a and 1.b, without indents. But
>in step 4, substeps are numbered as 1, 2, ...7, with indents. The substeps
>of step 4 has the same numbering as top level steps.
>
Ok. I can ask RFC Editor to fix that.

>#3
>section 3.2.3
>I didn't understand the first sentence of this section:
> "The Unknown Header Fields' Preservation Header Fields SHOULD be left
> as they are unless the MUA has special knowledge of a particular
> field. "
>
>
Downgrade document specifies a way to preserve "unknown" header fields
(i.e. header fields not known to the downgrade process). This sentence
is trying to say that a client that understands a specific "unknown"
header field, may apply the procedure defined in the downgrade-display
document. Otherwise such header fields should be left as is.

>Also I noticed that "above" and "below" are used in a few places. These are
>not necessary when you already clearly refer to the exact sections.
>
>
I will let editors to comment on the rest of your comments.

>#4
>section 4
>The first paragraph describes a scenario that "Downgraded-From" header field
>can not be reconstructed. But it's not clear then what will happen. Any
>security effects?
>The last paragraph refer to "security considerations" in rfc5504 and
>rfc4952. But the security considerations in those documents are more about
>security issues for downgrading mechenisms. I suppose the security
>consideratioins in this document focuses more on downgraded-display. This
>should be clarified.
>
>Best,
>
>Sean
>

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

SPAM 6.265 (5) 答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-04T00:07:56Z

> > when can we have a discussion about recharter work?
>
> +1 :)

+1

Sean

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

SPAM 10.627 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-03T17:04:12Z

----- Original Message -----
From: "Shawn Steele" <Shawn.Steele@...>
To: "YAO Jiankang" <yaojk@...>; <ima@...>
Sent: Friday, December 04, 2009 4:32 AM
Subject: Re: [EAI] I-D Action:draft-ietf-eai-downgraded-display-03.txt

>>> I guess my concern is more procedural or process oriented, however
>>> it seems from earlier discussion that the consensus is that the
>>> downgrade as specified by RFC5504 doesn't work in all cases.
>
>> yes, it is. the test already proves it.
>
> I believe that there were serious problems maintaining the pairing once you hit things like mailing lists and mailto:

I share the same concern with you about mailing lists and mailto: when doing the downgrade or carring the alt-address.

>
> Alternatives discussed on the list were no downgrade, more partial downgrade, and what full downgrade would entail. RFC5504 was an attempt at full >downgrade, but it breaks in the edge cases and ends up being partial downgrade :(

+1

>
>> when can we have a discussion about recharter work?
>
> +1 :)
>
> - Shawn
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-03T12:32:36Z

>> I guess my concern is more procedural or process oriented, however
>> it seems from earlier discussion that the consensus is that the
>> downgrade as specified by RFC5504 doesn't work in all cases.

> yes, it is. the test already proves it.

I believe that there were serious problems maintaining the pairing once you hit things like mailing lists and mailto:

Alternatives discussed on the list were no downgrade, more partial downgrade, and what full downgrade would entail. RFC5504 was an attempt at full downgrade, but it breaks in the edge cases and ends up being partial downgrade :(

> when can we have a discussion about recharter work?

+1 :)

- Shawn

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: SPAM 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

2009-12-03T04:08:20Z

I looked into another plugin (for Outlook instead of Outlook Express)
from Verisign before, they don't support IDN at local-part.

best,
Joseph

On 3-Dec-09, at 2:33 AM, YAO Jiankang wrote:

> I send it a few days ago, but is regarded as the spam. :)
> I just remove the spam filter rule from ima list. :)
>
> ----- Original Message -----
> From: YAO Jiankang
> To: EAI WG
> Sent: Wednesday, November 25, 2009 11:28 AM
> Subject: verisign plug in supports the form ASCII@IDN in the outlook
> express
>
>
>
>
> I just get a news from my SGNIC friend that verisign plug in has
> supported the form ASCII@IDN in the outlook express.
>
> http://www.idnnow.com/index.jsp?lang=en
>
>
> but not sure whether it supports the form of non-ASCII@IDN.
>
>
> Yao Jiankang
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

SPAM 12.865 (5) Re: EAI WG status and rechartering

2009-12-03T01:22:52Z

----- Original Message -----
From: "Alexey Melnikov" <alexey.melnikov@...>
To: <ima@...>
Sent: Saturday, November 21, 2009 2:08 AM
Subject: [EAI] EAI WG status and rechartering

thanks AD for pointing it.

> While I am waiting for the 3 documents, I think the WG can start
> discussion about whether the group should shut down or recharter.

I hope that we can recharter.

The final aim of this WG is to move the documents to standard track.
EAI work is very hard. The co-chairs harald and xiaodong do an excellent job.
We have already survived the most difficult periond under the leading of chairs and key efforts of all WG members.

>In
> case there is consensus to recharter, I would like to see if updated
> charter text can be agreed on.

It is better if the chairs can provide some initial recharter document.

>
> If the WG has enough energy to recharter, I would also like to ask the
> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
> additional deliverable.

it is good if it can be dilivered before recharter, or this document is done in the WG with the new charter.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-03T01:06:22Z

Hi, EAI WG and Authors,
I read the draft and have the a few comments.

#1
Usually the "Abstract" is after "Status of this Memo" and "Copyright
Notice", right before the "Table of Contents". I went back to check previous
versions and found that 01 and 02 is in right order. Wondering why this
modification happened.

#2
section 3.2.2
Proper alignments are needed for procedure description part. Usually no
first line indent is needed for each step.
In step 1, substeps are numbered as step 1.a and 1.b, without indents. But
in step 4, substeps are numbered as 1, 2, ...7, with indents. The substeps
of step 4 has the same numbering as top level steps.

#3
section 3.2.3
I didn't understand the first sentence of this section:
"The Unknown Header Fields' Preservation Header Fields SHOULD be left
as they are unless the MUA has special knowledge of a particular
field. "

Also I noticed that "above" and "below" are used in a few places. These are
not necessary when you already clearly refer to the exact sections.

#4
section 4
The first paragraph describes a scenario that "Downgraded-From" header field
can not be reconstructed. But it's not clear then what will happen. Any
security effects?
The last paragraph refer to "security considerations" in rfc5504 and
rfc4952. But the security considerations in those documents are more about
security issues for downgrading mechenisms. I suppose the security
consideratioins in this document focuses more on downgraded-display. This
should be clarified.

Best,

Sean

> -----邮件原件-----
> 发件人: ima-bounces@... [mailto:ima-bounces@...] 代表
> Internet-Drafts@...
> 发送时间: 2009年12月1日 18:15
> 收件人: i-d-announce@...
> 抄送: ima@...
> 主题: [EAI] I-D Action:draft-ietf-eai-downgraded-display-03.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Email Address Internationalization
Working

> Group of the IETF.
>
>
> Title : Displaying Downgraded Messages for Email Address
> Internationalization
> Author(s) : K. Fujiwara, B. Leiba
> Filename : draft-ietf-eai-downgraded-display-03.txt
> Pages : 15
> Date : 2009-12-01
>
> This document describes a method for displaying downgraded messages which
> originally contained internationalized E-mail addresses or

internationalized
> header fields.
>
> Status of this Memo
>
> This Internet-Draft is submitted to IETF in full conformance with the
provisions
> of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering Task
Force
> (IETF), its areas, and its working groups. Note that other groups may
also
> distribute working documents as Internet- Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months and
> may be updated, replaced, or obsoleted by other documents at any time. It
is

> inappropriate to use Internet-Drafts as reference material or to cite them
> other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on June 4, 2010.
>
> Copyright Notice
>
> Copyright (c) 2009 IETF Trust and the persons identified as the document
> authors. All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal Provisions
> Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of

publication of this
> document. Please review these documents carefully, as they describe your
> rights and restrictions with respect to this document. Code Components
> extracted from this document must include Simplified BSD License text as
> described in Section 4.e of the Trust Legal Provisions and are provided
without
> warranty as described in the BSD License.
>
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-eai-downgraded-display-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

SPAM 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

2009-12-02T23:33:05Z

I send it a few days ago, but is regarded as the spam. :)

I just remove the spam filter rule from ima list. :)

----- Original Message -----

From: yaojk@...

To: ima@...

Sent: Wednesday, November 25, 2009 11:28 AM

Subject: verisign plug in supports the form ASCII@... in the outlook express

I just get a news from my SGNIC friend that verisign plug in has supported the form ASCII@... in the outlook express.

http://www.idnnow.com/index.jsp?lang=en

but not sure whether it supports the form of non-ASCII@....

Yao Jiankang

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

SPAM 14.304 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-02T23:27:55Z

----- Original Message -----
From: "Shawn Steele" <Shawn.Steele@...>
To: <ima@...>
Sent: Thursday, December 03, 2009 8:37 AM
Subject: Re: [EAI] I-D Action:draft-ietf-eai-downgraded-display-03.txt

>> Dear WG members,
>> I would like the WG to sanity check the new version, as this is a major rewrite of 2 sections of the document. Please send any > comments by the end of December 11th.
>
> I guess my concern is more procedural or process oriented, however it seems from earlier discussion that the consensus is that the downgrade as specified by >RFC5504 doesn't work in all cases.

yes, it is. the test already proves it.

>So that would seem to make eai-downgraded-display an historical footnote, and I'm not sure how much effort it is worth spending on it? The working group >seems to have moved to considering other options.

so we might try to design a simplified downgrade mechanism.

> I'm not sure if downgraded display is required for the charter? I'd thought yes, but it doesn't seem to be in the
>1.6 Deliverables section?

I think that downgraded display is not proper for the recharter. but I am not sure whether the current charter allow it. The co-chairs can decide it.

>
> It also seems that if it is published, that a note of the limitations that have been discovered since RFC5504 was published should be added. Of course one of the >other deliverables is a "Results and evaluation of experiment",

"Results and evaluation of experiment" is a kind of good deliverable. I think that draft-yao-eai-downgrade-tests-analysis-00.txt is one of them.

> however it might be difficult for people that stumble upon downgraded display to get to that >informational RFC.

I understand your concerns.

>
> I'm not trying to belittle the work involved in getting this far. I think that the RFC5504 approach was a very valuable learning experience, and indeed I preferred >that approach. I just think that at this point it's not worth perfecting that approach if we aren't going to use it, and instead focus our time and experimentation >effort on other possible solutions.

as it is dicussed before,
we might focus the 2 directions of recharter:

recharter without downgrading
or recharter with the downgrading.

I appreciate the concerns of Shaw.
since the next ietf meeting is coming soon, I agree with Shawn that we should focus more on the recharter work.

To Co-chairs:

when can we have a discussion about recharter work?

Yao Jiankang.

>
> -Shawn
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-02T16:37:29Z

> Dear WG members,
> I would like the WG to sanity check the new version, as this is a major rewrite of 2 sections of the document. Please send any > comments by the end of December 11th.

I guess my concern is more procedural or process oriented, however it seems from earlier discussion that the consensus is that the downgrade as specified by RFC5504 doesn't work in all cases. So that would seem to make eai-downgraded-display an historical footnote, and I'm not sure how much effort it is worth spending on it? The working group seems to have moved to considering other options. I'm not sure if downgraded display is required for the charter? I'd thought yes, but it doesn't seem to be in the 1.6 Deliverables section?

It also seems that if it is published, that a note of the limitations that have been discovered since RFC5504 was published should be added. Of course one of the other deliverables is a "Results and evaluation of experiment", however it might be difficult for people that stumble upon downgraded display to get to that informational RFC.

I'm not trying to belittle the work involved in getting this far. I think that the RFC5504 approach was a very valuable learning experience, and indeed I preferred that approach. I just think that at this point it's not worth perfecting that approach if we aren't going to use it, and instead focus our time and experimentation effort on other possible solutions.

-Shawn

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-02T04:23:02Z

Internet-Drafts@... wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the Email Address Internationalization Working Group of the IETF.
>
>
> Title : Displaying Downgraded Messages for Email Address Internationalization
> Author(s) : K. Fujiwara, B. Leiba
> Filename : draft-ietf-eai-downgraded-display-03.txt
> Pages : 15
> Date : 2009-12-01
>
>This document describes a method for displaying downgraded messages
>which originally contained internationalized E-mail addresses or
>internationalized header fields.
>
>

Dear WG members,
I would like the WG to sanity check the new version, as this is a major
rewrite of 2 sections of the document. Please send any comments by the
end of December 11th.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

I-D Action:draft-ietf-eai-downgraded-display-03.txt

2009-12-01T02:15:01Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

Title : Displaying Downgraded Messages for Email Address Internationalization
Author(s) : K. Fujiwara, B. Leiba
Filename : draft-ietf-eai-downgraded-display-03.txt
Pages : 15
Date : 2009-12-01

This document describes a method for displaying downgraded messages
which originally contained internationalized E-mail addresses or
internationalized header fields.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 4, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-downgraded-display-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

draft-ietf-eai-downgraded-display-03.txt (73 bytes) Download Attachment

Document Action: 'IMAP Support for UTF-8' to Experimental RFC

2009-11-30T10:54:14Z

The IESG has approved the following document:

- 'IMAP Support for UTF-8 '
<draft-ietf-eai-imap-utf8-09.txt> as an Experimental RFC

This document is the product of the Email Address Internationalization Working Group.

The IESG contact persons are Alexey Melnikov and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-09.txt

Technical Summary
This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support unencoded international
characters in user names, mail addresses and message headers.

Working Group Summary

The WG has consensus on the mechanisms described in this
document.

Document Quality

Alexey Melnikov has reviewed this document most carefully
before he became AD.
One implementation of the document is known.

Personnel

Harald Alvestrand is the document shepherd.
Alexey Melnikov is the Responsible Area Director.

RFC Editor Note

In Section 2, the last sentence:

OLD:
This
specification creates five new IMAP capabilities to allow servers to
advertise these new extensions, along with two new IMAP list
^^^^
extensions and a new IMAP list return option.

NEW:
This
specification creates five new IMAP capabilities to allow servers to
advertise these new extensions, along with two new IMAP LIST selection
^^^^^^^^^^^^^^
options and a new IMAP list return option.
^^^^^^^

In Section 3, 2nd paragraph, the last 2 sentences:

OLD:
(Note that the "UTF8=ONLY" capability
described in Section 7 implies the "UTF8=ACCEPT" capability. See
additional information in that section.)

NEW:
(Note that the "UTF8=ONLY" capability
described in Section 7 and the "UTF8=ALL" capability
described in Section 6 imply the "UTF8=ACCEPT" capability. See
additional information in these sections.)

Section 3.1., paragraph 7:

> would be the same as if other syntacticly valid but semantically

Nit: s/syntacticly/syntactically/

Section 3.4., paragraph 1:

> "LIST-EXTENEDED" [RFC5258] capability, the server MUST support the

Nit: s/"LIST-EXTENEDED"/"LIST-EXTENDED"/

In Section 5, please change the last sentence to read:
OLD:
The server MUST reject UTF-8
which fails to comply with the formal syntax in RFC 3629 [RFC3629].

NEW:
The server MUST reject UTF-8 which fails to comply with the formal
syntax in RFC 3629 [RFC3629] or if it encounters a Unicode characters
listed in section 2.3 of SASLprep [RFC4013].

In Section 6 add another paragraph to the end:

NEW:
Note that the "UTF8=ALL" capability implies
the "UTF8=ACCEPT" capability.

In Section 8, change the last sentence of the 3rd paragraph to read:

OLD:
Other widely deployed MIME charsets SHOULD be supported.

NEW:
If the server supports other charsets in IMAP SEARCH or IMAP
CONVERT [RFC5259], it SHOULD also support
those charsets in this conversion.

and also add [RFC5259] to the list of Normative References.

Add a new Appendix B "Examples demonstrating relationships between UTF8=
capabilities":

UTF8=ACCEPT UTF8=USER UTF8=APPEND
UTF8=ACCEPT UTF8=ALL
UTF8=ALL ; Note, same as above
UTF8=ACCEPT UTF8=USER UTF8=APPEND UTF8=ALL UTF8=ONLY
UTF8=USER UTF8=ONLY ; Note, same as above

In the IANA Considerations section please replace "RFC XXXX" with the RFC
number of this document.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: (Re: EAI WG status and rechartering) -- mailto bis

2009-11-30T10:31:44Z

On 30-Nov-09, at 2:45 AM, Martin J. Dürst wrote:

> Hello Joseph,
>
> On 2009/11/27 1:48, Joseph Yee wrote:
>> Hi Martin,
>>
>> I read the latest mailto-bis (07). Section 2.4 and 2.5 are great.
>
> These are just point 4 and 5 in a numbered list within Section 2,
> but thanks for your review and comments, anyway.

yes, my mistake there.

>
>> In the paragraph right after section 2.5, it mentions the pct-
>> encoding
>> for <hfname> and <hfvalue>. My own interpretation had it sounds like
>> allowing <hfname> to be pct-encoded. Since current and proposed
>> message
>> header definition do not allow non ASCII characters, wouldn't that be
>> easier to limit <hfname> to ASCII only? That would make <hfname> be
>> case
>> insensitive easier to manage too.
>
> Okay, so you are proposing to change the grammar from:
>
> hfname = *qchar
>
> (with qchar being unreserved / pct-encoded / some-delims) to:
>
> hfname = unreserved
>
> On the face of it, that may seem okay. But looking at things in
> detail, it isn't. Optional header field names, as defined in RFC
> 5322 (see http://tools.ietf.org/html/rfc5322#section-3.6.8) can
> include any printable ASCII character except ":". So for whatever
> reason, and however unlikely, there may be a header field named
> "#browns" (an abbreviation for "hashbrowns"), where the "#" would
> need escaping in a mailto: URI. This would lead to an example such as:
>
> mailto:frypan@...?%23browns=diced-with-bacon
>
> Which would translate to a mail containing:
>
> To: frypan@...
> #browns: diced-with-bacon
>
> So even if this example is quite silly, we can essentially not
> remove pct-encoded from the production. This means that software
> interpreting the mailto: URI has to reverse the %-escaping on
> hfnames, anyway.
>
> Do you think we need such an example? I hope not, but if you think
> it would help, I'd also appreciate ideas for a somewhat better
> example.

I agreed with you, there are still non alphabets in hfname. The
suggested restriction would not help.

For example, maybe header X-something? It's not common either,but
would show escaping in header name and I don't think we need such
example.

Thanks for your explanation, Martin.

Regards,
Joseph

>
>
>> I noticed that section 4 would stop
>> non ASCII in <hfname>, but wonder if it's good to restrict it in
>> mailto
>> IRI.
>
> Yes, you are correct, section 4 would essentially stop non-ASCII as
> well as most ASCII, too.
>
> Regards, Martin.
>
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: (Re: EAI WG status and rechartering) -- mailto bis

2009-11-29T23:45:01Z

Hello Joseph,

On 2009/11/27 1:48, Joseph Yee wrote:
> Hi Martin,
>
> I read the latest mailto-bis (07). Section 2.4 and 2.5 are great.

These are just point 4 and 5 in a numbered list within Section 2, but
thanks for your review and comments, anyway.

> In the paragraph right after section 2.5, it mentions the pct-encoding
> for <hfname> and <hfvalue>. My own interpretation had it sounds like
> allowing <hfname> to be pct-encoded. Since current and proposed message
> header definition do not allow non ASCII characters, wouldn't that be
> easier to limit <hfname> to ASCII only? That would make <hfname> be case
> insensitive easier to manage too.

Okay, so you are proposing to change the grammar from:

hfname = *qchar

(with qchar being unreserved / pct-encoded / some-delims) to:

hfname = unreserved

On the face of it, that may seem okay. But looking at things in detail,
it isn't. Optional header field names, as defined in RFC 5322 (see
http://tools.ietf.org/html/rfc5322#section-3.6.8) can include any
printable ASCII character except ":". So for whatever reason, and
however unlikely, there may be a header field named "#browns" (an
abbreviation for "hashbrowns"), where the "#" would need escaping in a
mailto: URI. This would lead to an example such as:

mailto:frypan@...?%23browns=diced-with-bacon

Which would translate to a mail containing:

To: frypan@...
#browns: diced-with-bacon

So even if this example is quite silly, we can essentially not remove
pct-encoded from the production. This means that software interpreting
the mailto: URI has to reverse the %-escaping on hfnames, anyway.

Do you think we need such an example? I hope not, but if you think it
would help, I'd also appreciate ideas for a somewhat better example.

> I noticed that section 4 would stop
> non ASCII in <hfname>, but wonder if it's good to restrict it in mailto
> IRI.

Yes, you are correct, section 4 would essentially stop non-ASCII as well
as most ASCII, too.

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

I-D Action:draft-ietf-eai-imap-utf8-09.txt

2009-11-29T15:30:02Z

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Email Address Internationalization Working Group of the IETF.

Title : IMAP Support for UTF-8
Author(s) : P. Resnick, C. Newman
Filename : draft-ietf-eai-imap-utf8-09.txt
Pages : 15
Date : 2009-11-29

This specification extends the Internet Message Access Protocol
version 4rev1 (IMAP4rev1) to support UTF-8 encoded international
characters in user names, mail addresses and message headers.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 3, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eai-imap-utf8-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

draft-ietf-eai-imap-utf8-09.txt (73 bytes) Download Attachment

AD review of draft-ietf-eai-mailinglist-04.txt

2009-11-28T09:04:27Z

I think the document is very close to being ready for publication as an
Experimental RFC.

Below are some comments:

2. Introduction

In most cases, the mailing list agent redistributes a received
message to its subscribers as a new message, that is, conceptually
it uses message submission [submit]

This is not listed as a reference. I assume it should be Informative.

(as did the sender of the
original message). The exception, where the mailing list is not a
separate agent that receives and redistributes messages in separate
transactions, but is instead an expansion step within an SMTP
transaction where one local address expands to multiple local or
non-local addresses, is out of scope for this document.

[...]

There are considerations for internationalized email addresses in
the envelope as well as

"in" missing here?

header fields of redistributed messages. In
particular, an internationalized message cannot be downgraded unless
envelope addresses are in ASCII (which includes use of ALT-ADDRESS).

I would suggest rewording this to make it clear that either envelope
addresses are in ASCII, or ALT-ADDRESSes for them are available.

3. Scenarios Involving Mailing Lists

The submission server then decides
which recipients to include in whi ch transaction.)

nit: which

4. Capabilities and Requirements

1. If the list uses a UTF8 submission or return-path address, it
SHOULD specify an alt-address for it. Clearly, it needs to sit
behind a UTF8SMTP-enabled final-delivery SMTP server and delivery
agent.

I think this needs an Informative reference to RFC 5336.

Likewise, if a list uses a UTF8 return-path address, then
its MSA needs

I recommend an Informative reference to RFC 5598 here.

to support UTF8SMTP.

5. List Header Fields

Even without these header fields being extended to support UTF8,
some special provisions may be helpful when downgrading. In
particular, when a List-* header contains a UTF8 mailto (even
encoded in ASCII) followed by an ASCII mailto, it may be advisable
to not only copy and preserve the original header as usual, but also
to edit the header to remove the UTF8 address. Otherwise, a
non-UTF8-aware client might run into trouble if the decoded mailto
results in a non-ASCII address. [[[EDITOR'S NOTE: This needs to be
vetted by the eai list.]]]

I think this is sensible.

But note that currently mailto-bis doesn't directly allow UTF-8 in LHS
of addresses. This will be dealt with when the WG recharters (hopefully).

The List-ID header filed uniquely identifies a list. The intent is
that the value of this header remain constant, even if the machine
or system used to operate and host the list changes. This header
field is often used in various filters and tests, such as
client-side filters, Sieve filters, and so forth. Because of this,
great care should be taken, as a non-ASCII value might not match
when encoded into ASCII. It is generally desirable that this header
field contain something meaningful that users can type in. However,
non-ASCII characters encoded into ASCII are unlikely to be
meaningful to users or easy for them to accurately type.

I think that we should make it simple and just say that any List-ID is
all-ASCII (for the reasons
you specified) the same way as we did for the Message-ID header field.
And informational suggestion to use punycode version of domain names
can be added, if needed.

6. Further Discussion

1. Obtaining Downgrade Information -- for a mailing list, or mail
relay server for that matter, that is UTF8SMTP-aware, receiving mail
from an internationalized email address, the alt-address is not
required from the sending MTA for the transport to be complete.
Thereupon when the mailing list retransmits the message to its
subscribers, it may encounter paths where a downgrade is called for.
In order to mitigate this situation, the mailing list might perhaps
decide to reject all incoming mail from an internationalized email
address that lacks an alt-address.

An alternative would be to require that all subscribers be UTF8SMTP-aware.
I think this would become the more common alternative over time, if EAI
takes off.

However, note that in general,
downgrades are not expected to be the normal case.

11. Informative References

[mailto-bis] M. Duerst and L. Masinter, "The mailto URI scheme",
draft-duerst-mailto-bis-xx (work in progress).

[List-*] G. Neufeld and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message Header
Fields", July 1998

[List-ID] R. Chandhok and G. Wenger, "List-Id: A Structured Field
and Namespace for the Identification of Mailing Lists", March 2001

[IRI] M. Duerst and M. Suignard,"Internationalized Resource
Identifiers (IRIs)", January 2005

The last 3 documents are lacking RFC numbers.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: EAI WG status and rechartering

2009-11-28T06:11:19Z

Martin J. Dürst wrote:

> Hello Alexey,
>
> On 2009/11/21 3:08, Alexey Melnikov wrote:
>
>> If the WG has enough energy to recharter, I would also like to ask the
>> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
>> additional deliverable.
>
> I'm not sure this makes sense, for two reasons:
>
> - While draft-duerst-mailto-bis is very much about internationalization
> (it allows non-ASCII characters in things such as Subject and body,
> which the current RFC doesn't), it isn't actually about EAI
>
> - The draft has already been out for quite a long time, it doesn't seem
> to make sense to wait for other EAI drafts to complete and then the
> WG to recharter to move on.

I agree with both statements.

> That said, it would be possible (I'd even say appropriate) for a
> rechartered WG to take up the job of either further updating what
> might by that time be the RFC resulting from draft-duerst-mailto-bis
> (essentially continuing what was
> http://tools.ietf.org/html/draft-ietf-eai-mailto-01), or of creating a
> new URI/IRI scheme for EAI mail addresses. [I'd be glad to volunteer
> as an editor in either case.]

Yes, I mostly meant this work item.

I think that draft-duerst-mailto-bis is essentially ready for IETF LC.
If no major objections are raised during IETF LC, then it can be
published as an RFC. However if there are some objections, the document
might require a new or existing WG to help build/judge consensus.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

(Re: EAI WG status and rechartering) -- mailto bis

2009-11-26T08:48:06Z

Hi Martin,

I read the latest mailto-bis (07). Section 2.4 and 2.5 are great.

In the paragraph right after section 2.5, it mentions the pct-encoding
for <hfname> and <hfvalue>. My own interpretation had it sounds like
allowing <hfname> to be pct-encoded. Since current and proposed
message header definition do not allow non ASCII characters, wouldn't
that be easier to limit <hfname> to ASCII only? That would make
<hfname> be case insensitive easier to manage too. I noticed that
section 4 would stop non ASCII in <hfname>, but wonder if it's good to
restrict it in mailto IRI.

Regards,
Joseph

On 23-Nov-09, at 4:34 AM, Martin J. Dürst wrote:

> Hello Alexey,
>
>
> On 2009/11/21 3:08, Alexey Melnikov wrote:
>
>> If the WG has enough energy to recharter, I would also like to ask
>> the
>> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
>> additional deliverable.
>
> I'm not sure this makes sense, for two reasons:
>
> - While draft-duerst-mailto-bis is very much about
> internationalization
> (it allows non-ASCII characters in things such as Subject and body,
> which the current RFC doesn't), it isn't actually about EAI
>
> - The draft has already been out for quite a long time, it doesn't
> seem
> to make sense to wait for other EAI drafts to complete and then the
> WG to recharter to move on.
>
> That said, it would be possible (I'd even say appropriate) for a
> rechartered WG to take up the job of either further updating what
> might by that time be the RFC resulting from draft-duerst-mailto-bis
> (essentially continuing what was http://tools.ietf.org/html/draft-ietf-eai-mailto-01)
> , or of creating a new URI/IRI scheme for EAI mail addresses. [I'd
> be glad to volunteer as an editor in either case.]
>
> Also, it's never too late for anybody in this WG to have a look at
> draft-duerst-mailto-bis (currently at http://tools.ietf.org/html/draft-duerst-mailto-bis-07)
> . Any kinds of reviews are appropriate, but with respect to WG
> matters, I'd want in particular to point out the following two items
> (not EAI per se, but definitely related) in Section 2, "Syntax of a
> 'mailto' URI":
>
> 4. Percent-encoding can be used in the <domain> part of an <addr-
> spec>, in order to denote an internationalized domain name. The
> considerations for <reg-name> in [STD66] apply. In particular,
> non-ASCII characters MUST first be encoded according to UTF-8
> [STD63], and then each octet of the corresponding UTF-8 sequence
> MUST be percent-encoded to be represented as URI characters.
> URI
> producing applications MUST NOT use percent-encoding in domain
> names unless it is used to represent a UTF-8 character sequence.
> When the internationalized domain name is used to compose a
> message, the name MUST be transformed to the IDNA encoding where
> appropriate [RFC3490]. URI producers SHOULD provide these
> domain
> names in the IDNA encoding, rather than percent-encoded, if they
> wish to maximize interoperability with legacy 'mailto' URI
> interpreters.
>
> 5. Percent-encoding of non-ASCII octets in the <local-part> of an
> <addr-spec> is reserved for the internationalization of the
> <local-part>. Non-ASCII characters MUST first be encoded
> according to UTF-8 [STD63], and then each octet of the
> corresponding UTF-8 sequence MUST be percent-encoded to be
> represented as URI characters. Any other percent-encoding of
> non-ASCII characters is prohibited. When a <local-part>
> containing non-ASCII characters will be used to compose a
> message, the <local-part> MUST be transformed to conform to
> whatever encoding may be defined in a future specification for
> the internationalization of email addresses.
>
>
> Regards, Martin.
>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: EAI WG status and rechartering

2009-11-23T05:02:13Z

On Fri, 20 Nov 2009 18:08:17 -0000, Alexey Melnikov
<alexey.melnikov@...> wrote:

> While I am waiting for the 3 documents, I think the WG can start
> discussion about whether the group should shut down or recharter. In
> case there is consensus to recharter, I would like to see if updated
> charter text can be agreed on.

If we are going to recharter, then an additional piece of work could be to
do EAI for Netnews. This would be mostly straightforward, since the
distrubution channels for Netnews (NNTP and UUCP) are already 8-bit clean,
and have been so for years, and so downgrading would only be needed when
netnews was gatewayed to an email list.

So the only additional work would be to define an EAI extension for the
Newsgroups header, enabling newsgroups with non-ASCII names to be formed.
The USEFOR WG did much work on that a few years back, and tests indicated
that such newsgroups would indeed progagate fine (a non-ascii group under
dk.* was created for the purpose). But the work was shelved pending
completion of other work. This job is nominally still on the agenda for
the USEFOR WG, but that group has struggled to get its main two drafts out
of the door (to be published imminently as RFC5536/7), and it is unlikely
to survive further. So moving that item to this group would make sense. I
could probably persuade a few News experts to come here to finish it off,
and would be happy to produce a draft based on what USEFOR did earlier.

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
   Web: http://www.cs.man.ac.uk/~chl
Email: chl@...      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
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: EAI WG status and rechartering

2009-11-23T01:34:07Z

Hello Alexey,

On 2009/11/21 3:08, Alexey Melnikov wrote:

> If the WG has enough energy to recharter, I would also like to ask the
> WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
> additional deliverable.

I'm not sure this makes sense, for two reasons:

- While draft-duerst-mailto-bis is very much about internationalization
(it allows non-ASCII characters in things such as Subject and body,
which the current RFC doesn't), it isn't actually about EAI

- The draft has already been out for quite a long time, it doesn't seem
to make sense to wait for other EAI drafts to complete and then the
WG to recharter to move on.

That said, it would be possible (I'd even say appropriate) for a
rechartered WG to take up the job of either further updating what might
by that time be the RFC resulting from draft-duerst-mailto-bis
(essentially continuing what was
http://tools.ietf.org/html/draft-ietf-eai-mailto-01), or of creating a
new URI/IRI scheme for EAI mail addresses. [I'd be glad to volunteer as
an editor in either case.]

Also, it's never too late for anybody in this WG to have a look at
draft-duerst-mailto-bis (currently at
http://tools.ietf.org/html/draft-duerst-mailto-bis-07). Any kinds of
reviews are appropriate, but with respect to WG matters, I'd want in
particular to point out the following two items (not EAI per se, but
definitely related) in Section 2, "Syntax of a 'mailto' URI":

4. Percent-encoding can be used in the <domain> part of an <addr-
spec>, in order to denote an internationalized domain name. The
considerations for <reg-name> in [STD66] apply. In particular,
non-ASCII characters MUST first be encoded according to UTF-8
[STD63], and then each octet of the corresponding UTF-8 sequence
MUST be percent-encoded to be represented as URI characters. URI
producing applications MUST NOT use percent-encoding in domain
names unless it is used to represent a UTF-8 character sequence.
When the internationalized domain name is used to compose a
message, the name MUST be transformed to the IDNA encoding where
appropriate [RFC3490]. URI producers SHOULD provide these domain
names in the IDNA encoding, rather than percent-encoded, if they
wish to maximize interoperability with legacy 'mailto' URI
interpreters.

5. Percent-encoding of non-ASCII octets in the <local-part> of an
<addr-spec> is reserved for the internationalization of the
<local-part>. Non-ASCII characters MUST first be encoded
according to UTF-8 [STD63], and then each octet of the
corresponding UTF-8 sequence MUST be percent-encoded to be
represented as URI characters. Any other percent-encoding of
non-ASCII characters is prohibited. When a <local-part>
containing non-ASCII characters will be used to compose a
message, the <local-part> MUST be transformed to conform to
whatever encoding may be defined in a future specification for
the internationalization of email addresses.

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: IMEAI WG status and rechartering (Alexey Melnikov)

2009-11-21T10:48:48Z

I don't think eai-downgraded display is interesting. It is intended for the original downgrade mechanism, which was proven not to work.

-Shawn

----------------------------------------------------------------------

Message: 1
Date: Fri, 20 Nov 2009 18:08:17 +0000
From: Alexey Melnikov <alexey.melnikov@...>
Subject: [EAI] EAI WG status and rechartering
To: "ima@..." <ima@...>
Message-ID: <4B06DB11.1080602@...>
Content-Type: text/plain; charset=us-ascii; format=flowed

Greetings,

Here is what I think remains to be done under the current WG charter:

1).
draft-ietf-eai-downgraded-display
draft-ietf-eai-imap-utf8

I am awaiting for updated versions of these documents before getting
them approved.

2). The following document is the last deliverable needed before
rechartering (I think):

draft-ietf-eai-mailinglist

Currently it is expired. Reissuing the document and sending it to WGLC
(if ready), would be nice.

While I am waiting for the 3 documents, I think the WG can start
discussion about whether the group should shut down or recharter. In
case there is consensus to recharter, I would like to see if updated
charter text can be agreed on.

If the WG has enough energy to recharter, I would also like to ask the
WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
additional deliverable.

Note that I also would be looking for at least 1 new WG chair. If you
want to volunteer yourself or somebody else, please send me an email
message with details directly.

Best Regards,
Alexey, Apps AD.
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

EAI WG status and rechartering

2009-11-20T10:08:17Z

Greetings,

Here is what I think remains to be done under the current WG charter:

1).
draft-ietf-eai-downgraded-display
draft-ietf-eai-imap-utf8

I am awaiting for updated versions of these documents before getting
them approved.

2). The following document is the last deliverable needed before
rechartering (I think):

draft-ietf-eai-mailinglist

Currently it is expired. Reissuing the document and sending it to WGLC
(if ready), would be nice.

While I am waiting for the 3 documents, I think the WG can start
discussion about whether the group should shut down or recharter. In
case there is consensus to recharter, I would like to see if updated
charter text can be agreed on.

If the WG has enough energy to recharter, I would also like to ask the
WG to take mailto: URI scheme update (draft-duerst-mailto-bis) as an
additional deliverable.

Note that I also would be looking for at least 1 new WG chair. If you
want to volunteer yourself or somebody else, please send me an email
message with details directly.

Best Regards,
Alexey, Apps AD.

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Slides of IAB presentation on Protocol I18N at IETF Technical Plenary

2009-11-13T00:55:36Z

[I'm using bcc because I'm sending this to various lists that I think
should be interested.]

For those who didn't attended yesterday's IETF Technical Plenary (or
like me, listened to it on the audio feed), here is a link to the slides
from the IAB presentation on Protocol Internationalization and Character
Encoding:

http://www.ietf.org/proceedings/09nov/slides/plenaryt-1.pdf

Regards, Martin.

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: BIDI & EAI

2009-11-13T00:48:26Z

Hello Shawn,

Please feel free to participate in the discussions in the IRI (and IDN)
lists and bring in your bidi-specific concerns. Ideally, we should have
a single story about how to display bidi identifiers, even if the story
isn't very good because the problem is extremely hard.

Regards, Martin.

On 2009/11/13 9:50, Shawn Steele wrote:

> That seems reasonable. I’m just thinking there’s been some discussion of BIDI in the IDN and IRI lists, so maybe EAI should be considered as well in those talks ☺
>
> -Shawn
>
> From: Xiaodong Lee [mailto:lee@...]
> Sent: tlherSjaj, nov'mber 12, DIS 2009 tera' 16:47
> To: Shawn Steele
> Cc: ima@...
> Subject: Re: [EAI] BIDI& EAI
>
> hi,
>
> BIDI and Variant problem should be solved in the future, now, we focus on the core protocol.
>
> If you have suggestions on that, you might submit the individual draft to this list.
>
> Regards,
> Xiaodong
>
> Shawn Steele wrote:
> Has there been any discussion on BIDI rendering of EAI addresses? Seems that there’re probably a few scenarios to think about.
>
> - Shawn
>
>  
> http://blogs.msdn.com/shawnste
>
>
>
>
> ________________________________
>
>
>
> _______________________________________________
>
> IMA mailing list
>
> IMA@...<mailto:IMA@...>
>
> https://www.ietf.org/mailman/listinfo/ima
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> IMA mailing list
> IMA@...
> https://www.ietf.org/mailman/listinfo/ima

--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp mailto:duerst@...
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: BIDI & EAI

2009-11-12T16:50:30Z

That seems reasonable. I’m just thinking there’s been some discussion of BIDI in the IDN and IRI lists, so maybe EAI should be considered as well in those talks J

-Shawn

From: Xiaodong Lee [mailto:lee@...]
Sent: tlherSjaj, nov'mber 12, DIS 2009 tera' 16:47
To: Shawn Steele
Cc: ima@...
Subject: Re: [EAI] BIDI & EAI

hi,

BIDI and Variant problem should be solved in the future, now, we focus on the core protocol.

If you have suggestions on that, you might submit the individual draft to this list.

Regards,
Xiaodong

Shawn Steele wrote:

Has there been any discussion on BIDI rendering of EAI addresses? Seems that there’re probably a few scenarios to think about.

- Shawn

 

http://blogs.msdn.com/shawnste

_______________________________________________

IMA mailing list

IMA@...

https://www.ietf.org/mailman/listinfo/ima

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Re: BIDI & EAI

2009-11-12T16:47:09Z

Has there been any discussion on BIDI rendering of EAI addresses? Seems that there’re probably a few scenarios to think about.

- Shawn

 

http://blogs.msdn.com/shawnste
_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima
  

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

BIDI & EAI

2009-11-12T13:07:15Z

Has there been any discussion on BIDI rendering of EAI addresses? Seems that there’re probably a few scenarios to think about.

- Shawn

 

http://blogs.msdn.com/shawnste

_______________________________________________
IMA mailing list
IMA@...
https://www.ietf.org/mailman/listinfo/ima

Nabble - IETF - IMA

***SPAM*** 11.038 (5) Re: EAI WG status and rechartering

Appointment of the EAI WG Secretary

Re: ´ð¸´: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: 答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

***SPAM*** 6.265 (5) 答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

***SPAM*** 10.627 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: ***SPAM*** 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

***SPAM*** 12.865 (5) Re: EAI WG status and rechartering

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

***SPAM*** 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

***SPAM*** 14.304 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

I-D Action:draft-ietf-eai-downgraded-display-03.txt

Document Action: 'IMAP Support for UTF-8' to Experimental RFC

Re: (Re: EAI WG status and rechartering) -- mailto bis

Re: (Re: EAI WG status and rechartering) -- mailto bis

I-D Action:draft-ietf-eai-imap-utf8-09.txt

AD review of draft-ietf-eai-mailinglist-04.txt

Re: EAI WG status and rechartering

(Re: EAI WG status and rechartering) -- mailto bis

Re: EAI WG status and rechartering

Re: EAI WG status and rechartering

Re: IMEAI WG status and rechartering (Alexey Melnikov)

EAI WG status and rechartering

Slides of IAB presentation on Protocol I18N at IETF Technical Plenary

Re: BIDI & EAI

Re: BIDI & EAI

Re: BIDI & EAI

BIDI & EAI

SPAM 11.038 (5) Re: EAI WG status and rechartering

SPAM 6.265 (5) 答复: I-D Action:draft-ietf-eai-downgraded-display-03.txt

SPAM 10.627 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt

Re: SPAM 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

SPAM 12.865 (5) Re: EAI WG status and rechartering

SPAM 14.01 (5) Fw: verisign plug in supports the form ASCII@IDN in the outlook express

SPAM 14.304 (5) Re: I-D Action:draft-ietf-eai-downgraded-display-03.txt