Subject: [weirds] Comments on draft-ietf-weirds-using-http

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 14 Sep 2014 23:27:19 -0700

Hi,

I've reviewed this draft and it's in pretty good shape.  I have the
following suggestions for the authors to consider as we march toward IESG
evaluation.  I think the most critical stuff is some revisiting of the
RFC2119 language and a couple of definitions.

1) Some editorial suggestions for Section 1:

- add a space between "HTTP" and "[RFC7230]"

- "Registration Data Directory Services" (the capitalization) made me go
look for a definition for that term, which of course isn't there.  Should
this be RDAP?  Should a definition be added?  Should it just be
de-capitalized?

- same thing happens in the same paragraph with "Registration Data" and
"Directory Services" separately, though it looks like "Registration Data"
is actually defined in the second paragraph so maybe that text can just be
moved to Definitions

- is there a definition of RESTful that could be included or referenced
here?

- Suggest changing "This data is typically provided" to either "These data
area typically provided" or "This information is typically provided"
("data" is actually plural)

- add a space between "GET" and "[RFC7231]"

- in the "basic usage pattern" list, the first bullet shows an example
query URL, but it ends with a period that's not part of the query.  Might
this be better separated out, like with <figure><artwork>?

- in the second bullet, delete "standardized by the IETF"

- should the third bullet reference the redirects draft?

- delete "It is important to note that"

2) In Section 2, "consideration" should be "considerations".

3) In Section 4.1, there are instances of both "SHOULD" and "should".  The
second one might better be "is usually".

4) Again about Section 4.1, the definition of SHOULD allows for deviation
from that advice when there's a good reason to do so.  Would it be worth
talking about other choices, and the impacts of using those options, and
why one might choose them?

5) Section 5's "SHOULD" has a similar issue.  Why would one choose not to
understand the response codes?

6) The example in Section 5.2 might be better done with <figure><artwork>
so an actual example can be viewed.

7) Section 5.3 talks about an "empty set", but this sounds a bit wrong to
me because an object can be undefined or it can be defined but empty.  It
sounds like we want to make it clear that we're saying "I don't have that
data" versus "I have a record for that, but it's empty."

8) Section 5.4 appears to suggest a client rejected for policy reasons can
retry.  Would it ever get a different result, unless the policy (or
permissions) changed?

9) In Section 5.6, remove the comma from the second paragraph.

10) Section 7 says the document requires use of HTTPS, but other than in
examples, this is the first reference to it.  Should a sentence or small
subsection be added about this somewhere earlier?

11) In Section 8.1, what are valid values for "Intended Usage"?

12) In Section 9.3, add a comma after "specified".

13) A general point: Should a small section be added someplace that refers
to the bootstrap protocol, at least to give some hint as to where the query
URL might come from?

---

From: Andrew Newton <[email-masked]>
Date: Mon, 15 Sep 2014 16:03:21 -0400

> - is there a definition of RESTful that could be included or referenced

My understanding is NO.

> subsection be added about this somewhere earlier?

It requires implementation, not use.

> to the bootstrap protocol, at least to give some hint as to where the query

That's a good idea.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 13:20:09 -0700

Hi Andy,

> > - is there a definition of RESTful that could be included or referenced

That's surprising.  I did find a wikipedia page that describes it but I
don't know if we consider that a sufficiently stable reference for RFCs.
I've asked on apps-discuss, but we can let it go as-is if there's no good
answer.

The IESG might ask us to define it, in which case we can do so in a
subsection or appendix, and later documents can refer to this one for such
a definition.

> It requires implementation, not use.

My point is that a single sentence in Security Considerations seems kind of
thin on the topic and fairly late in the document.  Also the wording "This
document requires..." made me think this was covered earlier, but it was
not.

-MSK

---

From: Andrew Newton <[email-masked]>
Date: Mon, 15 Sep 2014 16:59:00 -0400

> I've asked on apps-discuss, but we can let it go as-is if there's no good

Oh boy!

> subsection or appendix, and later documents can refer to this one for such a
> definition.

Well, they didn't the first time around.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 14:59:21 -0700

> > I've asked on apps-discuss, but we can let it go as-is if there's no good

Looks like it worked.  RFC7252 (CoAP) contains a citation they used for
REST, so we can just use that.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Sep 2014 16:48:00 -0700

> REST, so we can just use that.

How hard would it be to summarize the constraints defined on the Wikipedia
page into a small definition in this document?  It seems like writing down
something terse might be useful to this and future RFCs.

http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints

-MSK

---

From: Andrew Newton <[email-masked]>
Date: Tue, 16 Sep 2014 10:51:44 -0400

> http://en.wikipedia.org/wiki/Representational_state_transfer#Architectural_constraints

Just how much definition of "RESTful" (not REST) do you want? One
sentence? Or a section at the back of the draft?

-andy