Subject: [core] draft-ietf-core-http-mapping-12

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 02:38:50 +0200

Hello group,

I've read through the http-mapping-12 draft, I'm curious whether I've
spotted a consistency error and a needless constraint in the draft, or
just lack understanding of the involved mechanisms:

* 5.3 Default Mapping states that "[t]he default mapping is for the Target
  CoAP URI to be appended as-is to the HC Proxy URI". Given the HC Proxy
  URI would typically be "http://.../hc", literal appending of a CoAP
  URI gives "http://.../hccoap://..." without a slash after "hc". In 5.5
  Discovery, there is a "[t]he default template given in Section 5.3,
  i.e., {+tu}", again without a slash before it (similar with 5.5.1). As
  5.4 states that the URI Mapping Template is concatenated to the HC
  Proxy URI, this would not result in a slash. (I've also checked RFC
  6570 URI Templates: It does not specify any concatenation operation
  that would insert a slash.)
  
  In another place (5.4.1.1 2.), the template of "/{+tu}" is given as a
  default.

  My interpretation of those inconsistencies is that the intention is to
  have a default template of "/{+tu}", and that the 5.3 phrase just
  misses mentioning the slash that comes with the default template.

* 5.5 Discovery states that when discovered via CoAP, 'the link
  associated to the "core.hc" resource needs an explicit anchor
  referring to the HTTP origin', resulting in a link-format of

      </hc>;anchor="http://p.example.com";rt="core.hc"
  
  . While the anchor form is perfectly legal, why is it *needed*? A

      <http:/p.example.com/hc>;rt="core.hc"

  could at worst be interpreted in a way that it is hosted by the CoAP
  server (because "hosts" is the default rel and </> is the default
  anchor), but that would go away as soon as any other rel is used by
  the application, and I think the "http://p.example.com hosts
  http://p.example.com/hc" statement is not really valuable.

  Is there, apart from the "hosts" rel which an application might set
  to any other value (an ext-rel-type), a reason for the "needs"?

I know that it is late in the document process, and that neither of
these issues (if they are issues at all and not just my
misinterpretation) is likely to cause actually wrong implementations 
(implementors that followed the letters of '{+tu}' would be likely to
consider /hccoap:// to be buggy and fix it the obvious way). Is there
something we should do about this?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Jul 2016 08:27:03 +0000

Hi Christian,

Thanks very much for reviewing the draft.  It's never too late for bug
fixing!

>  misses mentioning the slash that comes with the default template.

I think you are right.

>  to any other value (an ext-rel-type), a reason for the "needs"?

My reading of RFC 6690 section 2.1:
"""
   Each link conveys one target URI as a URI-reference inside angle
   brackets ("<>").  The context URI of a link (also called the base URI
   in [RFC3986]) is determined by the following rules in this
   specification:

   (a)  The context URI is set to the anchor parameter, when specified.

   (b)  Origin of the target URI, when specified.

   (c)  Origin of the link format resource's base URI.

"""
is that we MUST force (a) because otherwise a client would use (b) which
is clearly wrong  since if the query comes from the CoAP side, the
"specified" origin is the coap:// origin -- and we need the http:// one
instead.

(Here my assumption is that (a), (b) & (c) are in strict order, otherwise
there would be no way to disambiguate situations where, for example, both
(a) and (b) apply.)

>something we should do about this?

We have to fix the slash-less {+tu} text occurrences.  I'm not sure when
-- before or during IESG review?  Jaime and Carsten will surely have a
sensible answer for this.

Cheers, t

---

From: Jaime Jiménez <[email-masked]>
Date: Mon, 18 Jul 2016 08:46:36 +0000

Hi,

As Thomas pointed out, there is still time to make the changes, you can submit a new version reflecting the late WGLC comments.

On 5.3. though the text could be made more clear by also pointing to the three 5.4.1.1 examples and by editing the text on 5.3 to "/{+tu}".

Ciao,
- - Jaime Jimenez

> On 18 Jul 2016, at 10:27, Fossati, Thomas (Nokia - GB) <[email-masked]> wrote:
> 
> Hi Christian,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Jul 2016 08:54:50 +0000

Hi Jaime,

On 18/07/2016 10:46, "core on behalf of Jaime Jiménez"
<[email-masked] on behalf of [email-masked]> wrote:
>As Thomas pointed out, there is still time to make the changes, you can
>submit a new version reflecting the late WGLC comments.

OK, will do.

>On 5.3. though the text could be made more clear by also pointing to the
>three 5.4.1.1 examples and by editing the text on 5.3 to "/{+tu}".

Agreed.

Cheers, t

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 11:06:15 +0200

On Mon, Jul 18, 2016 at 08:27:03AM +0000, Fossati, Thomas (Nokia - GB) wrote:
> > [...]
>    [...]

These bullets only give the context in the sense of base URI, which is
afaict not used for anything else than relative URI expansion. If an
absolute URI is given in the angular brackets, it expanding it based on
any base URI always gives the given absolute URI.

Best regards
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Jul 2016 09:39:17 +0000

>any base URI always gives the given absolute URI.

I agree that this would be a very sensible interpretation if you put
together RFC6690 and the definition of URI-Reference from RFC3986.
However, RFC6690 Section 2.1 seems to override that, by defining specific
rules (a-c) for defining the context URI for CoRE Link Format: "The
context URI of a link (also called the base URI in [RFC3986]) is
determined by the following rules **in this specification**: [...]"

What do other think?

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Jul 2016 10:27:09 +0000

Hi Christian,

On 18/07/2016 10:27, "core on behalf of Fossati, Thomas (Nokia - GB)"
<[email-masked] on behalf of [email-masked]> wrote:
>I think you are right

On second thought... I still think you are right that there is a slight
incongruence in the current text.  I guess the way to solve it is not to
change the default template to "/{+tu}" though, but rather to append a
slash to the the HC Proxy URI when needed -- that is, when the Target CoAP
URI is part of the path component of the Hosting HTTP URI, and not of the
query part.

I have appended a diff to show what I mean.

Cheers, t

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 17:22:57 +0200

> URI is part of the path component of the Hosting HTTP URI, and not of the

Well, both do work, either a slash after the default proxy HC Proxy URI
or one before the default URI Mapping template. If we go for the latter
(as you suggested the patch), at the very least 5.4.1.1 2. must be
changed to say '{+tu}' in the first line. The examples taken literally
don't need changing because they give an explicit HC Proxy URI in the
introduction, but I think it is a confusing example then to use '/hc' as
Proxy URI, either change all examples to the default or take a different
name altogether. (In the latter case, not that example 1 becomes
'.../hc/?target_uri...'; same for the 5.4.2.1 examples. Further, 5.5.1
needs updating in the first and second examples too in the same spirit.

I don't see reasons to not consent to any of the forms, but have a gut
feeling that I like '/{+tu}' better.

Cheers
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 18 Jul 2016 17:04:57 +0000

>feeling that I like '/{+tu}' better.

The problem with hardcoding the slash in the template is that then if your
HC Proxy URI is "http://proxy.example.org/hc?coap_uri=" then you'd end up
with a bizarre "http://proxy.example.org/hc?coap_uri=/coap://node/resource"

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 18 Jul 2016 19:51:40 +0200

> with a bizarre "http://proxy.example.org/hc?coap_uri=/coap://node/resource"

Agreed, this is likely to cause fewer confused implementors.

Do we have and want to guidelines to offer on which parts of the URI
would reasonably go into the HC Proxy URI and which would go into the
template? (It wouldn't have occurred to me to have everything and the
query string in the proxy URI).

Cheers
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 19 Jul 2016 08:40:12 +0000

Hi Christian,

(replying to the rest of your previous email)

On 18/07/2016 17:22, "Christian Amsüss" <[email-masked]>
wrote:
>Proxy URI,

The premise we do at the beginning of Section 5.4.1.1 is: "Note that these
examples all define mapping templates that **deviate from the default
template** of Section 5.3 to be able to illustrate the use of the above
template variables."

In fact, the "/{+tu}" in the second example is not the default template --
which looks to be pretty coherent with the premise and correct as to the
produced Hosting HTTP URI.

The alternative (as you suggest below) is to change all the examples in
the section, which I'd rather avoid: at this stage we should keep the
changes as small as possible.

Cheers, t

>either change all examples to the default or take a different

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 19 Jul 2016 08:52:37 +0000

Hi Christian,

>query string in the proxy URI).

IMHO it's not necessary.  As long as the default mapping always produces a
syntactically valid Hosting HTTP URI (which is the case, modulo IPv6
address brackets escaping) I think we are done with our job.

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 19 Jul 2016 12:49:46 +0000

Hi Christian, all,

We would like to submit http-mapping-13 before the end of the day with the
patch attached in [1].

I hope that solves the comments you raised (modulo the need to minimise
the changeset).  If not, please shout ;-)

Cheers, thanks,
t

[1] https://mailarchive.ietf.org/arch/msg/core/AEtYOFjJZ62GZO116AfamRv7o5k

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Jul 2016 16:30:43 +0200

> determined by the following rules **in this specification**: [...]"

(Not being an other, but still), I think that this is not overriding the
basic URI concatenation mechanisms, but only how the context URI is
determined (start of your quoted sentence).

Best regards
Christian

PS. Reply on the other topic is in the works and will arrive during the
evening.

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Jul 2016 17:17:18 +0200

> template** of Section 5.3 to be able to illustrate the use of the above

I was about to point out that they not only deviate from the default
template but also from the recommended Proxy URI, but found that unlike
core-resource-directory ("An RD SHOULD use the value "rd" for this
variable whenever possible."), it does not actually recommend that at
any time.

> produced Hosting HTTP URI.

That is correct, but the "i.e., the default URI Mapping template" is
not, it should be "could also be achieved with /hc/ as Proxy URI and
default template".

> changes as small as possible.

My opinion is that it's better to change them. Slashes at the end of
paths are a thing people like to get wrong, and the introductory
examples and the later ones using subtly different proxy paths IMO has
too much potential for confusion.

> address brackets escaping) I think we are done with our job.

I'm fine with that.

Thanks for managing this swiftly
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 19 Jul 2016 17:24:49 +0000

Hi Christian,

>determined (start of your quoted sentence).

I've found the missing piece :-)

RFC6690 Section 2.2 says the following about the "hosts" relationship:
"The target URI MUST be a relative URI of the context URI for this
relation type."

So, since the one we are specifying is in fact a hosts relation, we just
can't have an absolute URI in the link (i.e., something like
<http:/p.example.com/hc>;rt="core.hc").

Therefore Section 2.1 applies, therefore we have to use the anchor
attribute.

Cheers, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 19 Jul 2016 17:30:51 +0000

Hi Christian,

>variable whenever possible."), it does not actually recommend that at

Yes, we don't do that.  And the reason is RFC 7320.

>not, it should be "could also be achieved with /hc/ as Proxy URI and

Yes, you are right (and I've fixed it in my working copy).

>too much potential for confusion.

Do you have an outline already in mind?  Would you be able to provide
replacement text by the end of this week?

>> address brackets escaping) I think we are done with our job.

Good.

Cheers, thanks very much,
t

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Jul 2016 23:50:27 +0200

> replacement text by the end of this week?

I do and would; either the source file to edit and return as a patch or
a vcs clone to create a pull request would work most easily for me. We
can then still ask for opinions of whether the delta is small enough to
apply at that stage.

Best regards
Christian

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 20 Jul 2016 00:00:24 +0200

> "The target URI MUST be a relative URI of the context URI for this

Good catch, I would have missed that.

As the language in the section is not strong ("the link [...] needs an
explicit anchor" instead of "MUST be anchored"), I think this issue is
closed.

Thanks for your consideration
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 20 Jul 2016 08:54:34 +0000

Hi Christian,

>can then still ask for opinions of whether the delta is small enough to

Excellent.  I've attached my working copy.  You hold the edit lock now.

Thanks, t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 20 Jul 2016 08:55:24 +0000

Good.

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 20 Jul 2016 12:17:23 +0200

> Excellent.  I've attached my working copy.  You hold the edit lock now.

Attached, you'll find my modified version; thereby returning the edit
lock to you.

The bulk examples now all use the /hc/ Proxy URI like the intro
examples, often producing a /hc/?foo= pattern in the Hosting HTTP URI
(which may not be fully widespread but is neither wrong nor bad). Only
one example would have ended up with a double slash, so another path
component was introduced in the Mapping Template (/hc/ + forward/{+tu}),
otherwise the example would become completely moot (dropping it would be
an option too IMO).

During writing I've utilized the xml2rfc tool to generate HTML previews,
and noted that in 5.4.1.1, the enumerated example headlines did appear
below the example blocks. This might be a bug only in the xml2rfc
version I'm using, but you might want to have a brief look at if it
works for you.

Best regards
Christian

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 20 Jul 2016 11:17:00 +0000

Hi Christian, thanks very much!

>otherwise the example would become completely moot (dropping it would be

OK.

>version I'm using, but you might want to have a brief look at if it

It renders as expected using my xml2rfc (2.5.1).  (What version are you
using?)

I have attached the newest diff including Christian's edits.  If everyone
is happy with it I'm going to submit it by tonight.

Cheers, t