Subject: WG meeting in Washington?

From: Mark Nottingham <[email-masked]>
Date: Sat, 2 Oct 1999 02:43:27 +1000 (EST)

Are there plans for http-wg to meet at the next IETF? If so, I'd like to request that discussion about draft-nottingham-http-roles-00.txt be considered (I plan 
to have 01 available before the draft deadline). I'm of the opinion that it's most appropriate here, but I'm open to discussing alternate forums.

Thanks,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 01 Oct 1999 14:40:37 -0700

In message <[email-masked]>, Mark Nottingham writes:
>Are there plans for http-wg to meet at the next IETF? If so, I'd like to
>request that discussion about draft-nottingham-http-roles-00.txt be
>considered (I plan 
>to have 01 available before the draft deadline). I'm of the opinion that it's 
>most appropriate here, but I'm open to discussing alternate forums.

The HTTP working group is expected to close as soon as the last of the
existing drafts are moved to RFC.

While there is value in documenting some implementation concerns for HTTP,
your draft is not appropriate for the IETF standards track.  The reason is
because IETF standards specify the protocol, not the means by which servers
are implemented to conform to that protocol.  Phrasing a bunch of
implementation concerns as if they were protocol requirements is not
appropriate, however well intentioned and useful the document may be.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 3 Oct 1999 01:11:30 +1000 (EST)

> appropriate, however well intentioned and useful the document may be.

OK. I was thinking that it may have qualified as an Applicability Statement, as in section 3.2 of RFC 2026. Looking back, I see how that's probably taking 
too much license with what's there, at least for http-wg.

In any case, I'm happy if people just start thinking and discussing this stuff, irregardless of the status of the doc. If there is another more appropriate 
place that this sort of thing could live, please tell me.

Thanks,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Larry Masinter" <[email-masked]>
Date: Mon, 4 Oct 1999 10:42:10 PDT

I think that the HTTP working group mailing list
is an appropriate forum for discussion of
Mark Nottingham's document "Server-Side Roles in the HTTP".

Even after the working group officially closes, the mailing
list remains open for discussion of evolution of the
protocol, errata, and progression to 'Standard' status.

Please note that [email-masked]' is preferable to
[email-masked]'.

I've seen, for other protocols, an "Implementation Guide"
released as an Informational document. 

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 04 Oct 1999 20:07:27 -0700

>Mark Nottingham's document "Server-Side Roles in the HTTP".

Only if it isn't talking about issues of compliance and using the
key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
as described in RFC-2119.  That is not what an implementation guide
does, and I doubt that the IESG would want that in an Informational
document.

I have no objection to discussions on how to best implement HTTP,
or further rationale to back up the HTTP requirements.  What I object
to is implementation advice for general-purpose server technology
that is made-over to look like protocol requirements.  The W3C does
that sort of thing, but the IETF does not (at least not without clearly
distinguishing between informational content and protocol requirements).

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Oct 1999 04:12:35 +1000 (EST)

> distinguishing between informational content and protocol requirements).

Roy,

I didn't intend to 'make over' the advice to look like protocol requirements, but I freely admit that they can be interpreted that way; I 
chose to do it that way because it seemed the most natural and clear way to do so. My logic was that the requirements set forth 
in it were only in the scope of the document, so that a product could be referred to as compliant with it, over and above protocol 
compliance. This will hopefully be more clear in a future draft of the document (if there is indeed any point in further revision).

I apologize if it's not politic to submit this to the IETF, but it seemed the best place to start (as I don't have the cash to join the 
W3C). I am (or at least I was during the writing of this draft) very much an outsider. If someone has a suggestion about where 
this document would best reside (whether that place is in the http-wg or not, as there does seem to be some dissention), I'll be 
more than happy to talk about it (as I've stated before).

--
Mark Nottingham
http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 06 Oct 1999 15:56:08 -0700

>I didn't intend to 'make over' the advice to look like protocol requirements, 

Sorry, that wasn't intended as a criticism of you -- just the current
format of your draft.  If it were actually a protocol spec, I'd be
congratulating you on following the proper form and making it easier on
the reader.  What I am worried about is misinterpreting implementation
guidance as protocol requirements.

>but I freely admit that they can be interpreted that way; I 
>chose to do it that way because it seemed the most natural and clear way to do
> so. My logic was that the requirements set forth 
>in it were only in the scope of the document, so that a product could be
>referred to as compliant with it, over and above protocol 
>compliance. This will hopefully be more clear in a future draft of the
>document (if there is indeed any point in further revision).

I think it is a worthwhile document, provided that it emphasizes rationale
and not requirements.  For example, there is very good rationale for having
the server constrain the i/o interface to conform to the protocol, and there
are many examples you might use to explain the rationale, but the protocol
requirements do not change as a result.  However, phrasing that rationale
as "a server MUST do ..." is stating a protocol requirement even if the
scope of the document excludes protocol requirements.

>I apologize if it's not politic to submit this to the IETF, but it seemed the 
>best place to start (as I don't have the cash to join the 
>W3C). I am (or at least I was during the writing of this draft) very much an
>outsider. If someone has a suggestion about where 
>this document would best reside (whether that place is in the http-wg or not, 
>as there does seem to be some dissention), I'll be 

I'm not a W3C member, so I wouldn't encourage that path either.  What I
meant is that W3C does theoretically include implementation conformance 
among its members as part of its spec writing scope.

Larry is the one who decides what is or is not appropriate for this forum,
and it seems that he wants to discuss the document here regardless of its
eventual publication status.  I agree with his reasons, though again I would
prefer that the format be changed so that it won't be misinterpreted.

....Roy