[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