[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ;binary
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
- Follow-Ups:
- Re: ;binary
- From: Phil Griffin <phil.griffin@asn-1.com>