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

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 5 Mar 2002 13:40:11 +1100

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:[email-masked]]
Sent: Tuesday, 5 March 2002 12:27
To: 'Jim Sermersheim'
Cc: [email-masked]
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 <[email-masked]> 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" <[email-masked]> 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
> 
>

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 5 Mar 2002 16:48:41 +1100

Ron,

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

> value. BER is only a factor if ;binary is used, and this hasn't been

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

> Subject: RE: Teletex Terminal 
> Identifierindraft-ietf-ldapbis-syntaxes-01
> 
> 
> 
> Jim,
> 
> Jim Sermersheim wrote:
> > Perhaps I'm confused.
> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Mar 2002 22:17:41 -0800

I note that "The H-R column suggests whether a value in
that syntax would likely be a human readable string."
Even DirectoryString may not be human readable.

I think all that is needed with regard to this syntax
is an explicit statement that dollar sign
("the following separator symbol") and backslash
should be escaped using the mechanism defined in RFC
2252, Section 4.3, pp3.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Wed, 6 Mar 2002 09:39:07 +1100

Kurt,

> Even DirectoryString may not be human readable.

Perhaps instead of indicating whether the native encoding for
a syntax is human-readable we should be indicating whether it
is a UTF8 character string. If a client knows that the encoding
is a UTF8 string then the unprintable characters have a particular
meaning, e.g. (hex)0D is a carriage return. If the encoding isn't
a UTF8 character string then (hex)0D shouldn't be assumed to be
anything in particular, and treated accordingly. It probably isn't
a carriage return.

> should be escaped using the mechanism defined in RFC

Dumping the raw octets into the encoding means it isn't (in general)
a UTF8 character string. Using hexadecimal means it is.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 05 Mar 2002 15:06:18 -0800

At 02:39 PM 2002-03-05, Steven Legg wrote:
>is a UTF8 character string.

I have no problem with this.

>If a client knows that the encoding

I would suggest that we:
        - clarify that UTF-8 values can contain non-printables,
        - state that consistent handling of many non-printable
         characters cannot be expected,
        - non-printable characters should be avoided in
          absence of an agreement to their handling.

>a UTF8 character string. Using hexadecimal means it is.

I think it better to correct the H-R column then to change
the syntax's specification.

Kurt

---

From: Kathy Dally <[email-masked]>
Date: Wed, 06 Mar 2002 16:48:02 -0500

Hi!

The H-R column has already been removed from the list of syntax oid
assignments in ....-syntaxes-02 (Annex A).  I don't see how indicating
which syntaxes are utf8 is helpful.  For example, what would be in the
column for IA5 String?  

Thanks,
Kathy Dally

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 06 Mar 2002 16:07:36 -0800

>which syntaxes are utf8 is helpful.  For example, what would be in the

As each syntax defined in the [Syntax] I-D should be complete,
there is no need to maintain the table.  It, IMO, should be
completely removed from the document or changed to a simple
table providing for each syntax defined in the document an
indication of which section it is defined in.

We cannot attempt to maintain a table of all the syntaxes
defined "thus far" for use in LDAP.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 7 Mar 2002 12:29:44 +1100

Kathy,

Kathy Dally wrote:
> which syntaxes are utf8 is helpful.

It is helpful for implementors of simple clients. Every syntax whose
native encoding is known to be a UTF8 character string can have its
values displayed the same simple way.

> For example, what would be in the
> column for IA5 String?

Every IA5 string is a legal UTF8 character string, so the field would
be "Yes". All the *fully specified* syntaxes from RFC 2252 that were
marked as human-readable produce legal UTF8 character strings.

Kurt has suggested we throw out the syntax table. That's okay with me,
but there's still the question whether we want to capture the
human-readable-ness/utf8-ness of each syntax in its description.

Regards,
Steven