RE: Protocol: Ignore SEQUENCE elements...

["Jim Sermersheim" <jimse@novell.com>]

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
instructions). 

We probably need to give explicit instructions for SearchRequest.Filter
and SearchRequest.Filter.SubstringFilter.substrings.

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.
 
Ron
-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Jim Sermersheim
Sent: Wednesday, 17 September 2003 14:39
To: ietf-ldapbis@OpenLDAP.org 
Subject: Re: Protocol: Ignore SEQUENCE elements...


<Second try. I got no response last time.>

>>> "Jim Sermersheim" <jimse@novell.com> 7/14/03 3:16:38 PM >>>
All,

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
the
word "trailing").

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
a
reference, but I think the information might be handy. Also, we should
likely preserve the "trailing" word.

comments?

Jim