[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Binary Syntax (consensus confirmation)
You are correct.
I meant everywhere the Transfer syntax ;binary.
Helmut
> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> Sent: Dienstag, 18. Dezember 2001 11:48
> To: Volpers, Helmut
> Cc: 'Ramsay, Ron'; ietf-ldapbis@OpenLDAP.org
> Subject: RE: Binary Syntax (consensus confirmation)
>
>
> Your post appears to use the term binary inconsistently.
> Please repost qualifying each use of the word Binary to
> indicate whether you are referring to the binary transfer
> option or the binary syntax. Otherwise your post is
> hard to understand.
>
> Note as well that the binary syntax is not used for X.509
> certificates and CRLs. These each of specific syntaxes
> in LDAP which come from X.500, which are transferred using
> the ;binary transfer option. They are not impacted by the
> removal of the binary syntax (which, to the best of my
> knowledge, is LDAP specific) from the specification.
>
> The binary syntax can be used two different ways:
> a) to hold arbitrary BER encoded data where they
> want that value to be preserved (all existing
> LDAP servers preserve values of octet string, but
> do not necessarily preserve representations of
> values),
> b) as a shortcut for folks who are unwilling or
> unable to define a specific LDAP syntax.
>
> One can argue that both a) and b) are useful, though in each
> case there are significant limits to their usefulness. The
> problem we have is that the ASN.1 data definition of the binary
> syntax is not defined. While why can argue until we are blue
> regarding which of the two interpretations is most consistent
> with the technical specification, the fact is that there are
> two interpretations.
>
> The poll taken at IETF#52 appears to indicate that a sizable
> portion of that not only are both reasonable, that WG favors
> a) over b) [it was 2:1 for a)]. However, it appeared that
> a significant portion of the working group could swing either
> way so consensus was not declared.
>
> It was also noted during the meeting that this is not the
> only interoperability issue with regards to the binary syntax.
> There are clients implementations which require the binary syntax
> to be transferred using the ;binary transfer option and client
> implementations which require the syntax to be transferred without
> the ;binary transfer option. There are also server implementations
> which cannot generate both (are not required to) transfer encodings,
> let alone generate the ;binary transfer encoding expected by the
> client. Hence, if left in, the WG would also have to reach consensus
> on how the binary syntax is to be transferred (with or without
> ;binary transfer option). While disallowing use of the ;binary
> transfer option for values of the binary syntax would remove the
> ASN.1 contention (as both ASN.1 lead to the same native string
> encoding), restricting the syntax to only the native string
> encoding (no ;binary transfer option) would likely be
> contentious as well (regardless of which ASN.1 was chosen).
>
> It is noted that removing the binary syntax from the core
> specification
> does not preclude a future extension document from reintroducing
> the binary syntax and correcting the technical errors and/or
> omissions. Such a document would likely have to first submitted
> as a Proposed Standard, not as a Draft Standard, due to nature of
> the technical errors and/or omissions. This facet of the decision
> likely impacted the poll to remove the schema element from the
> technical specification.
>
> The proposal was to remove the binary syntax (NOT the binary
> transfer option) from the technical specification and to provide
> in an appendix detail as to why had immediate, quite strong
> consensus (close to unanimous -- I didn't see a hand, but I might
> have missed it).
>
> I note Ron's and your dissent.
>
> Please note there are numerous issues with regard to ;binary transfer
> option, the preservation of values, and the preservation of
> representation
> of values. These issues are being addressed separately (as part of
> the protocol I-D discussions).
>
> At 12:39 AM 2001-12-18, Volpers, Helmut wrote:
> >I totally agree with Ron.
> >;binary is defined and it have to be correctly encoded.
> >My Server looks in the value for a UserCertificate;binary
> >and validate the syntax and the client gets an error if it
> >is not correctly encoded.
> >Why should I use ;binary for an OctetString ?
> >Binary was invited to transfer complex ASN.1 syntaxes (e.g.
> >Certificates, Revokationlsits etc) over the LDAP V3 protocol without
> >defining a String representation for this attributes.
> >A Client which want to handle this types of attributes
> >should be able to handle ASN.1.
> >
> >Helmut
> >
> >> -----Original Message-----
> >> From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
> >> Sent: Dienstag, 18. Dezember 2001 05:49
> >> To: Kurt D. Zeilenga; ietf-ldapbis@OpenLDAP.org
> >> Subject: RE: Binary Syntax (consensus confirmation)
> >>
> >>
> >> I find this a tad extraordinary.
> >>
> >> RFC 2252 Section 6.2 Binary:
> >>
> >> Values in this syntax are encoded as described in section 4.3.1.
> >>
> >> 4.3.1 describes the binary transfer of values, therefore
> >> tying ;binary to
> >> the binary syntax.
> >>
> >> Values encoded in the Binary syntax are encoded in BER. For
> >> those of us
> >> working with X.500, we know that all values are encoded in
> >> BER and many of
> >> them have a suitable syntax (X.520). For those that don't
> >> have a defined
> >> syntax, the actual syntax must surely be ANY.
> >>
> >> How anyone felt any justification to use binary to mean octet
> >> string leaves
> >> me breathless!
> >>
> >> I know the IETF members complain about the cost of the
> >> standards and so try
> >> and play it by ear, but the standard is the standard. We are
> >> not talking
> >> whois or ph here.
> >>
> >> Unhappily,
> >>
> >> Ron.
> >>
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> >> Sent: Tuesday, 18 December 2001 14:33
> >> To: ietf-ldapbis@OpenLDAP.org
> >> Subject: Binary Syntax (consensus confirmation)
> >>
> >>
> >> The definition of the binary syntax [RFC2252] (not to be confused
> >> with the ;binary transfer option) was discussed during the LDAPbis
> >> session at IETF#52.
> >>
> >> RFC 2252 failed to provide an ASN.1 data definition for the
> >> binary syntax. There are at least two different interpretations:
> >> a) OCTET STRING constrained to a BER-encoded data
> >> b) ANY
> >> Implementations of both exist in the wild, they do not
> >> interoperate when ;binary is used.
> >>
> >> In summary, the proponents of a) argue that it is more useful
> >> as servers tend to preserve values (but not representations)
> >> while proponents of b) argue that it is more consistent with the
> >> literal reading of RFC 2252. A poll of the room appeared to
> >> favored a) over b), the chairs were not conformable in declaring
> >> consensus (even rough).
> >>
> >> The chair suggested that the specification for the binary syntax
> >> be removed and the reasons why (ambiguous definition) be detailed
> >> in the document's informative appendix detailing changes since
> >> RFC 2252. A poll of the room indicated strong consensus for this
> >> approach.
> >>
> >> Unless there is significant objection voiced from the WG, it shall
> >> be assumed the WG consensus is to implement this approach.
> >>
> >> Regards, Kurt
> >>
>