Subject: #545 requirement on implementing methods according to their semantics

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Jan 2014 10:38:02 +0100

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#rfc.section.4.1>:

"All general-purpose servers MUST support the methods GET and HEAD. All 
other methods are OPTIONAL; when implemented, a server MUST implement 
the above methods according to the semantics defined for them in Section 
4.3."

This ignores methods not defined in Part 2. How about:

"All general-purpose servers MUST support the methods GET and HEAD. All 
other methods are OPTIONAL; when implemented, a server MUST implement 
the above methods according to the semantics defined in their relevant 
specifications (as listed in the HTTP Method Registry maintained by 
IANA, described in Section 8.1.)".

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 03 Jan 2014 23:31:13 +1300

> IANA, described in Section 8.1.)".

+1.

Amos

---

From: Julian Reschke <[email-masked]>
Date: Fri, 03 Jan 2014 16:28:45 +0100

> IANA, described in Section 8.1.)".

Proposed patch at 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/545/545.diff>; 
includes some re-shuffling of paragraphs:

This changes the text below the table to:

    ...

    Additional methods, outside the scope of this specification, have
    been standardized for use in HTTP.  All such methods ought to be
    registered within the HTTP Method Registry (defined in Section 8.1).

    All general-purpose servers MUST support the methods GET and HEAD.

    All other methods are OPTIONAL; when implemented, a server MUST
    implement these methods according to the semantics defined for them
    in their relevant specifications (as listed in the HTTP Method
    Registry).

    ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sat, 04 Jan 2014 11:14:02 +0100

> IANA, described in Section 8.1.)".

There was a subsequent discussion between Roy and me in Trac...

Roy:

> The spec is correct as is. It is not our responsibility to require semantics of unknown or future methods. For example, a method might be defined by a few servers, implemented widely, proposed for standardization, and then specified by many drafts over multiple years. An HTTP server does not become non-conformant to HTTP as those definitions change -- they just don't conform to whatever spec (not HTTP/1.1) defines the new method.

Julian:

> True, but what I want to avoid is that implementers think that they can implement PATCH in their origin server any way they want. What's the correct spec text to ensure that?

Roy:

> The correct spec text would appear in the spec of that method, not the spec of HTTP/1.1.
>
> For example, consider experimental extensions to HTTP that have been deliberately published on the Experimental track instead of the standards track. Your suggested text would imply that those experiments have the same weight as the full standard.
 >
> I think what you want is some factual statement that describes the purpose of the method registry. In other words, it could say something about why methods should be registered, preferably in 8.1.2.

I think we need a clear statement that a server that implements a method 
not defined in P2 but registered with IANA needs to follow the spec as 
referenced by the IANA registry.

Yes, that can make an existing server non-conforming retro-actively if 
the authors chose to deploy a new method without standardizing and 
registering it.

Note that the IANA considerations for new methods require "IETF Review", 
so they do *not* exclude methods published on the Experimental Track.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 6 Jan 2014 16:47:19 +1100

On 4 Jan 2014, at 9:14 pm, Julian Reschke <[email-masked]> wrote:

> I think we need a clear statement that a server that implements a method not defined in P2 but registered with IANA needs to follow the spec as referenced by the IANA registry.

+1

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 27 Jan 2014 13:51:32 +0100

> IANA, described in Section 8.1.)".

Roy comments in the ticket 
<http://tools.ietf.org/wg/httpbis/trac/ticket/545>:

> Hmm, this is actually covered by p1 2.5 Conformance and Error Handling:
>
>    A recipient MUST interpret a received protocol element according to
>    the semantics defined for it by this specification, including
>    extensions to this specification, unless the recipient has determined
>    (through experience or configuration) that the sender incorrectly
>    implements what is implied by those semantics.
>
> Perhaps we can just delete the last bit above:
>
>     All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL. ; when implemented, a server MUST implement the above methods according to the semantics defined for them in Section 4.3.

(so the proposal is to remove the "; when implemented, a server MUST 
implement the above methods according to the semantics defined for them 
in Section 4.3").

I'm happy with this change, as it removes a statement that potentially 
causes confusion.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Jan 2014 13:54:05 +0100

On 2014-01-27 13:51, Julian Reschke wrote:
>> All other methods are OPTIONAL. ; when implemented, a server MUST
>> implement the above methods according to the semantics defined for
>> them in Section 4.3.
>

Seeing no objections: 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/2601.

Best regards, Julian