Re: Protocol: control specifications.

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

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