Subject: RE: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 13 Jun 2006 20:26:50 -0700

Hi Avi.  This is a good clarification.  Thanks.

Kent 

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Tuesday, June 13, 2006 9:55 AM
> To: Pete McCann; Mobile IPv4 Mailing List
> Cc: Henrik Levkowetz
> Subject: RE: [Mip4] Working Group Last 
> Callondraft-ietf-mip4-message-string-ext-00.txt
> 
> "I support the advancement of this document to the IESG with 
> a request for publication as proposed standard."
> 
> I have the following technical comment.  The text field 
> should not be null terminated.
> 
> From:
> 
> The Text field is one or more octets, and its contents are
>       implementation dependent.  It is intended to be human readable,
>       and MUST NOT affect operation of the protocol.  It is 
> recommended
>       that the message contain UTF-8 encoded 10646 [RFC2279] 
> characters.
> 
> To:
> The implementation dependent Text field is one or more 
> octets, and must not be NUL (hex 00) terminated.  It is 
> intended to be human readable,
>       and MUST NOT affect operation of the protocol.  It is 
> recommended
>       that the message contain UTF-8 encoded 10646 [RFC2279] 
> characters.
> 
> 
> 
> > -----Original Message-----
> > From: Pete McCann [mailto:[email-masked]]
> > Sent: Tuesday, June 13, 2006 12:30 PM
> > To: Mobile IPv4 Mailing List
> > Cc: Henrik Levkowetz
> > Subject: [Mip4] Working Group Last Call 
> > ondraft-ietf-mip4-message-string-ext-00.txt
> > 
> > This message announces a WG last call on:
> > 
> >   "Mobile IPv4 Message String Extension"
> >   - draft-ietf-mip4-message-string-ext-00
> > 
> > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006.
> > 
> > draft-ietf-mip4-message-string-ext-00 describes a new Mobile
> > IPv4 extension to carry a user-readable result string with 
> Mobile IPv4 
> > Registration Replies.
> > 
> > A URL for this Internet-Draft is:
> > 
> > <http://www.ietf.org/internet-drafts/draft-ietf-mip4-message-s
> tring-ext-00.txt>
> > 
> > 
> > Please respond to this WG last call:
> > 
> > * If you have no comments on the draft, and support its advancement,
> >    simply respond with a line containing something like
> > 
> >     "I support the advancement of this document to the IESG with a
> >      request for publication as proposed standard."
> > 
> >    If you have comments, please use a line similar to the 
> one above, 
> > and
> >    supplement this with your comments.
> > 
> > 
> > * If you *don't* support its advancement, respond with a line 
> > containing
> >    something like the following, supplemented by your comments -
> > 
> >     "I don't support the advancement of this document to 
> the IESG with
> >      a request for publication as proposed standard, for 
> the following
> >      reasons:"
> >     ...
> > 
> > 
> >      Pete & Henrik
> > 
> > --
> > Mip4 mailing list: [email-masked]
> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> >      Charter page: 
> http://www.ietf.org/html.charters/mip4-charter.html
> > Supplemental site: http://www.mip4.org/
> > 
> 
> --
> Mip4 mailing list: [email-masked]
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "Curtis Provost" <[email-masked]>
Date: Wed, 14 Jun 2006 12:05:58 -0500

I'm not convinced that I agree. I think it may be more appropriate to
have a general statement saying that only human-readable characters may
be included in the text field, but to exclude only the null terminator
seems too narrow. 

Perhaps something like:

The implementation dependent Text field is one or more octets, and
SHOULD NOT contain non human readable characters; e.g. it should not be
null terminated.  It is intended to be human readable, and MUST NOT
affect operation of the protocol.  It is recommended that the message
contain UTF-8 encoded 10646 [RFC2279] characters.

Curtis

-----Original Message-----
From: Kent Leung (kleung) [mailto:[email-masked]] 
Sent: Tuesday, June 13, 2006 10:27 PM
To: Avi Lior; Pete McCann; Mobile IPv4 Mailing List
Cc: Henrik Levkowetz
Subject: RE: [Mip4] Working Group Last

Kent

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Jun 2006 21:00:35 +0200

If I may be a bit contrary here...  Why would / should we exclude
anything?  So far there's a statement that the string should not
be NUL terminated, and now a statement that it might make more sense
to extend this to only human-readable characters.  But I miss at
least

  * A motivation why any of these are better than the current text.

  * If NUL terminated strings are disallowed, an explanation of how
    to handle strings which are non-null terminated, but contain a
    NUL character.

  * NUL is an ascii character, but the text recommends that the
    text have UTF-8 encoding.  What does NUL terminated mean for
    UTF-8 strings?

  * What is the proper definition of "human-readable" for unicode
    characters?

I would propose to skip this whole can of worms, and use ether the
original text:

   The Text field is one or more octets, and its contents are
   implementation dependent.  It is intended to be human readable,
   and MUST NOT affect operation of the protocol.  It is recommended
   that the message contain UTF-8 encoded 10646 [RFC2279] characters.

or one of the following two modifications.  For the first one, note
the elevation of 'recommended' to 'RECOMMENDED', and the additional
sentence at the end.

   The Text field is one or more octets, and its contents are
   implementation dependent.  It is intended to be human readable,
   and MUST NOT affect operation of the protocol.  It is RECOMMENDED
   that the message contain UTF-8 encoded 10646 [RFC2279] characters.
   The length of the text in the text field is exactly the value of the
   Length field minus one, in the encoding used.

But I'd really also like to elevate the RECOMMENDED one step further, to
a MUST in order to remove potential incompatibilities between 256 valued
character sets like Latin-1 and UTF-8.  Even if ASCII and UTF-8 can
'co-exist', this is not the case for many other character sets that have
a fairly wide spread.  So this would be my favourite text:

   The Text field is one or more octets, and its contents are
   implementation dependent.  It is intended to be human readable,
   and MUST NOT affect operation of the protocol.  The content of
   this field MUST be an UTF-8 encoded representation of an ISO-10646
   [RFC2279] message.  The length of the UTF-8 representation of the
   message is is exactly the value of the Length field minus one.

Regards,

	Henrik