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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 12 Sep 2006 23:15:03 -0700

Hi Avi/Curtis/Henrik.  We didn't get a chance to resolve this in the
Montreal meeting.

1) First, RFC 3629 will be referenced for UTF-8 instead of RFC 2279.

2) Finding the appropriate wording for the description of "Text".  I
think the gist of the debate is that the message in the Text field
should contain _only_ characters to convey the information.  This means
that NULL is not appended as the last character.

Proposed text, gleaned from Henrik's suggestion:

   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 [7] characters.
      The number of octets in the UTF-8 representation of the
      message is exactly the value of the Length field minus one.

This sounds OK?
 
BTW:

This issue seems to be a generic one that applies to any protocol that
want to convey a message to a human.  Though a random sampling of RFC
texts on UTF-8 encoding for message string shows how differently each
specification can be written. 

RFC 3748:

   Type-Data

      The Type-Data field in the Request contains a displayable message
      greater than zero octets in length, containing UTF-8 encoded ISO
      10646 characters [RFC2279].  The length of the message is
      determined by the Length field of the Request packet.  The message
      MUST NOT be null terminated. 

RFC 3931:

The Error Message
      contains an arbitrary string providing further (human-readable)
      text associated with the condition.  Human-readable text in all
      error messages MUST be provided in the UTF-8 charset [RFC3629]
      using the Default Language [RFC2277].

RFC 4251:

   string

      Arbitrary length binary string.  Strings are allowed to contain
      arbitrary binary data, including null characters and 8-bit
      characters.  They are stored as a uint32 containing its length
      (number of bytes that follow) and zero (= empty string) or more
      bytes that are the value of the string.  Terminating null
      characters are not used.

      Strings are also used to store text.  In that case, US-ASCII is
      used for internal names, and ISO-10646 UTF-8 for text that might
      be displayed to the user.  The terminating null character SHOULD
      NOT normally be stored in the string.  

Kent

-----Original Message-----
From: Curtis Provost [mailto:[email-masked]] 
Sent: Thursday, June 15, 2006 7:58 AM
To: Avi Lior; Kent Leung (kleung); Pete McCann; Mobile IPv4 Mailing List
Cc: Henrik Levkowetz
Subject: RE: [Mip4] Working GroupLast
Callondraft-ietf-mip4-message-string-ext-00.txt

Avi,

Can you clarify why you would allow embedded null characters but not a
null terminator? 

My only points were a) it doesn't make sense to explicitly disallow only
a single character, and b) while providing guidance for what the string
should contain might be reasonable, it doesn't make sense disallow any
character. 

The text I provided was intended to explicitly NOT disallow inclusion of
anything, but to be clear that an implementation would have to deal with
characters that are not typically readable. Hence, any special handling
for embedded or terminating nulls or other control characters would be
an implementation detail and not subject to specification. As Henrik
stated in his email, and I agree, if we explicitly disallow a
terminating null, then we have to define the behavior if a string is
null terminated. 

Curtis

-----Original Message-----
From: Avi Lior [mailto:[email-masked]]
Sent: Wednesday, June 14, 2006 10:07 PM
To: Provost, Curtis [RICH1:2H10:EXCH]; Kent Leung (kleung); Pete McCann;
Mobile IPv4 Mailing List
Cc: Henrik Levkowetz
Subject: RE: [Mip4] Working Group Last
Callondraft-ietf-mip4-message-string-ext-00.txt

Curtis,

I am not excluding NULL, in fact I am allowing an embedded null.  I am
just saying the string should not be terminated.

Your text does not address the termination part.  I think we either need
to say that this is terminated or non-terminated.  We need to be clear
about this.  This is important.  This could lead to very bad programming
errors.

Also your text is a MUST for human readable yet I don't think we need to
be that ridgid.  The current text say is is intended to be human
readable which is totally different to what you are saying.

Anyway there is precedence for this:

I am just borrowing from RADIUS RFC 2865....This seems to be also the
definition in Diameter.

In particular, types "text" and "string" in RADIUS do not
      terminate with a NUL (hex 00).  The Attribute has a length field
      and does not use a terminator.  Text contains UTF-8 encoded 10646
      [7] characters and String contains 8-bit binary data.  Servers and
      servers and clients MUST be able to deal with embedded nulls.

 text      1-253 octets containing UTF-8 encoded 10646 [7]
                characters.  Text of length zero (0) MUST NOT be sent;
                omit the entire attribute instead.

> -----Original Message-----
> From: Curtis Provost [mailto:[email-masked]]
> Sent: Wednesday, June 14, 2006 1:06 PM
> To: Kent Leung (kleung); Avi Lior; Pete McCann; Mobile IPv4 Mailing 
> List
> Cc: Henrik Levkowetz
> Subject: RE: [Mip4] Working Group Last 
> Callondraft-ietf-mip4-message-string-ext-00.txt
> 
> 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
> Callondraft-ietf-mip4-message-string-ext-00.txt
> 
> 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/
> 

-- 
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: Henrik Levkowetz <[email-masked]>
Date: Wed, 13 Sep 2006 11:11:58 +0200

Hi Kent,

  Your proposed text works for me.

Regards,

	Henrik

on 2006-09-13 08:15 Kent Leung (kleung) said the following:
>> > "I support the advancement of this document to the IESG  with a request 
>> > I have the following technical comment.  The text field  should not be 
>> > null terminated.
>> > 
>> > From:
>> > 
>> > > IPv4 extension to carry a user-readable result string with Mobile IPv4
>> > > Registration Replies.
>> > > 
>> > > <http://www.ietf.org/internet-drafts/draft-ietf-mip4-message-s tring-ext-00.txt>
>> > > 
>> > > 
>> > > * If you have no comments on the draft, and support its  advancement,
>> > >    If you have comments, please use a line similar to the one above,
>> > > and
>> > >     "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
>> > > 
>> > > --

---

From: "Curtis Provost" <[email-masked]>
Date: Wed, 13 Sep 2006 04:25:49 -0500

I'm fine with that also.

Curtis
-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Wednesday, September 13, 2006 5:12 PM
To: Kent Leung (kleung)
Cc: Provost, Curtis (RICH1:2H10); Avi Lior; Pete McCann; Mobile IPv4
Mailing List
Subject: Re: [Mip4] Working GroupLast
Callondraft-ietf-mip4-message-string-ext-00.txt

Hi Kent,

Regards,

	Henrik

recommended

>> > "I support the advancement of this document to the IESG  with a
request 
readable,
tring-ext-00.txt>
advancement,