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

["Steven Legg" <steven.legg@adacel.com.au>]

Ron,

Ramsay, Ron wrote:
> Pardon? I don't see where the BER came from.

If a value of the teletexTerminalIdentifier attribute type is
added to an entry held by an LDAP & X.500 capable server through
the LDAP interface, using the native encoding, then at some point
that server will need to convert the value into the BER encoding
so that the value can be returned through the DAP or DSP interface.
How the <octetstring> rule is defined is critical to this
conversion process. Your implementation supports LDAP and X.500.
How do you translate between the LDAP native encoding of ttx-param
and the DAP BER encoding of TeletexNonBasicParameters ?

An LDAP-only server doesn't need to do such a conversion and it
will probably just store the natively encoded value as is. How the
<octetstring> rule is defined will be irrelevant to such a server,
though perhaps Jim knows of an LDAP-only server that cares for
some reason.

I expect most LDAP clients will just display a natively encoded value
of teletexTerminalIdentifier as is, without conversion, since the
syntax is marked as human-readable. However, if the ttx-values are just
arbitrary octets then they could contain unprintable characters, and
the syntax shouldn't then be regarded as human-readable. Encoding the
ttx-values as hexadecimal character strings would avoid that problem.
Jim may know of an LDAP client implementation that pulls apart a
natively encoded value of teletexTerminalIdentifier to sensibly display
or use the component octet strings. Such a client will care how the
ttx-values are encoded.

> 
> 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.

Even without the ";binary" option being used on the LDAP interface,
the conversion from native encoding to BER is still an issue for
an LDAP & X.500 server.

Regards,
Steven

> 
> 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
> > 
> > 
>