RE: Teletex Terminal Identifierindraft-ietf-ldapbis-syntaxes-01

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Pardon? I don't see where the BER came from.

The issue surely is that one client adds the value using some encoding,
presumably one of the ones specified. Can another client then interpret this
value. BER is only a factor if ;binary is used, and this hasn't been
proposed.

Ron.

-----Original Message-----
From: Steven Legg [mailto:steven.legg@adacel.com.au]
Sent: Tuesday, 5 March 2002 12:27
To: 'Jim Sermersheim'
Cc: IETF-LDAPbis@OpenLDAP.org
Subject: RE: Teletex Terminal Identifierindraft-ietf-ldapbis-syntaxes-01



Jim,

Jim Sermersheim wrote:
> Perhaps I'm confused.
> 
> When Steven used the term "hexadecimal string", I assumed he meant:
> 
> hexstring = *hexchar
> hexchar = %x30-39 / %x41-46 / %x61-66

That's what I meant.

> 
> Which is different from:
> 
> octetstring = *OCTET
> OCTET = %x00-FF
> 
> By using a hexadecimal string, we wouldn't have to deal with escaping
> the '$' character, as it is outside the range of hexstring values.
> 
> I like the idea, but unfortunately, I believe there are existing
> implementations that encode octetstring as you have 
> prescribed, thus not
> allowing us to re-define it as hexstring.

Do these existing implementations actually pull apart the values
and do something interesting with the ttx-params ? I would expect
that LDAP only servers just store and return the bytes they're given.
So unless there are LDAP clients that try to interpret the values,
whether the ttx-params are raw octets or hexadecimal is only really
an issue for X.500 servers that need to translate between the native
encoding and the BER encoding.

Regards,
Steven

> 
> There's nothing wrong with the octetstring definition (at least in my
> mind). The original problem I was pointing out, is that when an
> octetstring is followed by a '$', we must remember (and remind) to
> escape any occurrence of the %x24 value inside the 
> octetstring (as well
> as the escape value). Otherwise, one cannot parse values of 
> the syntax.
> 
> Jim
> 
> 
> >>> Kathy Dally <kdally@mitre.org> 03/01/02 09:10AM >>>
> Hi Jim!
> 
> I'm a little confused.  A hexadecimal string is not necessarily
> octet-aligned.  So, what's the problem with the <octetstring>
> definition?
> 
> Thanks,
> Kathy
> 
> 
> Jim Sermersheim wrote:
> > 
> > Using a hexadecimal string would be nice, but there are existing
> > implementations (well, one at least) that treat an octetstring as
> Kathy
> > described (octetstring = *OCTET   , where OCTET  =  %x00-FF).
> > 
> > Actually, there are pros and cons for doing it either way.
> > 
> > Jim
> > 
> > >>> "Steven Legg" <steven.legg@adacel.com.au> 02/28/02 09:10PM >>>
> > 
> > Jim,
> > 
> > Jim Sermersheim wrote:
> > > This syntax has the encoding:
> > > teletex-id = ttx-term  0*("$" ttx-param)
> > > where ttx-param ends in an octetstring.
> > >
> > > Some escapment policy must be noted regarding the occurrence of
> %0x24
> > in
> > > the octetstring (due to the $ delimiter). It probably would have
> > been
> > > easier if ttx-param was defined as:
> > > ttx-param  = ttx-key ":" ttx-value-len ":" ttx-value
> > >
> > > but I think we're beyond going back and changing it.
> > 
> > The <octetstring> rule isn't actually defined anywhere so we're
> > free to define it to be something sensible. I suggest we make
> > it a hexadecimal string.
> > 
> > Note that the 4th edition of X.500 has deprecated this syntax.
> > The X.500 working group has even gone to the extent of removing
> > the teletexTerminalIdentifier attribute from every object class
> > that used to reference it. An option for us is to throw it out too.
> > 
> > Regards,
> > Steven
> 
>