Subject: [core] AD review comments on draft-ietf-core-http-mapping-13

From: Alexey Melnikov <[email-masked]>
Date: Thu, 1 Sep 2016 11:29:02 +0100

In Section 4: I think you should add an informative reference to HTML5.

In 5.4.1.1, example 3:

Would it be better to define a separate variable (in addition to "tu") 
which doesn't include the scheme? I don't see how your current example 3 
is valid as written, because your ABNF in 5.4.1 says that the scheme URI 
part is always included.

In 6.3: is the table fixed or can implementations do variations of it?

Excuse my ignorance, but does does "htc" attribute need registering with 
IANA?

In 9.2: "encoding consideration" should say "binary", because if the 
specific content format is not known, we can't say anything more 
specific than "binary".

"Provisional Registration" - should be "no".

In 10.3, last para: is this actually a good idea? What about 
opportunistic security and desire to prevent pervasive monitoring?

You are using Obsolete RFC 2616 reference. Please point to one or more 
latest HTTP/1.1 RFC.

Reported by ID-nits: RFC 2119 keyword use template doesn't match 
expected text.

Should the document cover HTTP PATCH?

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 1 Sep 2016 12:31:15 +0000

Hi Alexey,

Thanks very much for your comments.

>In Section 4: I think you should add an informative reference to HTML5.

OK

>is valid as written, because your ABNF in 5.4.1 says that the scheme URI

Last para of 5.4.1 "amends" the above ABNF saying:

  "The same considerations as in Section 5.3.1 apply, in that the CoAP
   scheme may be omitted from the Hosting HTTP URI."

Do you think it's not enough?

>In 6.3: is the table fixed or can implementations do variations of it?

The table is the default.  It is expected that an implementation can
refine it based on a) application-specific knowledge, b) registration of
new Content-Formats.

>Excuse my ignorance, but does does "htc" attribute need registering with

My understanding from previous discussions is that, since there doesn't
seem to be a registry for that, the hct attribute will be documented in
the Description of the new core.hc resource type in the "Resource Type
(rt=) Link Target Attribute Values" registry [1]. (I may be horribly
wrong, though.)

>specific content format is not known, we can't say anything more

OK

>"Provisional Registration" - should be "no".

OK

>opportunistic security and desire to prevent pervasive monitoring?

Personally, I agree with you.  My co-authors might have a different
opinion though?

>You are using Obsolete RFC 2616 reference. Please point to one or more

We do (normatively) reference the HTTPbis specs.  The reference to 2616 is
informative only -- it is used to highlight a difference in treating 201
responses' format between "original" HTTP and HTTPbis.

>Reported by ID-nits: RFC 2119 keyword use template doesn't match

Pardon my ignorance, but I don't understand what we'd need to fix here.

>Should the document cover HTTP PATCH?

This point was also raised by Christian [2].  The consensus was to do
avoid blocking this work on draft-etch (or any other protocol extension).

The following text was added to reflect the outcome of that discussion:

  "This document describes HTTP mappings that apply to protocol elements
   defined in the base CoAP specification [RFC7252].  It is up to CoAP
   protocol extensions (new methods, response codes, options, content-
   formats) to describe their own HTTP mappings, if applicable."

Cheers, t

[1] http://www.iana.org/assignments/core-parameters/core-parameters.xhtml
[2] https://www.ietf.org/mail-archive/web/core/current/msg07411.html

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 4 Sep 2016 13:07:13 +0100

Hi Thomas,

> On 1 Sep 2016, at 13:31, Fossati, Thomas (Nokia - GB) <[email-masked]> wrote:
> 
> Hi Alexey,
> 

I missed that. I think it would be much better to have correct ABNF with no textual amendments.
> refine it based on a) application-specific knowledge, b) registration of

Ok. You might want to clarify that.
> (rt=) Link Target Attribute Values" registry [1]. (I may be horribly

Ok. Maybe a registry should be created. Not necessarily in this document.

> Pardon my ignorance, but I don't understand what we'd need to fix here.

Update the sentence that talks about 2119 keywords to have the standard form. If you go to datatracker.ietf.org for your document and click on id-nits, it should tell you more.
> avoid blocking this work on draft-etch (or any other protocol extension).

draft-etch is now in IETF LC, so I think this argument is no longer valid. Was there any specific text proposed to cover PATCH on the mailing list?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 04 Sep 2016 15:32:16 +0200

> draft-etch is now in IETF LC, so I think this argument is no longer valid. Was there any specific text proposed to cover PATCH on the mailing list?

http-mapping is an informational document that is making use of the
extensive experience we have with mapping between HTTP and CoAP.

We don't have all that experience for PATCH yet.  Anything we could
write would be more speculative and, probably, premature.  I'd rather do
this in a future document.

Grüße, Carsten

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 4 Sep 2016 15:52:55 +0100

> On 4 Sep 2016, at 14:32, Carsten Bormann <[email-masked]> wrote:
> 
> Alexey Melnikov wrote:

Fair enough.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Sun, 4 Sep 2016 20:39:49 +0000

Hi Alexey,

>I missed that. I think it would be much better to have correct ABNF with

Will do.

>Ok. You might want to clarify that.

Will do.

>Ok. Maybe a registry should be created. Not necessarily in this document.

OK, I'd rather skip this then :-)

>Update the sentence that talks about 2119 keywords to have the standard
>form. If you go to datatracker.ietf.org for your document and click on
>id-nits, it should tell you more.

I've been staring at the thing for a while and it appears correct to me.
It looks like idnits doesn't take into consideration the RFC 2119 errata
(specifically errata 499 at [1])?

>draft-etch is now in IETF LC, so I think this argument is no longer
>valid. Was there any specific text proposed to cover PATCH on the mailing
>list?

Below in this same thread I see you agree with Carsten's argument re: lack
of implementation experience wrt the PATCH mapping.  I'm going to drop
this then.

I'll be back with a revised version that takes into account your comments
as well as the Gen-ART review shortly.

Cheers, thanks,
t

[1] https://www.rfc-editor.org/errata_search.php?rfc=2119

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 5 Sep 2016 14:33:01 +0000

Hi Alexey,

>opportunistic security and desire to prevent pervasive monitoring?

When we say:

 "By default, a HC proxy SHOULD reject any secured client request if
 there is no configured security policy mapping [...]"

The secured client request we are talking about is the embedded CoAP
client request, rather than the HTTP.

In which case, I guess the current text is fine -- except that we will
explicitly say "secured *CoAP* client request" to avoid any further
discombobulation.

Cheers, t