[Date Prev][Date Next] [Chronological] [Thread] [Top]

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



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
  

"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