[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
valueencoding production (Was: draft-ietf-ldapbis-filter-03.txt)
Should <valueencoding> be something like:
valueencoding = 0*(normal / escaped)
normal = UTFN / UTFMB
UTFN = %x01-27 / %x2b-5b / %x5d-7f
escaped = "\" hex hex
hex = %x30-39 / %x41-46 / %x61-66
where UTFM is as defined in [Models]:
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0)
UTF3 = %xE0-EF 2(UTF0)
UTF4 = %xF0-F7 3(UTF0)
UTF5 = %xF8-FB 4(UTF0)
UTF6 = %xFC-FD 5(UTF0)
(I'd like to see the grammar rewrite to the common productions
form [Models]).
Kurt
At 06:38 AM 2002-11-15, Mark C Smith wrote:
>Hallvard B Furuseth wrote:
>>Why was section 6 "String Search Filter Definition" changed to
>>say that "all octets greater than 0x7f" must be escaped?
>>Shouldn't that at least be "MUST" esacpe them when generating filters,
>>but SHOULD (or MAY) recognize them unescaped, for backwards
>>compatibility?
>
>That change was the result of working group last call comments made by Steven Legg (but I am the one who wrote the text). But I think I unintentionally made a protocol change. Is there a good reason to require that all octects > 0x7f be escaped? I do not remember all of the details surrounding those older conversations.
>
>
>> Also, the change should be noted in Appendix A.
>
>Agreed. Also, if we leave the escaping requirement in, I agree with you we should add text that suggests that recognizing octets > 0x7f when they are not escaped is good practice.
>
>
>>Also,
>>
>>>7. Examples
>>> (1.3.6.1.4.1.1466.0;binary=\04\02\48\69)
>>
>>;binary has been removed from [Protocol].
>
>Good catch.
>
>-Mark