Subject: Gen-ART review of draft-ietf-eai-rfc5335bis-12

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 18 Oct 2011 22:50:54 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other Last Call comments you 
may receive.

Document: draft-ietf-eai-rfc5335bis-12
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2011-10-18
IETF LC End Date: 2011-10-20
IESG Telechat date: 2011-10-20

Summary: The document is ready for publication as a standards track RFC.

Major issues: none

Minor issues: none

Nits/editorial comments:

- Section 3.4 reads:

    Section 2.1.1 of [RFC5322] limits lines to 998 characters and
    recommends that the lines be restricted to only 78 characters.  This
    specification changes the former limit to 988 octets.
           bbb                                ^^^

I wonder if there is an error in the third line and the text should say 
"... limit to 998 octets" rather than "988". Otherwise, I can't explain 
the 988 figure.

Idnits has a number of complaints:

   Checking nits according to http://www.ietf.org/id-info/checklist :
 
----------------------------------------------------------------------------

   -- The draft header indicates that this document obsoletes RFC5335,
but the abstract doesn't seem to mention this, which it should.

   -- The draft header indicates that this document updates RFC2045, but
the abstract doesn't seem to mention this, which it should.

   -- The draft header indicates that this document updates RFC5322, but 
the abstract doesn't seem to mention this, which it should.

   Checking references for intended status: Proposed Standard
 
----------------------------------------------------------------------------

   ** Downref: Normative reference to an Informational draft:
      draft-ietf-eai-frmwrk-4952bis (ref. 'I-D.ietf-eai-frmwrk-4952bis')

   ** Downref: Normative reference to an Informational RFC: RFC 5598

Other than that, the document looks good.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Oct 2011 08:42:19 -0400

Miguel:

I interpret this text to mean that the old limit was 998 octets and that the new limit is 988 octets.

Russ

On Oct 18, 2011, at 4:50 PM, Miguel A. Garcia wrote:

> I wonder if there is an error in the third line and the text should say "... limit to 998 octets" rather than "988". Otherwise, I can't explain the 988 figure.
>

---

From: Pete Resnick <[email-masked]>
Date: Thu, 20 Oct 2011 06:19:27 -0700

Your initial suspicion was correct: It is a typo.

Impressive how many folks can miss something so simple.

I'll put it in a note to the RFC Editor.

pr

On 10/20/11 5:48 AM, Miguel A. Garcia wrote:
> Yes, I interpret the same. But having found no motivation for the 
> reduction of 10 octets, I just wanted to verify that there is no typo 
> in the figure.
>
> A bit of motivation for the "988" would help too.
>
> /Miguel
>
> On 20/10/2011 14:42, Russ Housley wrote:
>> Miguel:
>>
>>> I wonder if there is an error in the third line and the text should 
>>> say "... limit to 998 octets" rather than "988". Otherwise, I can't 
>>> explain the 988 figure.
>>>
>>
>

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Thu, 20 Oct 2011 07:37:42 -0700

On 10/20/11 6:59 AM, Miguel A. Garcia wrote:
> But even if it is a typo, the text makes no sense. It says:
>
> So, if the limit is still 998, then there is no change with respect 
> the former limit.

See the next sentence:

    (Note that in
    ASCII octets and characters are effectively the same but this is not
    true in UTF-8.)

Remember, in UTF-8, characters can be multiple octets. So 998 UTF-8 
encoded *characters* are likely to be many more than 998 octets long. So 
the change is to say that the limit is in octets, not in characters.

pr

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 20 Oct 2011 14:48:28 +0200

Yes, I interpret the same. But having found no motivation for the 
reduction of 10 octets, I just wanted to verify that there is no typo in 
the figure.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 20 Oct 2011 15:59:18 +0200

So, if the limit is still 998, then there is no change with respect the 
former limit.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Abel" <[email-masked]>
Date: Fri, 21 Oct 2011 03:23:27 +0800

Yes, it's a typo,
next version will update it.

Abel

-----原始郵件----- 
From: Pete Resnick
Sent: Thursday, October 20, 2011 9:19 PM
To: Miguel A. Garcia
Cc: Russ Housley ; [email-masked] ; [email-masked] ; 
[email-masked] ; General Area Review Team ; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-eai-rfc5335bis-12

pr

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 23 Oct 2011 07:11:37 +0100

On 10/20/2011 3:37 PM, Pete Resnick wrote:
>> So, if the limit is still 998, then there is no change with respect the former
>> limit.
>
> See the next sentence:
>
> (Note that in
> Remember, in UTF-8, characters can be multiple octets. So 998 UTF-8 encoded
> *characters* are likely to be many more than 998 octets long. So the change is
> to say that the limit is in octets, not in characters.

The switch in vocabulary is clearly subtle for readers.  (I missed it too.)

I suggest adding some language that highlights the point, possibly the same 
language as you just used to explain it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Oct 2011 12:46:58 -0400

--On Sunday, October 23, 2011 07:11 +0100 Dave CROCKER
<[email-masked]> wrote:

> 
>> Remember, in UTF-8, characters can be multiple octets. So 998
>> UTF-8 encoded *characters* are likely to be many more than
>> 998 octets long. So the change is to say that the limit is in
>> octets, not in characters.
> 
> 
> I suggest adding some language that highlights the point,
> possibly the same language as you just used to explain it.

In addition to what might be useful/ necessary for readers of
5335bis, in retrospect, we ought to have a prominent comment in
one of the more generic i18n documents that highlights the fact
that the, once one moves beyond ASCII, length-in-characters and
length-in-octets, can no longer be assumed to be the same.  When
one is actually talking about storage length,
length-in-characters should be prohibited from our vocabulary
going forward.  That would actually make an interesting
extension to a nits-checker if someone could figure out how to
do it or, at least, a flag to the RFC Editor about something
they should watch out for.

    john

---

From: [email-masked]
Date: Sun, 23 Oct 2011 10:08:06 -0700 (PDT)

> language as you just used to explain it.

The document already contains text for this:

  Section 2.1.1 of [RFC 5322 limits lines to 998 characters and recommends that
  the lines be restricted to only 78 characters. This specification changes
  the former limit to 998 octets. (Note that in ASCII octets and characters
  are effectively the same but this is not true in UTF-8.) The 78 character
  limit remains defined in terms of characters, not octets, since it is
  intended to address display width issues, not line length issues.

Note the parenthetical comment in the middle of the paragraph.

I really don't see any point in further elaboration of this issue in this
context.

				Ned