Subject: [art] Apps Directorate Review of draft-ietf-core-http-mapping-14

From: Larry Masinter <[email-masked]>
Date: Tue, 4 Oct 2016 00:28:26 +0000

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-core-http-mapping-14

Title: Guidelines for HTTP-to-CoAP Mapping Implementations

Reviewer: Larry Masinter

Review Date: 3 October 2016

IETF Last Call Date: (past)

IESG Telechat Date: 2016-10-13

Summary: lots of clarifications would be useful; could publish as Informational or Experimental with warnings about the extent of ambiguities.

Sorry for the late review; it was more complicated than I expected.

There’s a lot that doesn’t seem clear to me, but I did look at cited material

Major Issues:

I think all of the issues raised are relatively minor but easily fixed and worth fixing.

Minor issues;

Overall, Intro:

·         Informational vs.  standards track update of RFC 7252: While it contains informative implementation advice, it also seems to set normative requirements. But given the state of the document, “Experimental” might be most appropriate.

·         A reference to RFC 7228 in the intro for terminology might be helpful.

·         “Representational State Transfer (REST) based architectures such as the Web” a REST reference might help to clarify which REST you mean? Or is there anything here for which “REST” matters?

·         “It is up to CoAP protocol extensions (new methods, response codes, options, content- formats) to describe their own HTTP mappings, if applicable.”  -- how are they supposed to do this?

·         Does this spec apply to HTTP/2 as well as HTTP/1.1 ?

Specifics by section:

·         5.2 Nit: “Proprietary” usually has to do with ownership; the mapping here is “unique” or “private” or “unspecified”

·         5.3 For this to work, doesn’t the “HC Proxy URI” need to end in a “/” ?

·         Does “is always syntactically correct” mean “will result in a syntactically valid http URI” ?

·         “This is the URI that will then be sent by the HTTP client” but HTTP clients will usually send only the path/query part of the request URL.

·         5.3.1  “When found in a Hosting HTTP URI…”  I think this is ‘When constructing a Hosting HTTP URI by embedding a  Target CoAP URI” since “Target CoAP URI”  is defined to use “coap” or “coaps”

·         I think you either need to change it so “Target CoAP URI” has scheme and initial “://” optional, or else they’re there but you can omit them when filling in the template.

·         And how do you know which of coap or coaps was intended?

·         Section 5.3.2 seems to imply that Target CoAP URI is percent-encoded before embedding in the Hosting HTTP URI, but 5.3 Default mapping appends the Target CoAP URI “as-is”. Why only the [] in ipv6 addresses? In any case, not “as-is”.

·         5.4 “This will then be used by the HTTP client to construct the URI to be sent in the HTTP request to the HC proxy.” Again, it isn’t the URI that is (usually) sent.

·         5.4.1.1 these examples are difficult to read because the white space in the ASCII text isn’t enough to convey the boundaries of the examples. Consider ASCII art.

·         5.4.2 “verbatim” doesn’t cover IPv6 addresses, or where the scheme is omitted.

·         5.5 talks about “HTTP origin” without reference to what it means (I’m guessing having to do with same-origin policy).

·         5.5.1 OK  “Req” means “Request” and “Res” means “Response”, and the first two examples are of coap traffic while the rest are HTTP.  The Content-Lengths are 1 short:

</hc/>;rt=”core.hc”
has 19 characters

·         6.1 why don’t you need “some form of access control” even when strictly mapping content-types?

·         6.3  table 1 column 1 entries are “Internet media type pattern” since the entries aren’t Internet Media Types.

·         6.4 the mapping algorithm uses an IANA-maintained table, “CoAP Content-Formats”, as established by Section 12.3 of ….    It doesn’t use the chart from Section 12.3

·         Note that “Accept” headers are not simple content-type values yet you’ve not shown how to translate those values or match.

·         The pseudo-code in 6.4 seems like notes and undefined notation.

·         6.5.2 CoRE Link Format seems incomplete. Which agents / nodes are affected by this? What is the purpose of this section?

·         10 When content-type is mapped, there is a risk that the content with the destination type would have malware not active in the source type.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 10 Oct 2016 16:24:26 +0000

Hi Larry,

Thanks very much for the review, and sorry for the late reply.

I have inlined my replies, prefixed with a "[TF]" tag.

Cheers, thanks,
t

From: Larry Masinter <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 4 October 2016 01:28
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Apps Directorate Review of draft-ietf-core-http-mapping-14
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Angelo Castellani <[email-masked]<mailto:[email-masked]>>, Salvatore Loreto <[email-masked]<mailto:[email-masked]>>, Akbar Rahman <[email-masked]<mailto:[email-masked]>>, Esko Dijk <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Jaime Jimenez <[email-masked]<mailto:[email-masked]>>
Resent-Date: Tuesday, 4 October 2016 01:28

Reviewer: Larry Masinter

Major Issues:

Minor issues;

Overall, Intro:

[TF] Done

[TF] Done

[TF]  Either in the document where they are specified, or in a separate document.  I don't think it is necessary to be specific about how that happens.  As long as it happens :-)

[TF] Either.  The wire format is not important, the only relevant thing is the HTTP semantics.

Specifics by section:

[TF] Done

[TF] Not necessarily, e.g., it could also end with a '?'. I think the only restriction is that you can't have a HC Proxy URI that does not have at least one char after the authority.

[TF] Done

[TF] You are right.  Using "Effective Request URI" (https://tools.ietf.org/html/rfc7230#section-5.5) seems more appropriate here.

[TF] Done

[TF] I think we did the latter (in Section 5.4.1).

[TF] Sender and receiver have a private agreement in place to make that decision.  E.g., coaps URIs could go to one HC Proxy URI, whereas coap to another.

[TF] 5.3.2 says the only things that have to be percent-encoded are the square brackets of the IPv6 literal, not the whole Target CoAP URI.  They need to be percent-encoded otherwise the produced URI is syntactically invalid.  OTOH, you are right that the current "as-is" is imprecise.  I've fixed it.

[TF] Done

[TF] I agree, and I've tried to improve a bit the situation.  But the result is still far from brilliant.  The problem is that the resulting URI tends to be long and would not fit in a table column, for example…

[TF] Here verbatim refers to path and query.  So it should be OK.

[TF] Done

</hc/>;rt=”core.hc”
has 19 characters

[TF] Well spotted, thanks!

[TF] The idea is that the "[…] access control" is specific to that attack vector.  But you are right that as it's written at the moment it is confusing.  I guess I could just remove the sentence.

[TF] Done

[TF] Done

[TF] You are right.  That aspect is currently under-specified.

[TF] Is there any established pseudo-code format that I can look at?

[TF] The discussion about link-format transcoding has popped up more than once in the working group. 6.5.2 should give a bunch of reasons why it's not a good idea.

·         10 When content-type is mapped, there is a risk that the content with the destination type would have malware not active in the source type

[TF] Right,  done.