[core] My wishlist for corr-clar

[Christian Amsüss <[e-mail]>]

Hello Carsten and CoRE,

while there's no established workflow for adding to core-corr-clar, here
are a few items I've collected and think would make good additions to
that document:

* A name for the path-less URI constructed from doing role reversal. RD
  would have been easier to write with this, and any role reversal is
  easier to argue about with it too, for example in OSCORE.

  * A statement on whether that can always be done even if the resulting
    URI can not be used by anyone else, or might not even have a proper
    URI representation (coap+tcp://...:ephemeral-port/ for the former,
    the address of the browser side of a websocket in for the latter).

  I've sketched up some strawman text (with potential not only better
  naming but also completely contrary statements) below.

* The text from lwig-coap defining the "block key"

  * echo-request-tag uses a slightly updated version of this (even
    though not naming it) that elective NoCacheKey options are not
    described as part of the "block key" (as they could safely be served
    by an intermediary if all else matches).

  (Anyway, the lwig-coap text could be a starting point.)

* Observation: Anything can cancel implicitly

  RFC7641 leaves it open how a new request on an active observation
  token should be processed if it's neither a registration update (which
  could only vary th ETag set) nor an explicit deregistration.

  Practically speaking, the server needs to assume that the client has
  lost any state it had of the observation (for otherwise it would have
  followed the protocol) and thus treat the old observation as cancelled
  and process whatever is in the new observation.

  corr-clar might be a good place to talk about this and pave the way
  towards sanctioning it. (In effect, that'd mean that anything in an
  observation can be changed by an observation update -- the server
  would treat it as a new registraiton anyway if it so wishes.)

Has there been any progress on moving corr-clar towards WG adoption, or
on its procedural side (how section status w/rt WG consensus is
managed)?

Best regards
Christian

---

Strawman text for the constructed URI:

  2.2 RFC7252-1.2 Terminology:

  RFC7252 hints at the possibility for role reversal in Section 9.1.1 by
  suggesting that the DTLS client should also act as the CoAP client,
  and RFC8323 accordingly distinguishes between a CoAP client and a
  connection initiator (however often they may coincide) in Section 3.3.
  They do not contain considerations for the URIs that'd describe
  resources on the DTLS client or connection initiator side.

  : Role-Reversal URI

  The Role-Reversal URI of a request is a URI based on which resources
  hosted by the endpoint that sent the request are named. Its
  construction depends on the protocol used.

  For CoAP over UDP, DTLS, TCP, TLS and WebSockets, the Role-Reversal URI is
  constructed by following RFC7252 Section 6.5 and RFC8323 Section 8.7,
  but with no CoAP options present, and using the source rather than
  destination address and port.

  For CoAP over TCP, TLS and WebSockets, that results in an address that
  is not generally usable (because opening such a connection would not
  succeed), but can still be used locally for the duration of the
  connection. Such URIs should not be used outside the host on which the
  Role-Reversal URI was generated, or for a longer than the connection
  persists.

  For CoAP over DTLS, TLS and secure WebSockets, the credentials
  presented by the Connection Initiator may be insufficient to justify
  using that connection as to access resources hosted on it.
  If applications use Role-Reversal URIs over secure protocols, they
  need to describe under which circumstances those URIs are usable.

  When used with IPv6, the source address can be a link-local address
  that requires a zone identifier to be disambiguated between several
  interfaces. A zone identifier is expressed following RFC 6874, and
  like Role-Reversal URIs in connection-based protocols can not be used
  outside the host which generated it.

  Note that a client can not express resources under its Role-Reversal
  URI in request payloads as relative references, as these requests's
  base URIs are ... [probably anonymous, with the application stepping
  in? the target URI?]. Resources on Role-Reversal URIs must be
  announced using relative references that use application-dpendant base
  URIs, or (preferably) perform resource discovery.

  {{I-D.core-resource-directory}} uses the Role-Reversal URI as the
  default value for the "base" registration parameter, and described
  explicitly there as it predates this definition.


-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom