[Date Prev][Date Next]
RE: Protocol: Ignore SEQUENCE elements...
- To: "Jim Sermersheim" <firstname.lastname@example.org>, <ietf-ldapbis@OpenLDAP.org>
- Subject: RE: Protocol: Ignore SEQUENCE elements...
- From: "Ramsay, Ron" <Ron.Ramsay@ca.com>
- Date: Wed, 17 Sep 2003 16:52:06 +1000
- Content-class: urn:content-classes:message
- Thread-index: AcN84kxJoFXdVbQvQU+ZEDc0h7YXZgAA9tng
- Thread-topic: Protocol: Ignore SEQUENCE elements...
You haven't addressed the four ENUMERATED types?
The original statement referred only to SEQUENCE - wouldn't it be better to leave it there?
I don't think we need to deal with extensibility. If the appropriate response to unknown elements in the ASN.1 were to return protocolError, then new clients can have a fallback when dealing with old servers. For old clients and new servers, the clients would have to ignore anything the didn't recognise because ... well, they have no option.
But who is going to change the ASN.1? The LDAP way is to change behaviour using controls.
From: Jim Sermersheim [mailto:email@example.com]
Sent: Wednesday, 17 September 2003 16:07
To: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
Subject: RE: Protocol: Ignore SEQUENCE elements...
Here are the CHOICEs in LDAP today:
- LDAPMessage.protocolOp. When unknown, there are explicit instructions
to return protocoIError and close the conn.
- BindRequest.authentication. When unknown, there are explicit
instructions to return authMethodNotSupported.
- SearchRequest.Filter. When unknown, I had imagined that the filter
item would evaluate to Undefined.
- SearchRequest.Filter.SubstringFilter.substrings. I imagine this also
results in an Undefined predicate.
That said, I think you're right. the fact that CHOICE and ENUMERATED
are implicitly extensible doesn't automatically mean unknowns should be
ignored (even if we say that behavior is overridden by more explicit
We probably need to give explicit instructions for SearchRequest.Filter
There are no SET constructs today.
>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 9/16/03 10:54:14 PM >>>
Excuse me, but how can you possibly ignore an unknown alternative in a
CHOICE type? What if LDAMessage.protocolOp is not one of the published
ones? Do you say, "Well, at least I got a messageID - let's see if there
are controls." The same for enumerated types.
The beauty of ignoring (trailing) unrecognised items is that you
already have enough to form a legal operation - additional items would
merely have the same status as controls.
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim
Sent: Wednesday, 17 September 2003 14:39
Subject: Re: Protocol: Ignore SEQUENCE elements...
<Second try. I got no response last time.>
>>> "Jim Sermersheim" <firstname.lastname@example.org> 7/14/03 3:16:38 PM >>>
There is the statement in [Protocol] that instructs:
"Because of the implied extensibility, clients and servers MUST ignore
trailing SEQUENCE elements whose tags they do not recognize."
This is basically the same text as RFC2251 (we added the _why_, and
But I think this falls short of what it really intends to say. I think
that what it really intends to say is that:
"protocol peers MUST ignore the presence of arbitrary unexpected
extension additions above those defined (if any) in a SEQUENCE or SET
type, or of an unknown alternative in a CHOICE type, or an unknown
ENUMERATION in an enumerated type, or of an unexpected length or value
of a type whose constraint is extensible."
I just s! tole most of that from X.680, thus it could be shortened with
reference, but I think the information might be handy. Also, we should
likely preserve the "trailing" word.