Re: StartTLS responseName became optional

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

Kurt D. Zeilenga writes:
>At 05:34 PM 7/22/2005, Hallvard B Furuseth wrote:
>> I've just learned that the StartTLS responseName changed
>> from mandatory to optional in Protocol-26, but I cannot
>> find anything about it in the LDAPbis archive.
>
> I believe this issue was previously discussed on the list
> and, IIRC, in face-to-face meetings.  I am on the road at
> present so cannot provide URLs.

The closest I can find is a thread 'starttls result codes' after
protocol-26 was released, but that did not mention responseName.

Do anyone else remember?  The dates of the drafts seems to put it
near the Control Combination wars, so I'm not surprised if I lost
it.  Or even if I participated and then forgot it:-)

I'll wait some days before responding after this (if I remember
to wait:-), in case someone finds the old thread first.

BTW, this change is not listed in Appendix C, "Changes".


>> (...) Thus, for backwards compatibility I think the spec should
>> be that servers still MUST send the responseName with any other
>> result code, though it wouldn't hurt to also say that clients
>> SHOULD or MUST accept responses without the responseName.
>
> I disagree.  Adding a MUST here will lead to clients being
> developed which are not accepting of the current practice of
> some servers not to provide a responseName in this case.

Eh?  That's why I suggested to add that clients SHOULD/MUST accept
responses without responseName.  And we wouldn't be _adding_ the
MUST for servers, we'd be restoring it after less than a year's
absence from a draft.  People have had five years to produce such
RFC 2830 clients.

> And if such clients did exist already, they likely have other
> problems.

Well, if common practice is to break RFC 2830 in this respect, I
suppose such clients might work poorly with servers that break the
standard in other common ways too.  Or do you mean something else?

>> While it seems pointless of RFC 2830 to require the responseName,
>
> Not only is it pointless, it is very bad for clients to
> require a responseName here.  Obviously there is the unrecongized
> case where the server cannot provide a responseName.

In that case RFC 2251 says ExtendedResponse.responseName
should be absent, so clients that require responseName even
with protocolError are broken.  So far we agree.  But -

> But there are likely other cases where a server cannot
> generate a responseName for some recognized control, for
> instance when the server fronts for a distributed system.

I don't understand, even after your next message.  This is just a
matter of composing a correct response.  How does a control or a
distributed system make it difficult to insert the responseName?
Drop this if I'm responding to banalities instead of what you mean
to say, but anyway:

Do you mean a control could tell the server to change the StartTLS
responseName field to something else than the StartTLS spec says,
and a distributed system would make that difficult?  If so I don't
see how it makes a difference to this problem what the StartTLS
spec says, be it absent, present or rot13-encoded responseName.
Nor why it is difficult.  The possibilities listed in 4.1.11 are
- make use of the control when performing the operation.  So
  the server will know what to put in the responseName field.
- not apply the control (because it's recognized by a distributed
  system component which is down?).  So the server will still know
  what to put in responseName: whatever the StartTLS spec says.
  And in this case either return unavailableCriticalExtension or
  ignore the control, depending on its criticality.

[Pasting from your next message]

> If it was not clear in my previous response, there are other
> cases where it is appropriate for a server not supporting an
> extended operation to return a result code other than
> protocolError.

Not according to [Protocol] 4.12:

   If the Extended operation associated with the requestName is not
   supported by the server, the server MUST NOT provide a responseName
   nor a responseValue and MUST return with resultCode set to
   protocolError.

I guess it depends on what you mean with "appropriate", and if you
mean something else with "support" than the draft does.  There are
times when it's appropriate for software to violate standards, but
it's not appropriate according to the standard.  And nothing
prevents software which violates the Extended Operation spec from
violating the StartTLS spec too, no matter what [Protocol] says.

> For instance, it would be reasonable for a server which is busy to
> return busy, or for a server which believes another server is better
> able to response to return a referral, or a server which has an
> internal error to return other, or operationsError when the request
> cannot be processed due to issues with other operations.

Sure.  But I don't see why any of that makes it difficult to
insert the responseName.  The server can't e.g. respond to an
extended operation with referral if it doesn't even (bother to)
recognize the extended operation.  Possibly that's a problem, but
if so the place to fix it is section 4.12 (Extended Operation).
If it does recognize the operation, it knows enough to compose a
correct response.

Well, except for severe internal errors.  But if the server is too
confused it can always drop the connection.

> A client which assumes that responseName is absent only when the
> resultCode is protocolError is broken.

Not according to RFC 2830.

[Back to previous message]

>> cleaning that up isn't worth breaking clients that also the
>> require responseName, if any.
>
> This is not merely protocol clean.  This is fixing existing
> broken clients.

Well, it's telling and encouraging broken clients to get fixed.
But as you see, I think it can also break correct clients.
I think it's better to encourage both clients and servers to
address the problem, so they will work together as soon as at
least one of them is fixed.

> The MUST lead to development of clients which absolutely
> required the responseName, even from servers which don't
> implement the extension.

I suggested a fix which covered that:  The StartTLS section
can say clients MUST accept an absent responseName.

> Another issue is that StartTLS technical specification,
> because of its inclusion in the core TS, is used as a
> template for future extended operation specifications.
> Having it do something which future specifications should
> not do is a bad thing.

RFC 2830 is a separate RFC detailing one extended operation, so it
can be used as a template for other such documents.  The LDAPbis
StartTLS spec won't be that.

If an extended operation spec should normally say the responseName
should be absent, that can be mentioned in Section 4.12 (Extended
Operation) or in the separate document you sometimes suggest which
could describe how to write extensions.  And the StartTLS spec
could mention that servers should include the responseName "for
the sake of backward compatibility".

-- 
Hallvard
For sale: Parachute. Never opened, used once, slightly stained.