[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
use cases (RE: ;binary Concensus?)
Chris, to your cases below, here are my opinions:
1) Agree. Attribute is encoded as LDAP-specific
2) I believe if there is no LDAP-specific encoding, ;binary must be
used here
3) How would this be inserted in the schema? Don't think we need to
discuss this.
4) Same as 3
5) Agree. LDAP-specific encoding is used
6) The server should return the value in LDAP-specific encoding, but
clients must be prepared to receive ;binary. (RFC 2252 4.3.1)
7) Agree (if we're talking about the client not knowing)
8) Same as 7
9) Same as 5
10) Unrecognized attribute. Ignored by server
11) No, should always be retuned as x;y
12) Unrecognized attribute. Ignored by server
13) Agree. Return as x;y
14) Agree. Unrecognized attribute. Ignored by server
15) Unrecognized attribute. Ignored by server
16) Unrecognized attribute. Ignored by server
>>> Christopher Oliva <Chris.Oliva@entrust.com> 04/12/02 10:05AM >>>
I forgot two case:
15. The client requests attribute desc 'x'. There is no native encoding
for
the syntax of attribute 'x' and there is no mandated transfer encoding
in
that syntax definition.
First, I'd like to believe this type of syntax definition would not be
allowed. But if it were allowed, I'd think the server would return the
values in binary encoding and the associated attribute description
would be
'x;binary'. This assumes that there is a valid ASN.1 abstract syntax
defined.
But the way RFC 2251 4.1.6 is written, it sounds like there is a need
for an
extra octet string wrapper.
I would think the clarification would not require an extra octet
string
wrapper. I don't think this is a problem in protocol-07.
16. The client requests attribute desc 'x;y'. There is no native
encoding
for the syntax of attribute 'x' and there is no mandated transfer
encoding
in that syntax definition.
RFC 2251 4.1.6 would seem to only allow the server to respond if y =
binary.
Otherwise the same as case 15.
I think the clarification would allow 'y' to be anything. I believe
this has
already been done in protocol-07.
Chris.
> 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.
>