Subject: RE: ;binary

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 25 Feb 2002 11:35:47 +1100

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:[email-masked]]
Sent: Monday, 25 February 2002 10:47
To: 'Christopher Oliva'
Cc: [email-masked]; '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

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 25 Feb 2002 12:40:27 +1100

Ron,

> 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

---

From: Phil Griffin <[email-masked]>
Date: Sun, 24 Feb 2002 22:42:24 -0500

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:
> c for this syntax. However, I