Subject: Re: ;binary and *

From: David Chadwick <[email-masked]>
Date: Sat, 02 Mar 2002 22:28:33 +0000

"Kurt D. Zeilenga" wrote:
> 
> There needs to a clarification regarding transfer encoding
> to use when the attribute was not requested by attribute
> description.  E.g., by * or an empty attribute list.
> 
> I suggest that if "foo" is to returned (when not requested
> by attribute description), that the server is to use the
> "native" transfer encoding if the server supports such for
> that attribute. 

agreed

> Otherwise, the server may choose to return
> the attribute in any one of the transfer encodings it does
> support 

replace may choose to with shall

>OR not return the attribute.

Absolutely not. The user has asked for ALL attributes. Unless access
controls prevent it, all should be returned, even if the user cant
handle them. For example, pictures should be returned, even though today
some well known windows clients cant display them (whilst others can).
This is no different to sending others back using ;binary encoding. The
server does not know what the client supports, so should assume it can
support everything since it has not limited what it wants.

> 
> Additionally, the TS should say that clients MUST NOT
> expect any particular transfer encoding of attributes
> which are not requested by attribute description.  Where
> a client desires a particular transfer encoding, including
> the native encoding, the client SHOULD request the
> attribute using an attribute description indicating
> the desired transfer encoding.
> 

agreed

David

> In examples, please avoid use of userCertificate and other
> attributes which mandate use of particular transfer
> encoding options.
> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 02 Mar 2002 15:09:56 -0800

At 02:28 PM 2002-03-02, David Chadwick wrote:
>Absolutely not. The user has asked for ALL attributes.

It could be argued that '*' (or empty list) should be treated
as a request for all attributes in their 'native' transfer
encoding.

>Unless access
>This is no different to sending others back using ;binary encoding.

There is a difference.  A client can determine that attribute
type is of a syntax which it doesn't recognize as printable.
But a client has no way to determine whether a particular
option is a tagging, transfer, or other option.

>The server does not know what the client supports, so should assume it can

A server does not know what the client supports, so it should
assume the client does not support any non-tagging option.

How should a client deal with "cn;foo" when it doesn't recognize "foo"?

If foo is a tagging option, then it can treat cn;foo as it
would any other subtype of cn.

If foo is a transfer option, then it cannot simply treat cn;foo
as a subtype of cn.

It could be argued that servers cannot expect all clients to
recognize ;binary let alone all possible non-tagging options
and hence should not use any non-tagging option without some
form of solicitation by the client.

What I've suggested is kind of a middle ground. 

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 04 Mar 2002 13:33:50 +0100

David Chadwick wrote:
> handle them.
> For example, pictures should be returned, even though today

I concur.

> support everything since it has not limited what it wants.

Yes.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Mar 2002 07:20:52 -0800

>>support everything since it has not limited what it wants.

Then clients MUST treat any attribute description which contains
an unrecognized option as unrecognized.  Clients cannot simply
treat attributes with unrecognized options as an (indirect)
subtype of the attribute description with the same attribute
type and no options.

It is a really bad idea for servers to assume clients support
anything which is not REQUIRED.

Kurt

---

From: Michael Ströder <[email-masked]>
Date: Mon, 04 Mar 2002 16:43:54 +0100

Kurt D. Zeilenga wrote:
> an unrecognized option as unrecognized.

Do you think that's a big difference to what LDAP clients are
already doing today?

>  Clients cannot simply

So what?

Frankly I wouldn't expect most LDAP applications to treat e.g. cn;lang-de-DE 
automagically as a sub-type of cn if the application wasn't explicitly 
designed to handle language sub-types. I also can't imagine an exact 
behaviour a LDAP application should have. I'd consider it rather as opening 
a can of worms.

> anything which is not REQUIRED.

IMHO it's also a bad idea for servers to assume which attributes a client 
cannot handle based on what the client requested or did not request when 
using *.

I think I'd vote for assuming that client applications would be at least 
smart enough to move unhandled attribute types to /dev/null.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 04 Mar 2002 08:15:52 -0800

>Do you think that's a big difference to what LDAP clients are

Yes.  There are many clients today which implement "An
AttributeDescription with one or more options is treated as a
subtype of the attribute type without any options."

>>subtype of the attribute description with the same attribute

This will break all those clients which do treat attribute
descriptions with one or more options as a subtype of the
attribute type without any options.

>Frankly I wouldn't expect most LDAP applications to treat e.g. cn;lang-de-DE automagically as a sub-type of cn if the application wasn't explicitly designed to handle language sub-types.

An LDAP client can generically support all attribute description
subtyping without specifically implementing language tag options.

>I also can't imagine an exact behaviour a LDAP application should have. I'd consider it rather as opening a can of worms.

The application should behave as if they are subtypes. For example,
a client which is designed to display all attributes of directory
string syntax can simply display all subtypes of attribute types
with that syntax.  However, if one of the options could be
a unrecognized transfer option, then it MUST treat all unrecognized
options as unrecognized transfer options.

>IMHO it's also a bad idea for servers to assume which attributes a client cannot handle based on what the client requested or did not request when using *.
>I think I'd vote for assuming that client applications would be at least smart enough to move unhandled attribute types to /dev/null.

Then one needs to change:
   A server will treat an AttributeDescription with any options
   it does not implement as an unrecognized attribute type.

   A server or a client will treat an AttributeDescription with
   any options it does not implement as an unrecognized attribute
   type.  Clients and Servers cannot assume that an AttributeDescription
   with any options it does not implement is a subtype of the attribute
   type without any options.