RE: ;binary

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Phil,

I would think that this wouldn't encode an address as "1 First Avanue,
Downtown" (human readable) or "1 FirstAvanue$Downtown" (LDAP) but as

<street-address><item>1 First
Avanue</item><item>Downtown</item></street-address>

?

Ron.

-----Original Message-----
From: Phil Griffin [mailto:phil.griffin@asn-1.com]
Sent: Monday, 25 February 2002 14:42
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: ;binary


The possibility of defining a human-readable 
format for binary ASN.1 values in the future
is here, right now. Done already - or at least
very near final approval.

It's called the 2002 edition of ISO/IEC 8824-1 |
ITU-T Recommendation X.680, and it defines an XML
markup representation for every value of every ASN.1
type. Interestingly, it defines a dotted format, 
borrowed from LDAP, for values of type OBJECT 
IDENTIFIER.

And there's XML Encoding Rules (XER), defined in 
ISO/IEC 8825-3 | ITU-T Recommendation X.693. These
encodings carry the exact same abstract values as 
defined in the ASN.1 standards, but in a human-
readable textual format. 

Having XER allows you to easily switch back and 
forth between binary and textual representations
of the exact same values.

Phil


"Ramsay, Ron" wrote:
> 
> Steven,
> 
> 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!
> 
> What about aci;encoding=novel;. Would this be a subtype?
> 
> 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
> c 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