Subject: Re: Protocol: control specifications.

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 08 Jan 2004 14:54:50 -0800

Though I think you might have misunderstand some of my points,
I likely some of yours, and that we're not exactly seeing eye to
eye on the "why", I think we've converging on acceptable
replacement text.  Here is my latest offering:

- guidance as to what value the sender should provide for the
  criticality field (note: the processing semantics of the
  criticality field, which are defined above, should not be
  altered in any way by the control's specification),

Comments?  Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 8 Jan 2004 22:45:20 +0100

Kurt D. Zeilenga writes:
>At 11:11 AM 1/8/2004, Hallvard B Furuseth wrote:
>>Kurt D. Zeilenga writes:
>>> As I previously suggested:
>>>> Consider the need to update a specification from "clients MUST provide
>>>> criticality field of TRUE" to "clients SHOULD provide criticality field
>>>> of TRUE".  Such a change could not be made if we require servers to
>>>> error where the criticality is not TRUE.
>>
>>Oops.  I notice I forgot to answer that:
>>
>>In terms of the current definition of criticality, this gives the
>>control different semantics.
> 
> By current, do you mean RFC 2251 or [Protocol].

I mean RFC 2251.  It says the definition of a control includes:

     - whether the control is always noncritical, always critical, or
       critical at the client's option,

To my eyes, this means that setting the control wrong is a user
error.  Good quality servers SHOULD reject such user errors, except
when that gets too hairy or cumbersome to implement.

I can see that you can instead interpret that wording alone as 'the
value of the criticality is as specified regardless of what is sent
over the protocol', but a few paragraphs above the RFC describes how
the server must act on the criticality _field_.  The 'field' refers
clearly to the criticality protocol element.

BTW, I note Jim has updated the text I quoted from rfc2251 to match
that.

> [Protocol] is
> certainly specifying different criticality semantics than RFC 2251.
> I argue that the change is inappropriate and problematic.

Well, we too argue for changes from RFC 2251, which the other of us
considers problematic...

> Anyways, when we say 'control semantics', there two portions:
> that defined by the "core" protocol specification and that
> defined by the extension specification (which are associated
> with the the controlType and associated controlValue).  We
> call this extension specification the "control specification".
> That might be part of the problem.
>
> The extension specification should not overload or otherwise
> alter the criticality semantics specified by "core" protocol
> specification.

Yes, I said I agree.  My original suggestion - which Jim adopted -
was bad, and so was my compromise suggestion.  So in the protocol-20
description of a control specification:

   - whether the criticality field should be always set to TRUE, always 
     set to FALSE, or sender's choice,

I agree completely that far (and want to go further), but the
following should be deleted:

     and server behavior when 
     constraints of this nature are violated,  

>>If there is a need to change this, then
>>the semantics of the control as currently defined is flawed.  One should
>>define a new and correct control instead, just as one should usually do
>>instead of changing the semantics of a control in any other major way.
> 
> Any decisions regarding versioning should considered as part
> of whatever process of which the technical specification is
> being maintained under.  Note our standards process certainly
> allows changes, even major ones, to be made without versioning
> changes (if that is deemed appropriate by the community).
> I believe it is quite common practice to defer such decisions
> to the community most effected by the change and to a time
> in which the (extension) specification is being revised.

Well, true.  I should have said, one should _normally_ define a new
control.  A major change in semantics is usually a bad idea, and
should be considered very carefully.

> I can certainly thing of cases where such a change would be
> quite appropriate,  for example, where the change is due more
> to applicability of the extension than to alter the semantics
> of the controlType and associated controlValue.

My point here is that a change in specified criticality _is_ a
change of semantics, and quite a major one in my opinion.  The
choice of whether to change the control or create a new one should
be seen in that light.

>>> I offer the the following replacement text:
>>>     - guidance as to what value should be provided for the criticality
>>>       field,
>>
>>Which even removes existing servers' license from rfc2251 to treat
>>wrong criticality as an error.  Please, no.
> 
> I don't believe the text I offerred says anything about how servers
> are to treat the criticality value.  However, given the history
> of control designers and implementors in this area, clarification
> (as I offerred) would be wise.

Huh?  The original rfc2251 text, quoted at the top of this message, says
- or can be interpreted to say, take your pick - that supplying another
criticality is a user error.  Your replacement text above does not in
any way say that, so I don't see how the server can be allowed to treat
it as an error.

OTOH, your following text does give a useful clarification:

>>>     (the processing semantics of the criticality field, defined above,
>>>     should not be altered in any way by the control specification)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 08 Jan 2004 12:23:03 -0800

>control different semantics.

By current, do you mean RFC 2251 or [Protocol].  [Protocol] is
certainly specifying different criticality semantics than RFC 2251.
I argue that the change is inappropriate and problematic.

The extension specification should not overload or otherwise
alter the criticality semantics specified by "core" protocol
specification.  That causes all kinds of problems, such as
increasing the complexity of implementation (allowing controlType
specific processing requirements associated to criticality
field may be hard to deal with in some implementations).

>>> Control specifications should detail under what circumstances the
>>> control generator should mark the control critical or non-critical.
>>> However, they should not detail any semantics upon the implementation
>>> processing that control as those are defined in the general protocol
>>> semantics. 
>
>About the specifications doing so, I agree.  About [Protocol] doing so,
>I still disagree, as you can see.
>

>> and, given the past problems with control specifications
>> adding semantics to the criticality flag, I suggest the
>> following note be added as well to this bullet item:
>Fine.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 8 Jan 2004 20:11:46 +0100

control different semantics.  If there is a need to change this, then

Fine.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 08 Jan 2004 08:40:48 -0800

The current language regarding extension document guidance to
criticality is still problematic:
>     set to FALSE, or sender's choice, and server behavior when

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 9 Jan 2004 18:17:41 +0100

Kurt D. Zeilenga writes:
> replacement text.

I don't:-(

> Here is my latest offering:
> 
>   criticality field

That still has the problem that it removes the server's license to
treat the 'unadvised' criticality as an error.  In that, it goes
exactly in the opposite direction of what I want.  My preference is
this text from protocol-19:

   - whether the criticality field should be always set to TRUE,
     always set to FALSE, or sender's choice

Failing that, my second suggestion would be to revert to RFC 2251's
text:

   - whether the control is always non critical, always critical, or
     optionally critical, 

which at least won't introduce any incompatibility.
(Or s/optionally critical/sender's choice/, I liked the new phrase
better.)

Also, I'm still hoping for:

  If the criticality field for a supported control does not match
  the value required by the control specification, the server SHOULD
  NOT perform the operation, but instead return protocolError in the
  resultCode if the operation has a response.
    
or s/required by/in/ if we use the RFC 2251 text above.

>   (note: the processing semantics of the

I'd strengthen that:  s/should not/can not/.  Remove '(note: )'.
(Yes, I know.  Nobody is as fanatic as a convert:-)

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Jan 2004 10:15:08 -0800

Hallvard,

I believe you are missing a few aspects of the RFC 2251 text:
   This document does not define any controls.  Controls may be defined
   in other documents.  The definition of a control consists of:
     ...
     - whether the control is always noncritical, always critical, or
       critical at the client's option,

Note that the bullet is part of a statement of practices to be followed
in writing extension documents.  That is, this bullet is not stating a
requirement upon implementations of LDAP (including those implement
any control).  Someone implementing LDAP can completely ignore this
paragraph as it simply does not pertain to implementations.

Second, your interpretation of this text as an implementation requirement
is counter to the previous text detailing the protocol:
   The criticality field is either TRUE or FALSE.                      
                             
   If the server recognizes the control type and it is appropriate for
   the operation, the server will make use of the control when
   performing the operation.

This text, as been interpreted by most implementors as meaning that,
regardless of the value of criticality presented, a server is to make use
of a control when they recognize the control type and that control type
is appropriate for the operation.

You suggested text is also problematic for a number of reasons:
        1) servers don't, as far as I know, don't behave in the manner you
        describe,
        2) the suggestion is counter to "be liberal in what
        they accept" principle, and
        3) the suggestion hinders changes to guidance given (based upon
        operational experiences or otherwise).

Your primary argument to make the change is that servers should check
user input.  I think it can be reasonable be argued that checking user
input in this case is primarily the responsibility of the client (under
the clients "should be strict in what they send" principle).

I oppose the direction you suggest we take.

A few additional comments below.

At 09:17 AM 1/9/2004, Hallvard B Furuseth wrote:
>treat the 'unadvised' criticality as an error.

Again, the RFC 2251 text which this replaced does not specify any
implementation "license" as it simply did not pertain to implementors.
Was a profiling statement for extension specifications, as is the
replacement text.

>In that, it goes

As previously noted, this language could be viewed as limiting the
kinds of guidance which an extension specification could give.  For
instance, it does not allow an extension from saying:
        Criticality should be TRUE when X is TRUE.
or
        Criticality should be FALSE when Y is FALSE.

The intent of this original text was to encourage extension authors
to discuss the circumstances of when particular criticality values
are appropriate.  The text I proposes attempts clarify the text
to that intent while removing ambiguity that some have raised that
the text could be viewed as stating an implementation requirement
(instead of a document profile). 

>(Or s/optionally critical/sender's choice/, I liked the new phrase

The original text has most of the same problems as your suggested
text.

>  resultCode if the operation has a response.

It would be inappropriate to make such a statement in text intended
to detail a document profile.  When considers this as an addition
to the technical specification, absent the document profile, it becomes
clear that you are asking for a change in protocol semantics.

>(Yes, I know.  Nobody is as fanatic as a convert:-)

I think it clearer as suggested.

Kurt

---

From: John McMeeking <[email-masked]>
Date: Fri, 9 Jan 2004 14:55:16 -0600

No recommendation - just some observations...

X.511 has a similar notion of recommended criticality.  And it is just
that, a recommendation.  As far as I could tell, doing the equivalent of
modifyDN with new superior is done via an extension that the DUA may, or
may not mark as critical.  If the DUA does not mark this as critical and it
goes to a DSA that does not support this extension, the result will most
likely not be what was intended.  If the operation specifies a new RDN and
new superior, the result could be that the entry is renamed but left with
the same superior.  Weird, but...

I'm not saying that this doesn't have any risks.  I sympathize with
Hallvard's view that we ought to leave leeway for a server to discourage
such risky practices.

I'm tempted to suggest  "A server MAY reject a control that has a
criticality that violates the recommended criticality defined in the
control specification."

That doesn't introduce an incompatibility with older servers, and it gives
leeway to implementations with Hallvard's perspective on control
criticality.

However, it does introduce the possibility that a [popular or critical]
application that works great with servers that do not enforce recommended
criticality will not work with some servers.

You're going to make someone unhappy either way -- the user whose
application is doing bad things because it didn't specify the proper
criticality, or the user whose application works on other vendor's servers,
but not on his.

John  McMeeking

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 9 Jan 2004 22:05:01 +0100

Kurt, I'm suddenly wondering if I've misunderstood you completely,
and if so I don't know where.  So I need a bit of clarification
before replying to your latest message:

You are saying, I think, that current practice is for most servers
to ignore the criticality protocol field when the criticality is
given by the control spec.  Yet you suggest that control specs
should no longer say what the criticality _is_, they should merely
give guidance to what the field should be _set_ to.  Thus, there
will no longer be a criticality in the control spec which servers
can follow, so they all MUST change from current practice to always
obeying the protocol field.

Yet one of your arguments against my suggestion is that it changes
current practice.  My suggested change is merely a SHOULD.  Servers
may ignore it and keep doing what they do now.  Or if you disagree
about that, I may have made a mistake and should modify my
suggestion, but we can get back to that later.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Jan 2004 16:30:22 -0800

>before replying to your latest message:

After a couple of draft responses, I've concluded that there
isn't a good way to clarify my reply without taking a (big)
step back.

LDAP provides, in controls, a mechanism for extending the
semantics of an existing operation.  The extended semantics
are associated with the type of control (an OID) and
associated type-specific data (an octet string).

This mechanism also provides a facility by which a client
can indicate to the server that the extended semantics
associated with any particular control instance is critical.
That is, by marking a control critical, the client demands
that server not process the operation if it cannot make
use of the control.

Criticality was intended to be in the eye of the client
(based upon user input and/or guidance in the specification
of the particular control), not the server.

Also, the criticality field was not intended to have any
other semantic.  That is, the performance of the operation
as extended by the control is not intended to be dependent
on the criticality value.

I believe that most implementations behave as I describe
above, which I content is as intended.  I also believe
this section needs clarification to ensure future clients
and servers implement the technical specification in
a manner consistent with today's implementations.  My
suggestions are intended to do this.

I object to your suggestions are numerous grounds:
        1) that wasn't what was intended,
        2) that isn't what is implemented,
        3) that violates interoperability principles on
        which Internet is built on (be strict in what you
        send, be liberal in what you accept),
        4) that hinders subsequent revision of extension
        specifications, and
        5) it will limit how one control could extend
        an operation extended by other control(s).

(The last one is new.  For now, I'll leave it as something
for you and others to think about.)

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 09 Jan 2004 20:11:02 -0800

At 12:55 PM 1/9/2004, John McMeeking wrote:
>X.511 has a similar notion of recommended criticality. 

Similar or same?  Given that one of planned uses of LDAP
Controls was to provide a mechanism in which additional
X.511 semantics could be added to LDAP in a manner which
would facilitate implementation of LDAP<->X.511 gateways,
I think the intent was for the criticality semantics to
be the same.

X.511:
   The criticalExtensions component provides a mechanism
   to list a set of extensions which are critical to the
   performance of a Directory operation. If the originator
   of the extended operation wishes to indicate that the
   operation shall be performed with one or more extensions
   (i.e. that performing the operation without these
   extensions is not acceptable), it does so by setting the
   criticalExtensions bit(s) which corresponds to the
   extension(s). If the Directory, or some part of it, is
   unable to perform a critical extension it returns an
   indication of unavailableCriticalExtension (as a
   ServiceError or PartialOutcomeQualifier). If the Directory
   is unable to perform an extension which is not critical,
   it ignores the presence of the extension.

Sounds the same to me.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 12 Jan 2004 01:34:43 +0100

I believe this message answers the clarifying message as well as the
one I'm replying to.

> paragraph as it simply does not pertain to implementations.

Yes, of course.  But that leads to control specifications which say
that the criticality for a control is <something>.  What we are
talking about is how to implement <the LDAP spec + such a control
spec>.  And given that combined spec, and interpreting criticality
in the text you quoted as the criticality protocol element and not
the criticality given in the control spec (which seems the natural
way to read rfc2251 to me, given the context of that text), it is a
user error to provide the other criticality value.

Which is why I at the very least want servers to continue to be
allowed to return an error for it.

>    performing the operation.

That text says how to perform such an operation if it is performed
at all.  Then the RFC goes on to list, among other things,
circumstances when _not_ to perform the operation.

At least, that's how I'm reading it.

> is appropriate for the operation.

Yes, I agree with that.

We disagree about
- whether or not to perform the operation at all in various
  circumstances,
- how the various parties should get to participate in that
  decision: LDAP spec, control spec, server, and/or client, and
- what it is desirable that implementors choose to do about it.

> [Moving this part of your message further down - will need to
> address a few other points first]

> the clients "should be strict in what they send" principle).

That helps, but I'm afraid s/user/user or client programmer/ in my
arguments better expresses what I meant to say.

It's a good point, though.  A statement that clients SHOULD NOT (or
MUST NOT) send controls with wrong criticality would help.  However,
that's incompatible with telling control specs to merely supply
'guidance' about what criticality to send, like you suggest.

> implementation "license" as it simply did not pertain to implementors.

Again, the LDAP spec + such a control spec does.  Or rather, can be
interpreted to do.  If you read it as, the control spec may say what
the client SHALL set the criticality to, then it's a client error to
set it differently.  If you read it as saying what the criticality
of the control as considered by the server is, then it is not a
client error, but OTOH all the other text talks about how the server
shall react not to the spec's value but the criticality _field_.

Your proposal redefines what was previously client bugs - and
potentially quite harmful ones - to be features.  This solution does
not appeal to me, to put it mildly.

>> My preference is this text from protocol-19:
>>

I must have missed that.  I agree, allowing that is good.  However,
it can be done while retaining the spirit of the current text:

    - when to set the criticality field to TRUE, when to set it
      to FALSE, and when the sender may choose

(Or if going back to the rfc2251 text, reword to not talk about
'setting' the 'field', so people may interpret it either way.  But
if you see no point in that, then I certainly prefer text based on
the current [Protocol] text.)

That should also take care of this point in your clarifying message,

> are appropriate.

I wouldn't know.  If that was the intent, it's strangely worded -
strangely enough that I suspect you may be wrong about the intent,
however certain you sound.  It isn't what it says at all.

As for X.511 which is mentioned elsewhere in this thread, looking
that up left me rather confused.  A little below the text in section
7.3.1 (Critical extensions) which you quoted, it says:

  If the criticality of an extension is defined to be critical, the
  DUA shall set the corresponding bit in criticalExtensions. If the
  defined criticality is non-critical, the DUA may or may not set
  the corresponding bit in criticalExtensions.

i.e. the criticality in the spec is a mandate, not just a guidance.
However, it later says:

  The extensions, their identifiers, the operations in which they
  are permitted, the recommended criticality, and the clauses in
  which they are defined are shown in Table 1.

which indicates that e.g. the targetSystem's criticality=TRUE in
Table 1 is merely recommended, not mandated.  Then, in the
definition of targetSystem in section 11.1.2 (Add Entry arguments),
it reverts to saying:

  If the [targetSystem] argument is present, the targetSystem bit in
  the criticalExtensions parameter in CommonArguments shall be set,
  indicating that this extension is critical.

i.e. criticality=TRUE is mandated.

So I guess X.511 can be read either way, but it seems to lean
towards mandated criticality, not mere guidance.

There doesn't seem to be any text about which criticality to assume
if the client sends FALSE when TRUE is mandated, unless (a) you read
X.500 as saying the criticality is mandated, so this would be a
client error, and (b) there is text somewhere which requires the
server to catch such errors.

BTW, one note: Unlike LDAP, X.511 does not seem to allow the control
spec to mandate that the criticality is FALSE.

> The text I proposes attempts clarify the text

However, it also removes the possibility of interpreting the text as
saying the wrong criticality is a user error.  So any server which
reads rfc2251 as I do and returns an error, will be in violation of
the new LDAP spec.

> [Snip]
> to detail a document profile.

Of course.  It would be in the text about the LDAP protocol, not
about the control spec.

> When considers this as an addition to the technical specification,
> absent the document profile, it becomes clear that you are asking
> for a change in protocol semantics.

I don't understand what you mean here.  I'm suggesting to change an
implicit 'MAY' - implicit if one reads rfc2251 as I do - to an
explicit 'SHOULD'.  That is no change in protocol semantics.  I
might even argue that it is an implicit 'SHOULD' in rfc2251 (when
reading it as I do), since good quality servers SHOULD catch
client/user errors.

>         1) servers don't, as far as I know, don't behave in the manner you

A SHOULD about that does not make such servers wrong, but will push
them into moving in that direction.

Such a move will be a problem for some clients, but only the ones
that are buggy according to rfc2251.  I seem to care less about
keeping buggy clients working than you do, at least when the bug can
cause the client to do significant harm if someone switches to
another server implementation than the client was designed for.

>         they accept" principle, and

I've already said why I don't buy this argument.  This principle is
a guidance, not a command cast in stone.  I think it is harmful to
follow it here, and I see little advantage in following it.  If you
wish to argue that LDAP should always follow this principle, then
remove error returns from Stringprep, where LDAPbis has broken this
principle.

>         operational experiences or otherwise).

No, people can change the criticality in a new spec.  As I've said,
I think that is a major change in the semantics of the control, and
to make such a change rather than making a new control is a choice
to consider very carefully.

After all, the main effect of criticality is when the server
_doesn't_ implement the control, not when it does, so modifying the
control spec isn't going to help there.  The client is still sending
an operation which that server should not perform because the
operation is wrong without performing the control.  E.g. the no-op
control.  Changing the control spec won't affect that client.

> I think it clearer as suggested.

Both seem clear to me, they just say different things.  Your 'should
not' allows implementations to go against this note, my 'can not'
does not.

However, I have to retract that suggestion, because I have bad news:
There already are control spec RFCs that give the criticality field
additional semantics.  Look:

RFC2649 An LDAP Control and Schema for Holding Operation Signatures

   1.1.  Audit Trail Mechanism

   The SignedOperation
   Control MAY be marked CRITICAL, and if it is CRITICAL then if the
   LDAP Server performs the LDAP operation, then must include the
   signature in the signedAuditTrail information.

   2.  Signed Results Mechanism

   This control MAY be marked as CRITICAL.  If it is marked
   as CRITICAL and the LDAP Server supports this operation, then all
   search results MUST be returned with a signature as attached in the
   SignedResult control if it is willing to sign results for this user.

RFC2891 LDAP Control Extension for Server Side Sorting of Search Results

   2.1 Behavior in a chained environment

   If a client submits a sort request to a server
   which chains the request and gets entries from multiple servers, and
   the client has set the criticality of the sort extension to TRUE, the
   server MUST merge sort the results before returning them to the
   client or MUST return unwillingToPerform.

That RFC also has this mess:

   2. Client-Server Interaction

   3 - If the server supports this sorting control but for some reason
       cannot sort the search results using the specified sort keys and
       the client specified TRUE for the control's criticality field,
       then the server SHOULD do the following: return
       unavailableCriticalExtension as a return code in the
       searchResultDone message; include the sortKeyResponseControl in
       the searchResultDone message, and not send back any search result
       entries.

   4 - If the server supports this sorting control but for some reason
       cannot sort the search results using the specified sort keys and
       the client specified FALSE for the control's criticality field,
       then the server should return all search results unsorted and
       include the sortKeyResponseControl in the searchResultDone
       message.

So, (3) the control has an effect (returning sortKeyResponseControl)
even when the operation fails and unavailableCriticalExtension is
returned, and (4) if the server implements the control, there is no
such thing as the control having no effect when the criticality is
FALSE - even if the real point which the control was designed for is
not achieved.

Maybe it's less messy - but still ugly - to restate the control spec
as follows:

  The server SHOULD do this:

  - the control always succeeds if it is supported.  Its effect
    is to _attempt_ to sort the entries (according to a point I
    didn't quote) and to set the sortKeyResponseControl field in the
    result.

  - if sorting failed, the effect of setting criticality=TRUE is to
    return no entries, and to return unavailableCriticalExtension
    even though the control succeeded.

    (Does that mean the control succeeded even though operation
    failed?  Or does it mean that the operation succeeded but
    returned an error anyway?  My head hurts...)

It's a bit more complicated because of the rest of section 2, but
not significantly, I believe.

-- 
Hallvard

---

From: John McMeeking <[email-masked]>
Date: Tue, 13 Jan 2004 09:22:19 -0600

After further discussion here, I side with Hallvard.  There are likely to
be cases where the behavior of a control is such that it really ought to be
marked critical because the outcome when used with a server that doesn't
support the control is clearly undesirable.  To the end user, it is little
consolation that the application they are using is at fault because it
neglected to mark the control critical.

I haven't come up with an argument that a control must have
criticality=FALSE to prevent similar situations, so I suggest we get rid of
the "criticality always set to FALSE" part.

To make it clear that "criticality MUST be TRUE" is a requirement to both
the client and server and to avoid confusion (I hope) with previous
guidance that criticality always be set to TRUE, I suggest a specific RFC
"MUST" clause that can be used in future control specifications.  I don't
believe current control specification have such language, so there should
be no compatibility issue.  Support for a new control generally requires
some sort of server change; support for a new control could include a
mandatory criticality check.

That leaves control criticality options as:
- critical at senders choice, with a recommended criticality in the control
specification, or
- criticality MUST be TRUE

I suggest that we update protocal 4.1.11 as follows.

1) add the following text somewhere in 4.1.11:

   A control specification MAY state that "the control criticality MUST be
TRUE."
   If a control is defined in this way and the sender's control criticality
is
   FALSE, the server MUST return protocolError. If a specification does not
   state that "the control criticality MUST be TRUE" the sender's control
   criticality is used.

2) update the guidance to control specification writers:

   The specification of a control consists of:

   ...

   - a recommended control criticality, or a requirement that the control
     criticality MUST be TRUE.

John  McMeeking

> I think the intent was for the criticality semantics to

Yes, I could have used "the same".

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 13 Jan 2004 08:14:04 -0800

John, Hallvard,

Are you aware of any server implementation which behaves consistently
with the interpretation that you and Hallvard favor?  Is there any
existing clients which relies on this behavior?

If not, I don't think it makes sense to make a change which require
changes to be made to most (if not all) servers, especially where
those changes would cause breakage between pairs of interoperating implementations.

I think the suggested new text is pretty clear that if a control
specification really needs to alter the semantics of the server's
general criticality processing, the control specification needs
to state an imperative separately from the guidance it gives to
client.   That imperative would logically be part of the control's
semantics as it is semantics associated with a particular control
type.

Changing the 'core' TS to say that a "criticality MUST be TRUE"
implies both a requirement on the client and a requirement upon
the server is quite problematic as there are numerous control
specifications in existence which said this but intended that
statement to apply only to the client.

I know of know control specification which stated "criticality
MUST be TRUE" which intended that statement to apply to servers
nor am I aware of any server implementation which took such a
statement as applying to them.  Do you?

>   state that "the control criticality MUST be TRUE" the sender's control

This would change the interpretation of existing specifications
in a manner which was intended by their authors nor implemented
by previous readers, and this would lead to breakage.

>     criticality MUST be TRUE.

A control specification needs to provide adequate guidance.
Beyond that, if a control specification wants to change the
general semantics of the any protocol field, it should do
so in its text which details the semantics of the extension
information carried in the control.

I have prepared replacement text for the whole section
for the WG to consider.  I'll be posting it separately.