Subject: Re: Zero not allowed

From: Tom Taylor <[email-masked]>
Date: Wed, 31 Jan 2001 09:38:21 -0500

Just as a historical sidelight: originally we were going to allow both SDP and Annex C encodings within Local and Remote, but
the use of Annex C got restricted to binary encoding at the Redbank meeting.  Can x00 not appear within an MTPAddress, in
which case the exclusion is unwarranted?

I'm also concerned about the assumption of null-terminated strings.  That assumption is C/C++ specific and should not be
refelcted in a general protocol.  Not that we should deliberately make it hard for C programmers, but we shouldn't do anything
unnatural just to accommodate them.

On Tue, 16 Jan 2001 11:26:03 -0500, Troy Cauble <[email-masked]> wrote:

>Yes.  Please don't add the zero.
>
>SDP is limited to "the ISO 10646 character set in
>UTF-8 encoding".
>
>Based on that the range of characters for "octetString"
>should probably be narrowed, not widened.
>
>I think the problem is that the name "octetString" is
>misleading and implies that a full range of octet values
>needs to be supported.
>
>I'm especially worried about adding '0' because that
>terminates a character string and may cause implementation
>issues.
>
>-troy
>
>
>"Rosen, Brian" wrote:
>>
>> Well, maybe something along the lines of
>> "The octet zero is not among the permitted characters in octet string,
>> which is used in the ABNF for local and remote descriptors.  As the current
>> definition of these descriptors is limited to SDP, and a zero octet would
>> not
>> be a legal character in SDP, this is not a concern."
>>
>> > -----Original Message-----
>> > From: Christian Groves [mailto:[email-masked]]
>> > Sent: Monday, January 15, 2001 12:45 AM
>> > To: [email-masked]
>> > Subject: Re: Zero not allowed
>> >
>> >
>> > G'Day Brian and Paul,
>> >
>> > It doesn't sound like people care very much for this change?
>> > Do you want
>> > something added to the implementors' guide.
>> >
>> > Cheers, Christian
>> >
>> > Paul Long wrote:
>> > >
>> > > Brian,
>> > >
>> > > The low end of the range of acceptable characters for octetString
>> > > suspiciously starts with %01 rather than %00.
>> > >
>> > >    octetString          = *(nonEscapeChar)
>> > >    nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )
>> > >
>> > > Since octetString is only referenced in mtpAddress,
>> > localDescriptor, and
>> > > remoteDescriptor, maybe it doesn't matter if an octet of
>> > zero is excluded. I
>> > > was just wondering why it was left out. Sounds like there
>> > was no reason.
>> > >
>> > > Paul
>> > >
>> > > -----Original Message-----
>> > > From: Media Gateway Control (megaco)
>> > > [mailto:[email-masked]]On Behalf Of
>> > Rosen, Brian
>> > > Sent: Friday, January 12, 2001 2:08 PM
>> > > To: [email-masked]
>> > > Subject: Re: Zero not allowed
>> > >
>> > > I don't think we thought about it.
>> > > For SDP, it doesn't matter.  Beyond that, who knows.
>> > > I suppose it would be better if it allowed zero.
>> > >
>> > > Brian
>> > >
>> > > > -----Original Message-----
>> > > > From: Paul Long [mailto:[email-masked]]
>> > > > Sent: Sunday, December 31, 2000 12:30 PM
>> > > > To: [email-masked]
>> > > > Subject: Zero not allowed
>> > > >
>> > > >
>> > > > I noticed that an octet of zero is not allowed in the ABNF
>> > > > octetString. Was
>> > > > this intentional?
>> > > >
>> > > > Paul Long
>> > > > ipDialog, Inc.
>> >

---

From: Christian Groves <[email-masked]>
Date: Thu, 1 Feb 2001 10:15:08 +1100

Just to clarify Tom, both SDP and Annex C ARE within local and remote.
Annex C is also for Local Control. SDP is not.

Christian

---

From: Troy Cauble <[email-masked]>
Date: Wed, 31 Jan 2001 19:59:37 -0500

Christian,

Are you saying that every Annex C property is appropriate for
all three of the Local, Remote, and LocalControl descriptors?

I suspect they're not and that each Annex C property should
identify which descriptors they're appropriate for.  (Package
properties do this.)

What about Annex C.11, the SDP equivalents?  Are they appropriate
for local control or not?  You say "yes" and "no" below :)

-troy