[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