Subject: Fwd: [httpbis] #364: Capturing more information in the method registry

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 16:50:25 +1000

FYI, new issue as per recent discussion.

Begin forwarded message:

> Resent-From: [email-masked]
> From: "httpbis" <[email-masked]>
> Subject: [httpbis] #364: Capturing more information in the method registry
> Date: 3 July 2012 4:48:23 PM AEST
> To: [email-masked], [email-masked]
> Reply-To: [email-masked]
> 
> #364: Capturing more information in the method registry
> --------------------------+-----------------------------------------------
> Reporter:  mnot@…        |      Owner:  draft-ietf-httpbis-p2-semantics@…
>     Type:  design        |     Status:  new
> Priority:  normal        |  Milestone:  unassigned
> Component:  p2-semantics  |   Severity:  Active WG Document
> Keywords:                |     Origin:
> --------------------------+-----------------------------------------------
> We established the method registry in #72, and considered recording
> idempotency there. However, we closed that issue without a definitive
> answer, because we were still discussing the definition of idempotency.
> 
> Should we add idempotency to the method registry? Anything else?
> 
> -- 
> Ticket URL: <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/364>
> httpbis <http://tools.ietf.org/wg/httpbis/>
> 

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

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 3 Jul 2012 09:47:15 +0200

[Unable to create trace account, hence I'll add here]

>> Should we add idempotency to the method registry? Anything else?

Roy came up with a related table a while ago:

http://tech.groups.yahoo.com/group/rest-discuss/message/4732?var=0&l=1

Jan

---

From: Jan Algermissen <[email-masked]>
Date: Tue, 3 Jul 2012 09:54:16 +0200

> [Unable to create trace account, hence I'll add here]

Sorry - as always, it worked in the third attempt. Posted comment to ticket.

Jan

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 05:37:37 +1000

My .02 - 

I think we should list safety and idempotency, at the most. 

Including other information is too simplistic; e.g., cacheability depends on a LOT more than the method, capturing how the method affects cacheability in a table is problematic (see: POST).

I'd also be OK with removing all such information, because people really need to read the WHOLE method definition.

Cheers,

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 15:54:56 -0400

Yes, I think safety and idempotence are most needed in this table of
previously registered methods.

Per Julian's comment: if one of the reasons to leave idempotence off the
list is that we don't know whether some of these methods are idempotent or
not, then I'd opt for saying that in this table ("UNK", etc.) rather than
leaving that property out of the table completely.

On a related note, I wasn't able to find any details on the method
registry. Anyone able to give me some pointers?
mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Tue, Jul 3, 2012 at 3:37 PM, Mark Nottingham <[email-masked]> wrote:

> Including other information is too simplistic; e.g., cacheability depends
> on a LOT more than the method, capturing how the method affects
> cacheability in a table is problematic (see: POST).
>
> I'd also be OK with removing all such information, because people really
> need to read the WHOLE method definition.
>
> Cheers,
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 05:58:21 +1000

On 04/07/2012, at 5:54 AM, mike amundsen wrote:

> Yes, I think safety and idempotence are most needed in this table of previously registered methods.
> 
> Per Julian's comment: if one of the reasons to leave idempotence off the list is that we don't know whether some of these methods are idempotent or not, then I'd opt for saying that in this table ("UNK", etc.) rather than leaving that property out of the table completely.
> 
> On a related note, I wasn't able to find any details on the method registry. Anyone able to give me some pointers?

It's set up here:
  https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#method.registry

Cheers,

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 16:14:50 -0400

Thanks for the pointer, Mark:

In reading both 2.2 and 2.2.1 there is (in my mind at least) some discrepancy:

>From 2.2:
"Registrations MUST include the following fields:
- Method Name (see Section 2)
- Safe ("yes" or "no", see Section 2.1.1)
- Pointer to specification text"

>From 2.2.1:
"New method definitions need to indicate whether they are safe
(Section 2.1.1), what semantics (if any) the request body has, and
whether they are idempotent (Section 2.1.2)."

So, when registering a new method in the future, indicating Safety is
a MUST; indicating Idempotence is a .... SHOULD? MAY? And what of body
length/semantics, and cachability? SHOULD? MAY?

>From my POV, resolving the above Qs will better inform decisions on
how to complete the table in "Initial Hypertext Transfer Protocol
(HTTP) Method Registrations"

mca

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 06:16:55 +1000

It's common for the registration template to not reflect all of the requirements upon a registration.

For example, it would be at best inefficient to try to reflect the semantics of the body in the registry.

Cheers,

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 16:23:43 -0400

> For example, it would be at best inefficient to try to reflect the semantics of the body in the registry.

Agreed.

What I am asking here is on two fronts:
1 - does the _table_ in the proposed RFC ("Initial ... Method
Registrations") reflect the proposed _registry_ template?
2 - are any of the items mentioned in 2.2.1 (besides Safety) expected
to appear in the registry template?

I want to make sure I am not conflating things (RFC & upcoming
registry). Unless, of course, the point of both the RFC and the bis is
to do just that; establish a symmetry between the registry and the
RFC/bis.

mca

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 22:29:41 +0200

> Registrations") reflect the proposed _registry_ template?

Yes.

> to appear in the registry template?

So far, no. That's why we are having this discussion now.

> to do just that; establish a symmetry between the registry and the

The point of the registrations draft is to fill the template for those 
methods not defined by HTTPbis.

Best regards, Julian

---

From: "Musatov, Martin - CW" <[email-masked]>
Date: Tue, 3 Jul 2012 20:43:42 +0000

'pointer, Mark'? I'm not familiar. Is this a semantic term? :)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of mike amundsen
Sent: Tuesday, July 03, 2012 3:15 PM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: [httpbis] #364: Capturing more information in the method registry

>From 2.2.1:
"New method definitions need to indicate whether they are safe (Section 2.1.1), what semantics (if any) the request body has, and whether they are idempotent (Section 2.1.2)."

So, when registering a new method in the future, indicating Safety is a MUST; indicating Idempotence is a .... SHOULD? MAY? And what of body length/semantics, and cachability? SHOULD? MAY?

mca

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 17:01:12 -0400

Julian:

Thanks for the clarification.

I submit that the following be identified as "MUST appear" in the
method registry
- Method Name
- Safe (yes/no)
- Idempotent (yes/no)
- Link to documentation

All the above items are all "binary" and require no elaboration.

Body details and cache-ability should be identified as MUST items in
the documentation that defines the method, and need not be included in
the registry.

In the "Initial...." RFC, the Idempotent column MAY appear
blank/Uknown if it is decided determining this value for the items in
the list is too time consuming or will hold up timely completion of
the document. We can amend later, if desired.

mca