|
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" <Ron.Ramsay@ca.com> 9/17/03 12:52:06 AM >>> 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:jimse@novell.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 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 b! e shorte ned with a reference, but I think the information might be handy. Also, we should likely preserve the "trailing" word. comments? Jim |