RE: ;binary

["Steven Legg" <steven.legg@adacel.com.au>]

Ron,

Ramsay, Ron wrote:
> I think you have stepped over the edge with this proposal. 
> After Kurt was so
> careful to explain that we must use the ASN.1 implied by the 
> attribute OID
> with reference to the X.500 documents!

I said nothing that changes the interpretation of ";binary".
My statements are completely consistent with Kurt's explanation.
I was pointing out a reason for leaving the native LDAP encoding
as undefined, rather than specifying it to be the same as the
";binary" encoding.

> 
> What about aci;encoding=novel;. Would this be a subtype?

The LDAPbis working group has already reached consensus that there
are at least two categories of attribute options: subtyping options
and transfer encoding options. "aci;encoding=novel" would be
considered a subtype if and only if "encoding=novel" were defined to
be a subtyping option.

BTW, '=' is not a legal character for an attribute option.

Regards,
Steven

> 
> Ron.
> 
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Monday, 25 February 2002 10:47
> To: 'Christopher Oliva'
> Cc: ietf-ldapbis@OpenLDAP.org; 'David Chadwick SMTP (E-mail)'
> Subject: RE: ;binary
> 
> 
> 
> Chris,
> 
> Christopher Oliva wrote:
> > > The problem with this is that if a server is allowed to 
> > > return ;binary when the client makes a request without 
> > > ;binary then the servers might actually do that.  That 
> > > would be bad as client wouldn't get what they asked for. 
> > > 
> > As I have shown above, the client would know what they are getting
> > since the server has replied with ";binary".
> 
> Unfortunately, client implementors often don't take into account all
> the potential responses they can get. They usually do enough to make
> their client work with their preferred LDAP server and leave it at
> that. So even if we explicitly specify that servers are 
> allowed to return
> ";binary" without it being requested, there will still be people
> implementing clients that don't expect it.
> 
> 
> Apropos of the current discussion, I've found a good reason for NOT
> specifying that the native LDAP encoding for some syntax is the
> same as its ";binary" encoding. I've just submitted an I-D for
> an LDAP profile of X.500's Basic Access Control (it should appear in
> a few days) which uses the ACI Item syntax from RFC 2252. I've defined
> a human-readable native LDAP encoding for this syntax. However, I
> would have had a problem if the native LDAP encoding for this syntax
> had been previously defined to be the same as its ";binary" encoding.
> 
> By not defining the native LDAP encoding to be the same as 
> the ";binary"
> encoding for syntaxes that don't have a defined 
> human-readable encoding,
> we leave open the possibility that we might define one in the future.
> 
> 
> Regards,
> Steven
>