[core] Review of draft-ietf-core-protocol-negotiation-07

[Christian Amsüss]

Hello protocol-negotiation authors,
hello CoRE group,

I'd like to offer a review and some suggestions to the document
draft-ietf-core-protocol-negotiation-07. My interest in the document is
both as a potential implementor, and as co-author of resource-directory,
which will in part be judged by whether it easily allows extensions as
suggested in protocol-negotiation.

* Introduction: It would be helpful to have RFC8323 and
draft-becker-core-coap-sms-gprs-06 referenced to understand how
different transports use CoAP URIs.

* Another document that describes a CoAP scheme is
draft-bormann-t2trg-slipmux-02 ("Hey coap+uart://ttyUSB0/, do you
happen to be available over the network too, just in case you get
unplugged?").

* coap+ws:// does not work like the example with
coap+ws://example.org/ws-endpoint/sensors/temperature suggests any
more. A more suitable example might be an HTTP proxy URI
('http://proxy.example.org/coap+tcp://eample.org/sensors/temperature').

* The example exchange in "Overcoming Middlebox Issues" confuses me: Why
would a client that has already established communication with a
server utilize an external service to discover more addresses? With
the current draft, this calls for the Alternative-Transport option.

* New Resource Directory Parameters:

* Why is `at` comma separated rather than a repeated parameter? The
former indicates limitations on the available characters (at least
the comma; is there any other syntax planned a la `;q=0.5`?), and
the latter would IMHO be more straight forward to implement.

* With changes to the RD in the latest versions, the endpoint lookup
looks a bit different. I've taken the examples of this section and
created some current ones in the upcoming RD draft ([1]).

Note that at least for the endpoint lookups, the `at` parameter does
not need to be implemented in a PN-aware RD, as it is the default
behavior for unknown RD Parameters to accept them on registration
and show them in an endpoint lookup.

I think that with the new behavior of the RD, the `tt` parameter
makes more sense in resource lookup than in endpoint lookup; would
you consider specifying it for there too?

Do the examples align with your ideas of how P-N can would work with
the latest RD?

[1]: https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#rfc.appendix.B

* Does `at` mean that *all* URIs on this server can have their
prefixes arbitrarily exchanged, or only the advertised links?

* Alternative-Transport option:

* Does this option state that the requested URI is equivalent to the
indicated ones, or all URIs on the host?

* Why is an option used here? The availability of an alternative
transport is a metadatum I think would be very suitable for
inclusion in </.well-known/core>. Expression as link metadata would
make the unmediated exchange more compatible with the RD-mediated
exchange, which right now look very different.

* The 'ol' CoRE Link Attribute: Did you consider using a link relation
for this? (Ie. there would be a dedicated link from the described
resource to its alternative URIs, rather than the URIs being encoded
in target attributes). The "alternate" or "duplicate" registered
relations seem to already do the required.

(Admittedly, I don't quite see the use case for individual link
alternative URIs; if the use case you have in mind answers the
question, it might be a good idea to outline that use case.)

* "Using CoRE Resource Directory": The example in 6.2 would, on a
lookup in a ol-unaware RD, return as shown here:

Req: GET coap://rd.example.com/rd-lookup/res?ep=node1

Res: 2.05 Content
[...]
<coap://node1-address/sensors/light>;if="sensor";
ol="http://[FDFD::123]:61616,coap://server2.example.com"

If the intention is that the href of the link can be re-interpreted
as a relative reference based on any of the ol values (btw: again,
why comma-separated?), this depends heavily on the serialization and
breaks when the serialization needs to be changed (as in the RD that
needs to return the absolute reference).

All things considered, I think that this is a document that should be
adopted by the WG; it covers a relevant topic and provides good starting
points for solving it.

Thank you, Bill and Mert, for writing this document
Christian

[Christian Amsüss]

Hello Bill and Mert,

during the review of protocol-negotiation, I came up with an idea that
is too far off from the document to go directly into a review. It might
be an overdose of web-linking talking here, so feel free to dismiss it
if need be, but maybe there are ideas in it that can help bring on p-n.

Let me start with examples and then explain what they should mean:

| Req: GET coap://node1/.well-known/core
| Res: 2.05 Content, Payload:
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"

or when registering at the RD:

| Req: POST /rd?ep=node1&con=coap://node1
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"
| Res: 2.01 Created, Location: /reg/1234

The endpoint registering at the RD could update the alt-base value(s) of
the link like it would update any other link it manages. (Admittedly,
that part of RD got postponed; might look like PATCH /reg/1234, Payload
{"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some
upcoming JSON link patch format).

Resource lookups would stay the same. Asking a server directly for
alternative transports could be done with GET
/.well-known/core?alt-base=* or /.well-known/core?alt-base=coap+ws://*.
This would be a dedicated request rather than piggy-backing onto any
existing one with a new option, but we're doing the same with any of the
other resource metadata as well, and a .well-known/core discovery is
often the first step in interaction anyway.

One way to give the protocol negotiation meaning to this would be only
two normative sentences:

| An "alt-base" attribute on a link means that representations of the link
| target are equally valid if the attribute's value were assigned as Base
| URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose
| of resolving relative references in the document. URIs obtained from the
| representation using any alt-base value are all related to the URI
| obtained from the same reference without considering the alt-base
| attribute by the "alternative" relation (and therefore to each other, as
| that relation is transitive).

(I've picked the "alternative" relation here; see my review comments on
the `ol` attribute. If no link relation is deemed suitable and you stay
with `ol`, the second sentence would need to say that they are
"equivalent for all REST operations supported by their protocols".)


The approach of transmitting the URI data in link attributes is
motivated by the RD's desire to not be anything more than a cache of
what can be discovered using .well-known/core discovery.


The explanation of being an "alternative Base URI" rather than a generic
alternative transport could be a middle ground between saying that only
a single URI is available somewhere else and saying that everything on
this address is available there: It only makes statements about the
links in the presented document. This would allow groups of resources to
state their equivalences.


The approach suggested here has some drawbacks: It is a bit more verbose
in terms of transmitted bytes, and requires constrained nodes to
synthesize variable data into payload that we usually take pride in
being able to assemble at build time. If there is interest in the
approach at all, I think we can overcome those.


Best regards
Christian

[Martin Thomson]

Just a tourist, but can someone explain why this design needs to be so
fundamentally different to RFC 7838?

Making the means by which a resource is identified differ based on the
means of interaction is something we have tried hard to avoid in HTTP.
Or maybe this is the key point of divergence between HTTP and COAP and
any attempt to address this is a lost cause.

On Sat, Feb 24, 2018 at 10:40 PM, Christian Amsüss

Post by Christian Amsüss
Hello Bill and Mert,
during the review of protocol-negotiation, I came up with an idea that
is too far off from the document to go directly into a review. It might
be an overdose of web-linking talking here, so feel free to dismiss it
if need be, but maybe there are ideas in it that can help bring on p-n.
| Req: GET coap://node1/.well-known/core
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"
| Req: POST /rd?ep=node1&con=coap://node1
| <>;alt-base="coap+tcp://node1",
| </sensor/temp>;if="core.s"
| Res: 2.01 Created, Location: /reg/1234
The endpoint registering at the RD could update the alt-base value(s) of
the link like it would update any other link it manages. (Admittedly,
that part of RD got postponed; might look like PATCH /reg/1234, Payload
{"1": {"href": "", "alt-base": ["coap+tcp://node1:1234"]}} in some
upcoming JSON link patch format).
Resource lookups would stay the same. Asking a server directly for
alternative transports could be done with GET
/.well-known/core?alt-base=* or /.well-known/core?alt-base=coap+ws://*.
This would be a dedicated request rather than piggy-backing onto any
existing one with a new option, but we're doing the same with any of the
other resource metadata as well, and a .well-known/core discovery is
often the first step in interaction anyway.
One way to give the protocol negotiation meaning to this would be only
| An "alt-base" attribute on a link means that representations of the link
| target are equally valid if the attribute's value were assigned as Base
| URI of the encapsulating entity (RFC3986 Section 5.1.2) for the purpose
| of resolving relative references in the document. URIs obtained from the
| representation using any alt-base value are all related to the URI
| obtained from the same reference without considering the alt-base
| attribute by the "alternative" relation (and therefore to each other, as
| that relation is transitive).
(I've picked the "alternative" relation here; see my review comments on
the `ol` attribute. If no link relation is deemed suitable and you stay
with `ol`, the second sentence would need to say that they are
"equivalent for all REST operations supported by their protocols".)
The approach of transmitting the URI data in link attributes is
motivated by the RD's desire to not be anything more than a cache of
what can be discovered using .well-known/core discovery.
The explanation of being an "alternative Base URI" rather than a generic
alternative transport could be a middle ground between saying that only
a single URI is available somewhere else and saying that everything on
this address is available there: It only makes statements about the
links in the presented document. This would allow groups of resources to
state their equivalences.
The approach suggested here has some drawbacks: It is a bit more verbose
in terms of transmitted bytes, and requires constrained nodes to
synthesize variable data into payload that we usually take pride in
being able to assemble at build time. If there is interest in the
approach at all, I think we can overcome those.
Best regards
Christian
--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Bill Silverajan]

Hi Christian,

Post by Christian Amsüss
Hello protocol-negotiation authors,
hello CoRE group,
I'd like to offer a review and some suggestions to the document
draft-ietf-core-protocol-negotiation-07. My interest in the document is
both as a potential implementor, and as co-author of resource-directory,
which will in part be judged by whether it easily allows extensions as
suggested in protocol-negotiation.
* Introduction: It would be helpful to have RFC8323 and
draft-becker-core-coap-sms-gprs-06 referenced to understand how
different transports use CoAP URIs.
* Another document that describes a CoAP scheme is
draft-bormann-t2trg-slipmux-02 ("Hey coap+uart://ttyUSB0/, do you
happen to be available over the network too, just in case you get
unplugged?").

The intro has now been changed and a reference to [1] added, which lists
all the alternative transports being used or being considered for use.

Post by Christian Amsüss
* coap+ws:// does not work like the example with
coap+ws://example.org/ws-endpoint/sensors/temperature suggests any
more. A more suitable example might be an HTTP proxy URI
('http://proxy.example.org/coap+tcp://eample.org/sensors/temperature').

This is true. One of the original intent of protocol negotiation is to
overcome URI aliasing and locater/identifier problems. We did not have a
standard way to terminate the ws endpoint but that has been recently
solved by RFC 8307 which then paved the way for RFC 8323.

However, I'm not confident of addressing the usage of HTTP proxying as a
viable use case for multiple transports so it's better to omit the
WebSocket example in this section.

Post by Christian Amsüss
* The example exchange in "Overcoming Middlebox Issues" confuses me: Why
would a client that has already established communication with a
server utilize an external service to discover more addresses? With
the current draft, this calls for the Alternative-Transport option.

Thanks, this was a legacy example that we overlooked. It has now been
changed to omit the RD, and a new example added to illustrate how an RD
can be used to discover non-IP transport endpoints.

Post by Christian Amsüss
* Why is `at` comma separated rather than a repeated parameter? The
former indicates limitations on the available characters (at least
the comma; is there any other syntax planned a la `;q=0.5`?), and
the latter would IMHO be more straight forward to implement.

It was a historic design decision to allow using 'at' as a non-repeating
parameter in previous versions of the RD, to keep it consistent with the
other non-repeatable parameters in the registration interface. This
consequently led to 'at' being a single key-value pair and having a
comma-separated list of base URIs.

However, now 'at' has been updated as a repeatable parameter after later
versions of core-rd introduced extra-attrs*, with which we can
(hopefully) extend.

Post by Christian Amsüss
* With changes to the RD in the latest versions, the endpoint lookup
looks a bit different. I've taken the examples of this section and
created some current ones in the upcoming RD draft ([1]).
Note that at least for the endpoint lookups, the `at` parameter does
not need to be implemented in a PN-aware RD, as it is the default
behavior for unknown RD Parameters to accept them on registration
and show them in an endpoint lookup.
I think that with the new behavior of the RD, the `tt` parameter
makes more sense in resource lookup than in endpoint lookup; would
you consider specifying it for there too?
Do the examples align with your ideas of how P-N can would work with
the latest RD?
[1]: https://core-wg.github.io/resource-directory/draft-ietf-core-resource-directory.html#rfc.appendix.B

Thank you, that was really very useful. The examples you provided have
now been taken into -08. I think we'd still need to review how usage of
'con' and the anchors as used in the current core-rd specification, can
aid with the discovery of multiple transports for CoAP.

Post by Christian Amsüss
* Does `at` mean that *all* URIs on this server can have their
prefixes arbitrarily exchanged, or only the advertised links?
* Does this option state that the requested URI is equivalent to the
indicated ones, or all URIs on the host?

These 2 comments are related:

The prevailing design approach was to register endpoint information per
server, and not per resource. Therefore, the URI scheme and authority
would differ, but the path is not affected. So they should be regarded
as equivalent only in the sense that they should point to the same resource.

Post by Christian Amsüss
* Why is an option used here? The availability of an alternative
transport is a metadatum I think would be very suitable for
inclusion in </.well-known/core>. Expression as link metadata would
make the unmediated exchange more compatible with the RD-mediated
exchange, which right now look very different.

/.well-known/ is the best place for site-wide metadata. The challenge is
to find some means of expressing transports available per-server in a
way that does not break the per-resource web linking, so I'm not sure if
/.well-known/core does that very well. The other way to go if we don't
use the Alternative-Transport Option is to define a new resource under
/.well-known/ whose representation contains values of available
transports. Could that be viable and registered to an RD?

Post by Christian Amsüss
* The 'ol' CoRE Link Attribute: Did you consider using a link relation
for this? (Ie. there would be a dedicated link from the described
resource to its alternative URIs, rather than the URIs being encoded
in target attributes). The "alternate" or "duplicate" registered
relations seem to already do the required.
(Admittedly, I don't quite see the use case for individual link
alternative URIs; if the use case you have in mind answers the
question, it might be a good idea to outline that use case.)

The per-resource motivation and usage of attributes is to facilitate
mapping to OCF's "eps" (described just before section 6.1)

Post by Christian Amsüss
* "Using CoRE Resource Directory": The example in 6.2 would, on a
Req: GET coap://rd.example.com/rd-lookup/res?ep=node1
Res: 2.05 Content
[...]
<coap://node1-address/sensors/light>;if="sensor";
ol="http://[FDFD::123]:61616,coap://server2.example.com"
If the intention is that the href of the link can be re-interpreted
as a relative reference based on any of the ol values (btw: again,
why comma-separated?), this depends heavily on the serialization and
breaks when the serialization needs to be changed (as in the RD that
needs to return the absolute reference).

Thanks, this has now been updated. Also "ol" has been made as a
repeatable attribute upon checking guidance from Section 2.2 in RFC 8288
about attribute cardinality. Does the example look better to you?

Post by Christian Amsüss
All things considered, I think that this is a document that should be
adopted by the WG; it covers a relevant topic and provides good starting
points for solving it.
Thank you, Bill and Mert, for writing this document

Thank you for the great review!

Best regards,
Bill

[1] draft-silverajan-core-coap-alternative-transports-11