Re: FYI, resolution of "Digest" issue

> Larry, I think you owe the HTTP WG an explanation of your "null
> implementation", since it was never mentioned in the WG discussion. In my
> "peering" at the draft, I see nothing that has the word "null" in it and
> do not understand what you mean.

Well, I thought it was pretty self-explanatory, but I'll elaborate
publicly:

If you look at draft-ietf-http-digest-aa-04.txt, it doesn't actually
put many requirements on either clients or servers.  It says "a server
may assume Digest support when a client identifies itself as HTTP/1.1
compliant." So servers assume digest support. It says "a client is
encouraged to fail gracefully if the server specifies any
authentication scheme it cannot handle."

Since this is the language that we accepted through last call, it is
probably as strong a compliance statement we can make at this point,
without going back through another
revision. draft-ietf-http-digest-aa-04.txt does NOT say that clients
MUST prompt the user for authentication, or that clients MUST handle
digest authentication, all it says is that clients are encouraged to
fail gracefully (whatever that means) if it doesn't understand
digest. It does say "A server may assume Digest support", but it's not
clear what force that has on the clients. I suppose you could read "a
server may assume X support" as another way of specifying "a client
must support X".

This issue has arisen recently in the review of the MIME drafts of the
question of whether any mail clients 'support'
multipart/parallel. There are a lot of clients that 'support'
multipart/parallel by just treating it as multipart/mixed. Is that
'support'?

In any case, more tweaking of the language of the spec is not going to
be allowed without reopening one or both drafts in the working group.
I didn't hear anyone wanting to do that, actually, just people wanting
to vent their frustration.

What *is* the case is that HTTP/1.1 is fine, as is, for a Proposed
Standard, and that before we advance to Draft Standard and then
Standard, every feature must be implemented. The IETF process is set
up such that "what gets implemented affects what's allowed to be a
standard" rather than "what's a standard affects what gets
implemented". I think that's the strength of the process and that we
shouldn't try to change that.

> I'm not trying to be contentious, but I think it's inappropriate for you to
> declare a WG discussion moot in a message to the IESG when you as WG Chair
> never said so on the WG list. Further, this kind of action is especially
> inappropriate when the WG chair is in the minority of the rough consensus,
> as I feel is the case here. Regardless of individuals' motivations, most
> folks who spoke up (and there were plenty) agreed that
> digest-authentication should be a MUST in the spec.

This is really unfair, Paul. In the interest of getting on with
things, I sent a mail to the area directors, but I didn't respond
privately, I copied the list. If you actually disagree with my
recommendation, you have a chance to say so. I can't really tell from
your message whether you disagree. It's my understanding that we can't
actually add more constraints than are in the documents as written
without a reset to "last call" or (the alternative) writing a very
short RFC "applicability statement" and sending THAT into last call.

It sounds like you were reacting to my commentary rather than the
actual recommendation, though.

Larry

Received on Thursday, 29 August 1996 22:49:16 UTC