headers
Tony Hansen | 1 Oct 2010 03:01
Picon
Favicon

question on 5337bis

While preparing 5337 bis, Internationalized Delivery Status and 
Disposition Notifications, discussion with my co-authors brought up the 
question as to whether the registered names need to be changed.

In particular, Chris wrote to me:

----
If we assume the experiment never leaked, we can re-use names, I suppose.

Otherwise, we should consider changing names to avoid conflicts.  
Changing the address type from "utf-8" to, say, "utf8" would be simple 
to make it clear the new label can never have the <addr <addr>> syntax 
-- I presently lean towards doing that.

We don't have to change the notary media type 
(message/global-delivery-status), since the address type label change 
suffices.

But we might choose to change the type name for "message/global" and 
"message/global-headers" if we want to create a new type that disallows 
<addr <addr>> syntax for addresses.  However that change is less 
necessary since the simplified EAI proposal is a subset of the original 
media type.  I'd be inclined to just live with the possibility of leaked 
<addr <addr>> in message/global* just to avoid the pain of choosing a 
new type name for that.
----

So the questions to the mailing list is:

1) Should the address type be changed from UTF-8 to UTF8?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Shawn Steele | 1 Oct 2010 21:06
Picon
Favicon

Re: question on 5337bis


I personally don't think it's likely to have "leaked", and if it did "leak", then the people that knew about
it would fix it and want to update those anyway, so I can't get excited about changing the name.

-Shawn
----------------------------------------------------------------------
Date: Thu, 30 Sep 2010 21:01:13 -0400
From: Tony Hansen <tony <at> att.com>
Subject: [EAI] question on 5337bis
To: EAI WG <ima <at> ietf.org>
Message-ID: <4CA532D9.1080306 <at> att.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

While preparing 5337 bis, Internationalized Delivery Status and Disposition Notifications,
discussion with my co-authors brought up the question as to whether the registered names need to be changed.

In particular, Chris wrote to me:

----
If we assume the experiment never leaked, we can re-use names, I suppose.

Otherwise, we should consider changing names to avoid conflicts.  
Changing the address type from "utf-8" to, say, "utf8" would be simple to make it clear the new label can
never have the <addr <addr>> syntax
-- I presently lean towards doing that.

We don't have to change the notary media type (message/global-delivery-status), since the address type
label change suffices.

But we might choose to change the type name for "message/global" and "message/global-headers" if we want
(Continue reading)

Permalink | Reply | 0 comments |
headers
SM | 2 Oct 2010 17:16

Comments on draft-ietf-eai-rfc5335bis-02

Hello,

I read draft-ietf-eai-rfc5335bis-02 and I have a few comments.

In the Abstract Section:

   "This specification Updates"

That should be "updates".

In Section 1.2:

   "This document also updates [RFC5322] and MIME ([RFC2045]), and people
    who participate in the experiment have to swich to this document."

As the intended status of the document is Standards Track, the 
"participate in the experiment" is no longer applicable.  I suggest 
removing that sentence and adding:

   This document also updates RFC5322

at the end of the first paragraph of that section.

In Section 4:

   "To permit UTF-8 characters in field values, the header definition in
    [RFC5322] must be extended to support the new format."

I suggest the following to avoid the "must".
(Continue reading)

Permalink | Reply | 2 comments |
headers
SM | 2 Oct 2010 18:02

Comments on draft-ietf-eai-rfc5336bis-03

Hello,

I have a few comments about draft-ietf-eai-rfc5336bis-03.  In the 
Abstract Section:

   "Communication with systems that do not implement this
    specification is specified in another document."

I suggest removing that sentence.

In the Introduction Section:

   "An internationalized email address includes two parts, the local part
    and the domain part.  The ways email addresses are used by protocols
    are different from the ways domain names are used.  The most critical
    difference is that emails are delivered through a chain of clients
    and servers, while domain names are resolved by name servers looking
    up those names in their own tables."

The difference between email addresses and domain names is that the 
domain part of email addresses can be resolved using DNS at any point 
during message transit whereas the local-part can only be interpreted 
and assigned semantics by the host specified in the domain part of the address.

I suggest removing the "In addition to this,".

In Section 3.2:

   'If the original client submits a message to a Message Submission
    Server ("MSA") [RFC4409], it is the responsibility of the MSA that
(Continue reading)

Permalink | Reply | 0 comments |
headers
SM | 3 Oct 2010 12:00

Re: question on 5337bis

At 18:01 30-09-10, Tony Hansen wrote:
>While preparing 5337 bis, Internationalized Delivery Status and 
>Disposition Notifications, discussion with my co-authors brought up 
>the question as to whether the registered names need to be changed.

[snip]

I don't feel strongly about this.

>So the questions to the mailing list is:
>
>1) Should the address type be changed from UTF-8 to UTF8?

Yes, because to the syntax change.

>2) Should the internationalized notary media type change its name 
>from message/global-delivery-status?
>
>3) Should the internationalized message content type change its name 
>from message/global?
>
>4) Should the internationalized headers content type change its name 
>from message/global-headers?

No to the above as it is not much of a change from the original 
proposal.  It also avoids having to choose an appropriate name.

Regards,
-sm
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph Yee | 4 Oct 2010 16:53

Tentative schedule for IETF 79

All,

The tentative schedule for EAI at IETF 79 is published.  The WG scheduled to meet at Tuesday 9am (Nov 9 Beijing
local time).

https://datatracker.ietf.org/meeting/79/agenda.html

Please comment for potential conflicts & changes needed.

Thanks
Joseph
Permalink | Reply | 0 comments |
headers
Joseph Yee | 4 Oct 2010 20:55

Re: rfc5335bis and 5336bis ABNF

It is great that to have only one reference of ABNF, less likely to have editing mistakes, and we do have few
for RFC5335bis.

The 3 terms mentioned by Ernie are not in the docs, and they all were defined in the original RFC5336 (Section
3.3).  Since we are obsoleting both RFC5335 and RFC5336, it would be nice to include these references in the
current bis.  This would speed up IESG review too :)

Thanks
Joseph

On 2010-09-29, at 9:15 PM, Ernie Dainow wrote:

> Regarding Comment 2, The following are not defined anywhere. They should be added to rfc5335bis-02.
> uDomain
> uDot-String
> sub-uDomain
> 
> Here is the result of searching the two documents:
> 
> Search "uDot-String"
> draft-ietf-eai-rfc5335bis-02.txt
> Line 412: uLocal-Part    =  uDot-String / uQuoted-String
> 
> Search "sub-uDomain"
> draft-ietf-eai-rfc5335bis-02.txt
> Line 415:                =  (sub-uDomain 1*("." sub-uDomain)) / address-literal
> 
> So sub-uDomain and uDot-String need to be defined somewhere.
> 
> In rfc5336bis-03
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joseph Yee | 4 Oct 2010 21:50
Picon

Re: Comments on draft-ietf-eai-rfc5335bis-02

On Sat, Oct 2, 2010 at 11:16 AM, SM <sm <at> resistor.net> wrote:
> Hello,
>
> I read draft-ietf-eai-rfc5335bis-02 and I have a few comments.
>
> In the Abstract Section:
>
>  "This specification Updates"
>
> That should be "updates".

+1

>
> In Section 1.2:
>
>  "This document also updates [RFC5322] and MIME ([RFC2045]), and people
>   who participate in the experiment have to swich to this document."
>
> As the intended status of the document is Standards Track, the "participate
> in the experiment" is no longer applicable.  I suggest removing that
> sentence and adding:
>
>  This document also updates RFC5322
>
> at the end of the first paragraph of that section.

<individual>
Maybe mention the Experimental Draft? So that the whole thing says:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Joseph Yee | 4 Oct 2010 21:56

Re: rfc5335bis and 5336bis ABNF


On 2010-10-04, at 2:55 PM, Joseph Yee wrote:

> It is great that to have only one reference of ABNF, less likely to have editing mistakes, and we do have few
for RFC5335bis.
> 
> The 3 terms mentioned by Ernie are not in the docs, and they all were defined in the original RFC5336
(Section 3.3).  Since we are obsoleting both RFC5335 and RFC5336, it would be nice to include these
references in the current bis.  This would speed up IESG review too :)

correction: I meant to include these *definitions* in the current bis.

Joseph

> 
> Thanks
> Joseph
> 
> On 2010-09-29, at 9:15 PM, Ernie Dainow wrote:
> 
>> Regarding Comment 2, The following are not defined anywhere. They should be added to rfc5335bis-02.
>> uDomain
>> uDot-String
>> sub-uDomain
>> 
>> Here is the result of searching the two documents:
>> 
>> Search "uDot-String"
>> draft-ietf-eai-rfc5335bis-02.txt
>> Line 412: uLocal-Part    =  uDot-String / uQuoted-String
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin J. Dürst | 5 Oct 2010 03:31
Picon
Gravatar

Fwd: RFC 6068 on The 'mailto' URI Scheme

FYI.    Regards,   Martin.

(apologies if you get multiple copies)

-------- Original Message --------
Subject: RFC 6068 on The 'mailto' URI Scheme
Date: Mon,  4 Oct 2010 17:31:23 -0700 (PDT)
From: rfc-editor <at> rfc-editor.org
To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
CC: rfc-editor <at> rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

         RFC 6068

         Title:      The 'mailto' URI Scheme
         Author:     M. Duerst, L. Masinter,
                     J. Zawinski
         Status:     Standards Track
         Stream:     IETF
         Date:       October 2010
         Mailbox:    duerst <at> it.aoyama.ac.jp,
                     LMM <at> acm.org,
                     jwz <at> jwz.org
         Pages:      17
         Characters: 36683
         Obsoletes:  RFC2368

         I-D Tag:    draft-duerst-mailto-bis-10.txt
(Continue reading)

Permalink | Reply | 0 comments |

Gmane