Subject: Re: Protocol: Ignore SEQUENCE elements...

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 16 Sep 2003 22:39:06 -0600

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

>>> "Jim Sermersheim" <[email-masked]> 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 stole 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

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Sep 2003 14:54:14 +1000

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: [email-masked] [mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Wednesday, 17 September 2003 14:39
To: [email-masked]
Subject: Re: Protocol: Ignore SEQUENCE elements...

All,

This is basically the same text as RFC2251 (we added the _why_, and the
word "trailing").

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Sep 2003 00:07:05 -0600

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" <[email-masked]> 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: [email-masked]
[mailto:[email-masked]]On Behalf Of Jim Sermersheim
Sent: Wednesday, 17 September 2003 14:39
To: [email-masked] 
Subject: Re: Protocol: Ignore SEQUENCE elements...

All,

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

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Sep 2003 16:52:06 +1000

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.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Wednesday, 17 September 2003 16:07
To: Ramsay, Ron; [email-masked]
Subject: RE: Protocol: Ignore SEQUENCE elements...

 
 
Ron
-----Original Message-----

All,

comments?

Jim

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Sep 2003 07:32:44 -0600

When I looked at the ENUMERATED types, it was obvious that there were no
cases that should be ignored. Yes, the statement referring to SEQUENCE
will remain, My message was questioning whether it also applies to other
things.
 
Typically, extension will be done by control, but we don't want to
prohibit some future extension where it makes more sense to modify the
ASN.1
 
Jim

>>> "Ramsay, Ron" <[email-masked]> 9/17/03 12:52:06 AM >>>

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.

Ron

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]] 
Sent: Wednesday, 17 September 2003 16:07
To: Ramsay, Ron; [email-masked] 
Subject: RE: Protocol: Ignore SEQUENCE elements...

- LDAPMessage.protocolOp. When unknown, there are explicit
instructions

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.

>>> "Ramsay, Ron" < [email-masked] > 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.

Ron
-----Original Message-----

>>> "Jim Sermersheim" < [email-masked] > 7/14/03 3:16:38 PM >>>
All,

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

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Sep 2003 08:49:10 -0600

John
 
>I do not like the notion of a blanket statement to ignore unknown
values in
>an ENUMERATION or CHOICE type. I don't think that it makes any sense
for
>any of the existing CHOICE or ENUMERATED types, 

I think this is the current consensus of the group

>with the possible exception
>of resultCode.

I wouldn't say ignore, I would say treat as unknown error.

Some of the CHOICE types have explicit instructions, and others
probably need explicit instructions.

<snip>

>Yes, X.680 does allow for extensible types, but you must explicitly
define
>them as extensible (using "...") 

Or using "EXTENSIBILITY IMPLIED"

>and presumably the type "designer" has
>considered the ramifications of making a given type extensible.

Right, that's what I'm hoping to do in this thread.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 17 Sep 2003 17:49:02 -0600

So to summarize, I don't think we want to change the statement in
Section 4 at all. Well, I do think we should put an "unless otherwise
specified" in there to allow specific instructions to override
instruction to ignore.
 
However, I think we may want to add explicit language on how unknown
CHOICEs in SearchRequest.Filter and
SearchRequest.Filter.SubstringFilter.substrings are to be handled.
 
Jim

>>> "Jim Sermersheim" <[email-masked]> 9/17/03 8:49:10 AM >>>
John

values in
for

<snip>

define