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

From: "Avi Lior" <[email-masked]>
Date: Wed, 14 Jun 2006 23:07:19 -0400

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/

---

From: "Curtis Provost" <[email-masked]>
Date: Thu, 15 Jun 2006 09:57:34 -0500

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

Curtis,