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

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 4 October 2016 01:28
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Apps Directorate Review of draft-ietf-core-http-mapping-14
Resent-From: <[e-mail]<mailto:[e-mail]>>
Resent-To: Angelo Castellani <[e-mail]<mailto:[e-mail]>>, Salvatore Loreto <[e-mail]<mailto:[e-mail]>>, Akbar Rahman <[e-mail]<mailto:[e-mail]>>, Esko Dijk <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, Jaime Jimenez <[e-mail]<mailto:[e-mail]>>
Resent-Date: Tuesday, 4 October 2016 01:28


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.

[TF] Done


·         “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?

[TF] Done


·         “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?

[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 :-)


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

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


Specifics by section:

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

[TF] Done


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

[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.


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

[TF] Done


·         “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.

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


·         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”

[TF] Done


·         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.

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


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

[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.


·         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”.

[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.


·         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.

[TF] Done


·         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.

[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…


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

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


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

[TF] Done


·         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

[TF] Well spotted, thanks!


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

[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.


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

[TF] Done


·         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

[TF] Done


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

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


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

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


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

[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.