> >> >a) and b)
> >> >RFC 2252 clause 6.5 only mandates a binary encoding.
> >> >As previously pointed out by others, there is no absolute
> >> imperative that requires the use of the ";binary" option.
> >>
> >> How else would you indicate that the "binary" encoding was
> >> requested/used instead of the "string" encoding?
> >
> >RFC 2252, 6.5 says that ".. values in this syntax MUST only
> be transferred using the binary encoding ..".
>
> Yes. And RFC 2251 makes it quite clear that ;binary is used
> to indicate that the binary encoding was used instead of the
> native string encoding. If ;binary is not present, binary
> transfer of the binary encoding is not used.
There is no statement that says that if the ";binary" option is absent, that the syntax encoding cannot be the binary encoding. All the RFC says is that ";binary" overrides a string encoding. But certificates do not have a string encoding. Since there is no string encoding to override, the ";binary" option is not necessary.
> >Although 4.3.1 lists two reasons to use the binary encoding,
> it does not say that other valid reasons or syntaxes cannot
> require the use of the binary encoding.
>
> But RFC 2251 states when binary encoding is to be used and when
> native encodings are to be used.
All it says is that ";binary" can override a string encoding. It doesn't say anything about "native" encodings or what happens when no string encoding is defined. It also does not say what happens when a syntax definition requires a specific encoding (such as the Certificate syntax mandating the binary encoding).
The only guide is that the Certificate syntax requires the binary encoding. Therefore even if ";binary" is not used, the binary encoding must be generated.
>
> >Since the use of ";binary" is not mandatory for the
> Certificate syntax,
>
> I disagree.
Others have stated their belief that ";binary" is not mandatory for certificates. There is no text that supports an absolute imperative that ";binary" MUST be used.
>
> >and there is no other possible encoding, then the default
> encoding that is used (that must be used) is the binary encoding.
>
> There is no such thing as the "default" encoding. That term is
> no where used in the specification. There is the native string
> encoding and there is the binary encoding. Which one is used
> is indicated by the absence or presence of transfer options.
> If this wasn't the case, then clients would have no clue as to
> what encoding was actually used.
The term "string encoding" is not defined either. So it is not clear if the RFC refers to a "native string" encoding or an encoding based on text (printable) strings.
I note that for Directory String, the RFC does not explicitly identify the "string encoding" either. But we understand that the encoding mandated for Directory String is UTF8. The same logic can be applied to certificates.
>
> >If the ";binary" option is used to explicitly specify the
> binary encoding, this results in the same encodings and this
> would also satisfy the RFC.
>
> ;binary must be present when the binary encoding is transferred.
> ;binary must not be present when the native encoding is transferred.
Where is that stated in the RFC ? There are no such statements.
>
> >> >c)
> >> >Nowhere in the ldapv3 RFCs is there a description of the
> >> behavior for this case. There is no justification to label
> >> this as non conformant.
> >>
> >> You are right in that the RFC does not explicit state this.
> >>
> >> But it should be obvious that "CN;binary" should not be
> >> returned unless "CN;binary" was requested. Same goes
> >> for userCertificate.
> >>
> >
> >Attributes must be returned according to their syntax
> encoding requirements.
>
> Values of a syntax can encoded multiple ways for transfer. The
> encoding used is always indicated by the presence or absence of
> transfer options such as ;binary.
>
The ";binary" only specifies that a "string encoding" was overridden. But if there is not string encoding to override, then the ";binary" is not required (there is no text that says ;binary is required when there is no string encoding to override).
Chris.