Subject: Re: and/or (1..MAX) constraint (Was: protocol-27 comments)

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 09:21:21 -0700

I've re-added these, and will wait for WG consensus to remove them.

>>> "Kurt D. Zeilenga" <[email-masked]> 10/29/04 2:23:39 PM >>>
As chair, I note that the WG did specifically discussed adding
these constraints to the revised ASN.1 module, initially during
a [Filter] WGLC and then during a early [Protocol] WGLC. Based
on these prior discussions, and the fact that an issue was not
raised during the prior WGLC, I must assume that the consensus
of the WG is for the and/or Filter sets to explicitly include
SIZE (1..MAX) constraints in the ASN.1 module. Hence, I feel
obligated assume consensus supports keeping these constraints.

It seems however that some have raised "new" concerns supporting
dropping the SIZE (1..MAX) constraints, however, it not quite
clear what that concern is. Hence, I suggest that those who
support dropping these constraints based upon "new" concerns
detail those concerns to the WG and why it is necessary (or
appropriate) to drop these constraints. We'll discuss the "new"
concerns and see if consensus now clearly supports dropping
these constraints. In absence of a clear consensus to drop the
constraints, the chairs will direct the Editor to include
these constraints.

Kurt, as LDAPBIS co-chair

At 11:31 PM 10/28/2004, Jim Sermersheim wrote:
>>> 4.5.1. Search Request
>>
>>> Filter ::= CHOICE {
>>> and [0] SET OF filter Filter,
>>> or [1] SET OF filter Filter,
>>
>>Another change I do not remember from the list: The SIZE (1..MAX)
was
>>removed from the ASN.1 grammar (though the textual description still
>>requires at least one component). Why?
>This is the way it was in RFC 2251. At some point, [protocol] added
the SIZE (1..MAX) to the ASN.1 to make it consistent with the text. It
was then found that this prevents Kurt's T/F filter spec from working
without breaking protocol, so we removed the ASN.1 grammar.