[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: ;binary Concensus?



Title: RE: ;binary Concensus?

Hi,

Some questions/comments below.

> a previous message (4 April to Mark) I mentioned 8 cases that need to
> clearly covered in the protocol document.

I agree that the use cases for this are an important first step. It might be a good idea to understand where the use cases differ between the two camps. If there are more than two camps, it might help reduce the number of conflicting opinions (my hope would be that if the use cases were agreed upon, the specific text might be less of an issue).

> > It is, of course, important that the language used to clarify
> > draft-ietf-ldapbis-protocol-xx.txt preserve the demonstrated
> > interoperability for LDAPv3 certificate access.

Is there a way to know which interoperability has been demonstrated? I think that the approach of camp A and B are both proven to work. So then, the functionality of both should be preserved?

> > What I would like to see is the those in each camp, operating
> > as a design camp, offer text which provides a clear and concise
> > specification of ;binary,  e.g. replacement text for Section
> > 4.1.5 of draft-ietf-ldapbis-protocol-07.txt, for the WG to
> > consider.

Once the proposals are finished, how will they be evaluated? How will one be chosen?

I've copied the use cases from David's original message (and renumbered them) and also added a few of my own. I've indicated where I think there is agreement.

---------------
The server might receive on an Add operation

1) an attribute whose LDAP syntax OID is known to the server and whose
native encoding is known e.g telephoneNumber

OK. This one is easy.

2) an attribute whose LDAP syntax OID is known and whose native
encoding is not defined e.g. certificates and Steven Legg's multiple
examples of ACI etc (although it seems a bit odd to allocate an LDAP
syntax OID and not define what it means)

This one is a problem. If the syntax mandates an encoding, is the ";option" required? IMO it isn't. Mandating a transfer encoding is virtually the same as defining the native encoding.

3) an attribute whose syntax OID is not known and is sent to the
server as ;binary e.g. foobar;binary

I would think the server should produce an error?

4) an attribute whose syntax OID is not known and is sent to the server
in a native encoding known to the client e.g foobar

I would think this would result in an error.

--------------

I believe these next 4 are in reference to what a client may receive from a "*" search:

5) an attribute whose native encoding it knows, in native encoding e.g
telephoneNumber

No problem.

6) an attribute whose native encoding it knows, in ;binary encoding
e.g. telephoneNumber;binary

This should be invalid. If the native encoding is known, it should be used to return the values. Maybe depends on the answer to (3)?

7) an attribute whose native encoding it does not know, in native
encoding e.g. foobar

I think this is legal. The client should expect this if it asks for "*". It should discard/ignore anything it doesn't recognize.

8) an attribute whose native encoding it does not know, in binary
encoding e.g. foobar;binary

I suppose this is alot like case (7).

---------------

These are some I've added that describe a search request for a specific attribute:

9) Request attribute 'x' with a known native encoding

OK. No problem.

10) Request attribute desc 'x' with no native encoding. The syntax definition mandates a specific encoding 'y'.

This one is a problem. I believe the values should be returned encoded as 'y' and the attribute description may be either 'x;y' or 'x'.

11) Request attribute with 'x;y' with no defined native encoding. The syntax definition mandates a specific encoding 'y'.

This is a bit less of a problem. Same as for (10).

12) Request attribute with 'x;y' with no defined native encoding. The syntax definition mandates a specific encoding 'z'.

This one might be confusing. Since encoding 'z' is mandated, encoding 'y' is illegal. An error should be generated ?

13) Request attribute desc 'x;y'. Native encoding defined and encoding 'y' is known.

OK. No problem. 'x;y' is returned and values encoded as 'y'.

14) Request attribute desc 'x;y'. Native encoding defined but encoding 'y' is not known.

The server should treat 'x' as an undefined attribute type.


Chris.