Harald Tveit Alvestrand | 10 Jun 00:15 2008
Picon

Disposition of comments, Last Call on EAI documents

Based on the list of comments prepared by my co-chair, I have verified 
against the latest drafts the following dispositions.

I have called out those comments that have not resulted in changes in the 
drafts; I believe all others have been adequately addressed:

draft-ietf-eai-dsn-06:
  No comments requiring addressing.

draft-ietf-eai-smtpext-12:
  Comment from Frank ellermann on -11: Addressed.

  Comments from Miguel Garcia (gen-ART reviewer) on -11:
    A number of comments, all addressed in -12.

draft-ietf-eai-utf8headers-11:
  Comment from Spencer Dawkins (gen-ART reviewer) on -09:
    Most comments were addressed in -11. Some of them were
    replied to on the mailing list.
    Comment 7: the WG has  made a deliberate decision for
      message/global, and this will not be changed.
    Comment 8: Seems clear enough. Not changed.
    Comment 9: Mac typecode specific, probably clear to those
      who know about Mac UTIs.

  Comments from Frank Ellermann on -09 and -10:
     All addressed, except the comment about "message-id" vs
     "msg-id", and one NOTE IN DRAFT that has not been removed;
     the last one can be fixed with the RFC Editor.

(Continue reading)

Lisa Dusseault | 10 Jun 06:05 2008

Re: Disposition of comments, Last Call on EAI documents

As soon as Chris puts the others on the IESG agenda (Chris ping me  
when you do) I can put DSN on the agenda.

Lisa

On Jun 9, 2008, at 3:15 PM, Harald Tveit Alvestrand wrote:

> Based on the list of comments prepared by my co-chair, I have  
> verified against the latest drafts the following dispositions.
>
> I have called out those comments that have not resulted in changes  
> in the drafts; I believe all others have been adequately addressed:
>
> draft-ietf-eai-dsn-06:
> No comments requiring addressing.
>
> draft-ietf-eai-smtpext-12:
> Comment from Frank ellermann on -11: Addressed.
>
> Comments from Miguel Garcia (gen-ART reviewer) on -11:
>   A number of comments, all addressed in -12.
>
> draft-ietf-eai-utf8headers-11:
> Comment from Spencer Dawkins (gen-ART reviewer) on -09:
>   Most comments were addressed in -11. Some of them were
>   replied to on the mailing list.
>   Comment 7: the WG has  made a deliberate decision for
>     message/global, and this will not be changed.
>   Comment 8: Seems clear enough. Not changed.
>   Comment 9: Mac typecode specific, probably clear to those
(Continue reading)

SM | 10 Jun 17:44 2008
Picon

Re: Disposition of comments, Last Call on EAI documents

At 21:05 09-06-2008:
> > draft-ietf-eai-utf8headers-11:

I sent some comments on the above draft to the author.  I didn't get 
any feedback on them. There were minor language nits.

In Section 2:

   "Issues about how to handle messages that contain UTF-8
    header fields but are proposed to be delivered to systems that have
    not been upgraded to support this capability are discussed elsewhere,
    particularly in [I-D.ietf-eai-downgrade]."

I suggest a rewording:

    Issues such as how to handle messages containing UTF-8 header fields that
    have to be delivered to systems that have not been upgraded to support
    this capability are discussed in [I-D.ietf-eai-downgrade].

In Section 4:

   "To permit UTF-8 characters in field values, the header definition in
    [RFC2822] must be extended to support new format. The following ABNF
    is defined to substitute those definition in [RFC2822]."

You used field bodies in the previous paragraph.  You could use 
"field bodies" instead of "field values" in that sentence.  You are 
extending the header definition in this draft.  There's no need for 
the "must be".  I suggest:

(Continue reading)

Alexey Melnikov | 11 Jun 16:41 2008

Some quick comments on draft-ietf-eai-imap-utf8-03.txt

Hi Pete,
I've scanned through the diff between -02 and -03, and here are a couple 
of comments (I didn't read the whole draft in details):

In Section 3.3:

   When an IMAP server advertises the "UTF8" capability, the server MUST
   NOT return in LIST results any mailbox names to the client following
   the IMAP4 Mailbox International Naming Convention. Instead, the
   server MUST return any mailbox names with characters outside the US-ASCII
   repertorie using utf8-quoted syntax.

I think this text needs to make it clear that this behaviour is only 
enabled after ENABLE UTF-8. I.e. the server MUST NOT send mailboxes 
using utf8-quoted before ENABLE UTF-8

In Section 3.4.2:

   The \NoUTF8 mailbox attribute indicates an attempt to
   SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with
   a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute
   indicates an attempt to SELECT or EXAMINE that mailbox without the
   UTF8 parameter will fail with a [UTF-8-ONLY] response code.

This is missing ABNF. Suggested ABNF:

   resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"
Pete Resnick | 14 Jun 23:06 2008

Re: Some quick comments on draft-ietf-eai-imap-utf8-03.txt

On 6/11/08 at 3:41 PM +0100, Alexey Melnikov wrote:

>    When an IMAP server advertises the "UTF8" capability, the server MUST
>    NOT return in LIST results any mailbox names to the client following
>    the IMAP4 Mailbox International Naming Convention. Instead, the
>    server MUST return any mailbox names with characters outside the US-ASCII
>    repertorie using utf8-quoted syntax.
>
>I think this text needs to make it clear that this behaviour is only
>enabled after ENABLE UTF-8. I.e. the server MUST NOT send mailboxes
>using utf8-quoted before ENABLE UTF-8

I will make that clear in this paragraph.

>In Section 3.4.2:
>
>    The \NoUTF8 mailbox attribute indicates an attempt to
>    SELECT or EXAMINE that mailbox with the UTF8 parameter will fail with
>    a [NOT-UTF-8] response code. The \UTF8Only mailbox attribute
>    indicates an attempt to SELECT or EXAMINE that mailbox without the
>    UTF8 parameter will fail with a [UTF-8-ONLY] response code.
>
>This is missing ABNF. Suggested ABNF:
>
>    resp-text-code =/ "NOT-UTF-8" / "UTF-8-ONLY"

Thanks. Will add.

pr
--

-- 
(Continue reading)

Harald Alvestrand | 17 Jun 13:16 2008
Picon

WG Last Call on draft-ietf-eai-downgrade-07

This is the WG Last Call for the document entitled "Downgrading 
mechanism for Email Address Internationalization", 
draft-ietf-eai-downgrade-07.txt.

The Last Call ends 2 weeks from now, on July 1, 2008.

After resolution of issues raised (if any), the document will be forwarded
to the IESG for approval for Experimental publication.

Of special concern (raised in the last IETF meeting) is whether or not 
it is feasible to propose that this document be accepted prior to 
approval of the -maillist document, which in turn requires a resolution 
on the use of EAI addresses as components of mailto: URIs and/or IRIs.

To simplify resolution of comments, please follow the following formats 
for comments:

SUPPORT: If you have read the documents in their latest version, and
support their publication, please send a message with the subject line
"SUPPORT" to the mailing list.

REVIEW: If you have reviewed the documents in detail, and wish to send 
one (possibly long) message with a review of a whole document, please 
use the subject line "REVIEW: <document>". The chairs will be looking 
for these messages to indicate that the documents have been reviewed by 
a sufficiently large number of people in the WG.

EDITORIAL: If you have editorial issues, but are not asking for any 
change to the technical specification, and do not wish to claim to have 
reviewed the whole specification, please use the subject line 
(Continue reading)

SM | 1 Jul 21:54 2008
Picon

REVIEW: draft-ietf-eai-downgrade-07

At 04:16 17-06-2008, Harald Alvestrand wrote:
>This is the WG Last Call for the document entitled "Downgrading
>mechanism for Email Address Internationalization",
>draft-ietf-eai-downgrade-07.txt.

The abstract mentions:

   "To avoid bouncing internationalized Email messages when a server in the
    delivery path does not support the UTF8SMTP extension, some sort of
    converting mechanism is required."

I suggest using "rejecting" instead of "bouncing" as bounces are 
frown upon nowadays.

In Section 1:

   "To avoid bouncing such messages when a
    server is encountered which does not support the UTF8SMTP extension,
    this document describes a downgrading mechanism."

I suggest a rewording:

   This document describes a downgrading mechanism to avoid rejection 
of such messages
   when a server which does not support the UTF8SMTP extension is encountered.

   "In Section 3, many header fields starting with "downgraded" are
    introduced."

I suggest using "Downgraded-" as in Section 3.
(Continue reading)


Gmane