RE: Protocol: control specifications.

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi Hallvard,

I can't help feeling that you have answered your own question. Let's look at the cases:

1A: Server implements control and criticality incorrectly marked TRUE
1B: Server implements control and criticality incorrectly marked FALSE
2A: Server does not implement control and criticality incorrectly marked TRUE
2B: Server does not implement control and criticality incorrectly marked FALSE.

The server response is

1A: Server must use the information in the control to perform the operation. The result returned is the result of performing the operation; the server cannot advise the client on the use of controls
1B: This is the same as 1A: if a server CAN perform a control, it MUST perform it. Servers have no discretion when it comes to controls
2A: Server returns unavailable critical extension
2B: Server ignores the control.

That is, a server cannot make a comment about whether the criticality of the control is correct. This is because a server MUST take the control into account if it understands (implenments) it. If the server implements the control, it doesn't matter if the criticality is TRUE or FALSE.

Therefore, advice on the criticality of the control can only apply to clients. And servers cannot educate clients in this regard. As the discretion is with the clients, control designers should direct there remarks concerning criticality to the client writers.

Of course, there is the issue of response controls, but it seems that the criticality of these controls should always be FALSE.

Ron


-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Hallvard B Furuseth
Sent: Friday, 27 February 2004 19:46
To: Kurt D. Zeilenga
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Protocol: control specifications.


I should have replied to this before, but I got so frustrated that just
had to quit the discussion for a while.  I'll rush off a reply now
before going on holiday, just so it comes before the next IETF.  Sorry
about the bad timing, and about setting this up so I can't reply in
time.

Kurt, I think we have said to each other what there is to say about my
proposal: that servers SHOULD reject incorrect criticality on known
controls.  However, you have not replied several of the my points about
your proposal.  An argument against my suggested change is _not_ an
argument for the opposite change.

- You say the intent of the original text was to encourage extension
  authors to discuss the circumstances of when particular criticality
  values are appropriate.  I wonder how you know that, since it is
  very different from what rfc2251 says.

- X.500 does mostly mandate criticality TRUE when criticality is
  mentioned, not merely recommend it.  Though there is one place
  where it only recommends.  I don't know if a wrong criticality in
  X.500 is an error which MUST be reported, or MAY be reported, or what.

- I can't see that the current text allows the control spec to mandate a
  particular criticality, it only says the spec can give 'direction' for
  the value.  You said somewhere that 'direction' might be a mandate.
  If so, the text in [Protocol] should mention that explicitly.
  Also, it should make clear if it is talking about mandating the
  criticality protocol field, or the criticality value as used by
  the server (maybe ignoring the protocol field), or either.

- The original text could be read as allowing the server to return an
  error if the wrong criticality is supplied.  I can't see the new text
  saying that.  I don't remember at the moment what who ended up meaning
  about that, except it took some rounds of clarifications because you
  misunderstood why I read the text that way.

The current draft is even worse than your proposal, though:

   - Regardless of the value of the criticality field, if the server 
     recognizes the control type and it is appropriate for the 
     operation, the server is to make use of the control when 
     performing the operation. 

Now it _really_ isn't possible to treat wrong criticality as an error.
With this wording it doesn't make sense here to claim that "when
performing the operation" only applies if the operation is performed at
all, and that one can still return an error instead.

Kurt D. Zeilenga writes:
> John, Hallvard,
> 
> Are you aware of any server implementation which behaves consistently
> with the interpretation that you and Hallvard favor?

I really don't know many clients at all.

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

If you mean stating that the criticality is mandated, then as I've said,
I don't think your text says that at all.  I'd prefer

   - direction as to what value the sender should provide for the 
     criticality field

in the current draft to be changed to 'direction or requirements as
to...'.

-- 
Hallvard