headers
fujiwara | 1 Sep 2009 08:47
Picon
Favicon

Re: Comments on draft-ietf-eai-downgraded-display-01

Hi, 

Thanks for your comments.

> From: SM <sm <at> resistor.net>
> Hello,
> 
> These comments are for draft-ietf-eai-downgraded-display-01.  Please
> consider them as "I read the document".
> 
> In Section 2:
> 
>   "An "UTF8SMTP message" is an Email messages expanded by [RFC5335]."
> 
> There is a typo for "Email message".

I will update.

> In Section 4:
> 
>      "Apply Email header fields downgrading defined in section 5
>       of [I-D.ietf-eai-downgrade] to the output of Step 2 without re-
>       generating "Downgraded-" header fields."
> 
> This document describes the restoration methods.  I read the above as
> apply downgrading again as defined in RFC 5504.

I will try to rewrite the procedure to understand easy.
Displaying downgraded header uses Section 5 of RFC 5504.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Leiba | 1 Sep 2009 16:25
Picon

Re: Comments on draft-ietf-eai-imap-utf8-07

I have a few comments in addition to SM's -- they're all editorial,
but I think most of them are important.  On the other hand, the
document's technically sound, and ready to go in that regard.

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

Throughout:
It's customary to use "that", rather than "which", to introduce
restrictive clauses.  It's not *wrong* to use "which", but it reads
badly to this editor's eye, and it invites confusion with
non-restrictive clauses, which must use "which" (like this one).

Examples:
pg 4
OLD
   MUST reject octet sequences with the high bit set which fail to
NEW
   MUST reject octet sequences with the high bit set that fail to

OLD
   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
   servers which support the "Mailbox International Naming Convention"
NEW
   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
   servers that support the "Mailbox International Naming Convention"

Etc.

----------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
John C Klensin | 1 Sep 2009 20:26

Re: Gen-ART review of draft-ietf-eai-imap-utf8-07

David,

A comment on one issue -- speaking for myself, not the WG...

--On Monday, August 31, 2009 03:03 -0400 Black_David <at> emc.com
wrote:

> I have been selected as the General Area Review Team (Gen-ART) 
> reviewer for this draft (for background on Gen-ART, please see 
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 
>...

> Major issues:
>...
> Section 8 lists a number of 8859 character sets for which
> upconversion of MIME headers MUST be supported, and then says
> "Other widely deployed MIME charsets SHOULD be supported."
> How does an implementer figure out which character sets those
> would be?  As an alternative, I suggest saying something along
> the lines of: any server-supported character set that is a
> superset of ASCII should be supported for upconversion. That
> probably leads to fewer client surprises caused by UTF-8 not
> working as expected.

FWIW, "superset of ASCII" turns out to be a nightmare
definition.  There are languages out there that use Latin-based
scripts but don't use all ASCII characters.  While I'm not aware
of any of them that use coded character sets that don't include
all of the undecorated "Latin" characters that appear in ASCII,
that combination is certainly plausible and probably does occur
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 1 Sep 2009 23:36
Favicon

Re: Gen-ART review of draft-ietf-eai-imap-utf8-07

Hi  David,
Thank you for your detailed review.

Black_David <at> emc.com wrote:

>I have been selected as the General Area Review Team (Gen-ART) 
>reviewer for this draft (for background on Gen-ART, please see 
>http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). 
>
>Please resolve these comments along with any other Last Call
>comments you may receive.
>
>Document: draft-ietf-eai-imap-utf8-07
>Reviewer: David L. Black
>Review Date: August 31, 2009
>IETF LC End Date: August 31, 2009
>IESG Telechat Date: September 10, 2009
> 
>Summary:
>
>This draft is on the right track, but has open issues, described
>in the review.
>
>The draft appears to be in good shape, although one has to be an
>IMAP expert to understand all of its implications (and I am not
>an IMAP expert).  I found two open issues:
>
>- The header upconversion behavior specification for non-UTF-8
>	mailstores appears to be incomplete.
>- The recommendation to support MIME header upconversion for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 1 Sep 2009 23:56
Favicon

Re: Comments on draft-ietf-eai-imap-utf8-07

Hi Barry,
Thank you for your review.

My comments with my individual participant hat on:

Barry Leiba wrote:

>I have a few comments in addition to SM's -- they're all editorial,
>but I think most of them are important.  On the other hand, the
>document's technically sound, and ready to go in that regard.
>
>----------------------------
>
>Throughout:
>It's customary to use "that", rather than "which", to introduce
>restrictive clauses.  It's not *wrong* to use "which", but it reads
>badly to this editor's eye, and it invites confusion with
>non-restrictive clauses, which must use "which" (like this one).
>
>Examples:
>pg 4
>OLD
>   MUST reject octet sequences with the high bit set which fail to
>NEW
>   MUST reject octet sequences with the high bit set that fail to
>
>OLD
>   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
>   servers which support the "Mailbox International Naming Convention"
>NEW
(Continue reading)

Permalink | Reply | 1 comment |
headers
Black_David | 2 Sep 2009 18:46

Gen-ART review of draft-ietf-eai-imap-utf8-07 - upconversion SHOULD

John,

I freely admit to not being a character set expert.  The core
question from the review was:

> > Section 8 lists a number of 8859 character sets for which
> > upconversion of MIME headers MUST be supported, and then says
> > "Other widely deployed MIME charsets SHOULD be supported."
> > How does an implementer figure out which character sets those
> > would be? 

My attempt to improve on this seems to have missed the mark:

> FWIW, "superset of ASCII" turns out to be a nightmare definition.

I won't disagree with that, despite the number of 8859 character
sets that are listed in the draft.

Rather, what would you suggest to address the original concern? 
Specifically, you wrote:

> On the other hand, if the specification says "this needs to be
> Unicode, presented in UTF-8, on the wire" then servers pretty
> much know what they use (or have to deliver to mail-reading
> MUAs) locally and have to support and convert to and from,
> without our doing anything more than reminding them that, if
> they don't do those conversions, things won't work at all well.

Are you suggesting that the "SHOULD" for upconversion to UTF-8
ought to be on all character sets supported by the server, so
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexey Melnikov | 2 Sep 2009 23:46
Favicon

Re: Comments on draft-ietf-eai-imap-utf8-07

Hi Barry,

Barry Leiba wrote:

>pg 8/9
>
>There seems to be a conflict between these two paragraphs:
>
>   Server implementations also SHOULD up-convert all MIME body headers,
>   SHOULD up-convert or remove the deprecated (and misused) name
>   parameter [RFC1341] on Content-Type and MUST up-convert the Content-
>   Disposition filename parameter.  These parameters can be encoded
>   using the standard MIME parameter encoding [RFC2231] mechanism, or
>   via non-standard use of MIME header encoding [RFC2047] in quoted
>   strings.
>
>   The IMAP server MUST NOT perform up-conversion of headers and content
>   of multipart/signed, as well as Original-Recipient and Return-Path.
>
>Isn't it possible to have a subpart of a multipart/signed message that
>has a Content-Disposition header with a "filename" parameter?  If so,
>the first graph says you MUST up-convert it, and the second says you
>MUST NOT.
>
Right. I think the intent is for the second quoted paragraph to override 
the first.
So I think the first sentence of the first quoted paragraph should end 
with something like:

 ... and MUST up-convert the Content- Disposition filename parameter,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 3 Sep 2009 22:28

Re: [EAI] Gen-ART review of draft-ietf-eai-imap-utf8-07

On 9/1/09 at 10:36 PM +0100, Alexey Melnikov wrote:

>Black_David <at> emc.com wrote:
>
>>- The header upconversion behavior specification for non-UTF-8
>>	mailstores appears to be incomplete.
>>- The recommendation to support MIME header upconversion for
>>	"Other widely deployed MIME charsets" strikes me as
>>	too vague to be useful guidance to implementers.

I'll leave these as they are without further instruction.

>>Section 3.1, next to last paragraph needs a couple of RFC 2119
>>keywords:
>>
>>   Mailbox
>>   names must comply with the Net-Unicode Definition (section 2 of
>>MUST >-->^^^^
>>
>>   [RFC5198]) with the specific exception that they may not contain
>>MUST NOT >----------------------------------------->^^^^^^^
>>
>>   control characters (0000-001F, 0080-009F), delete (007F), line
>>   separator (2028) or paragraph separator (2029).
>
>Agreed. I've entered these as RFC Editor notes.

Fixed.

>>Section 7 recommends that all IMAP clients be modified to display a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pete Resnick | 3 Sep 2009 22:28

Re: Comments on draft-ietf-eai-imap-utf8-07

On 8/30/09 at 10:46 PM -0700, SM wrote:

>The Abstract section mentions that "this is an early draft and 
>intended as a framework for discussion.  Please do not deploy 
>implementations of this draft."

Removed.

>In Section 3.3:
>
>   "Instead, the server MUST return any mailbox names with characters
>    outside the US-ASCII repertorie using utf8-quoted syntax."
>
>There is a typo for "repertoire".

Fixed.

Thanks SM.

pr
--

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
Permalink | Reply | 0 comments |
headers
Pete Resnick | 3 Sep 2009 22:29

Re: Comments on draft-ietf-eai-imap-utf8-07

On 9/1/09 at 10:56 PM +0100, Alexey Melnikov wrote:

>>Throughout:
>>It's customary to use "that", rather than "which", to introduce
>>restrictive clauses.  It's not *wrong* to use "which", but it reads
>>badly to this editor's eye, and it invites confusion with
>>non-restrictive clauses, which must use "which" (like this one).
>
>I would leave this to RFC Editors. They always fix that.

It turned out easy to fix, so I did so, except for the last 
occurrence of "which", which did not need to be fixed.

>>OLD
>>   If the UTF8 capability is advertised, then utf8-quoted syntax MAY be
>>   used with any IMAP argument that permits a string or an astring.
>>NEW
>>   If the server advertises the UTF8 capability, the client MAY use
>>   utf8-quoted syntax with any IMAP argument that permits a string.
>
>Agreed.

Fixed.

>>OLD
>>   All IMAP servers SHOULD accept UTF-8 in mailbox names and IMAP
>>   servers which support the "Mailbox International Naming Convention"
>>   described in RFC 3501 section 5.1.3 MUST accept utf8-quoted mailbox
>>   names and convert them to the appropriate internal format.
>>NEW
(Continue reading)

Permalink | Reply | 0 comments |

Gmane