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

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

Kathy,

Kathy Dally wrote:
> 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.

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
   
> 
> Thanks,
> Kathy Dally
>   
> 
> "Kurt D. Zeilenga" wrote:
> > 
> > At 02:39 PM 2002-03-05, Steven Legg wrote:
> > >Kurt D. Zeilenga wrote:
> > >> 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.
> > >
> > >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.
> > 
> > I have no problem with this.
> > 
> > >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.
> > 
> > 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.
> > 
> > >>
> > >> 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.
> > >
> > >Dumping the raw octets into the encoding means it isn't 
> (in general)
> > >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
> 
>