Re: [core] Questions and comments against the github version

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

Hello Jim, Peter,

(trying to wrap up all the comments that have been exchanged here)

On Mon, Dec 10, 2018 at 06:22:48PM -0800, Jim Schaad wrote:
> *  In section 5.3, I don't understand why the rule exists that if the
> attribute values are different then the location of the registration needs
> to be changed.   It seems that this could lead to some interesting conflicts
> in behavior depending on what messages are used.

Frankly, I don't understand why those rules need to be here in the first
place -- from my PoV the only thing that matters is CoAP idempotency
(ie. identical messages that arrive with no other related operations
inbetween have the same result).

Peter, any concrete ideas on how to clean them up -- preferably in a way
that they don't speak of "updates"?

(My alternative would be: "The following rules" and their items, and
state that "Any Registration that has the same endpoint name and sector
('ep' and 'd' values) as a previously active one implicitly deletes that
registration." -- the idempotency rule stays intact and allows some
optimizations in terms of retransmission, but for everything else
everyone pretty please use the Location returned, whatever that is.)

> *  In Section 5.3 - What is the correct behavior if the RD is configured to
> recognize an endpoint, but the endpoint supplies a different name?  Is this
> an error or does one of them override?

4.01 Unauthorized. Were the credentials valid for any other ep, the
server could not "recognize" the endpoint; thus it follows that the
credentials are not good enough to create a registration with the given
ep value.

> * In section 5.3.1 - I assume it would be an error to include the base
> attribute - perhaps this should be explicit?

(pvds):
> The text says: "the base attribute is not accepted to keep the
> registration interface simple"
> Looks sufficient to me.

Agreed. I'd expect 4.00 Bad Request, but whoever sends that is already
in violation of the interface.

> * In section 5.3.1 - When doing simple registration, I do not believe that
> it should be a requirement that the result MUST be returned prior to doing
> the query.

See https://github.com/core-wg/resource-directory/issues/186

> * In section 5.3.1 - A valid response code might be 4.XX - method not
> supported if this functionality is disabled.  I am not sure what the "or is
> empty" means for the 4.04 response code.  Which one is empty, the RD or the
> EP? 

The 4.04 is an error here IMO that has been reitrated time and again in
the context of link format lookups (an empty list of links is distinct
from an absent list!); fixed.

> * In section 5.3.1 - Is the RD responsible for dealing with resource-link
> items which would not make sense by doing full resolutions on everything or
> re-writing them?

(pvds)
> For me a difficult question. "making sense" is very context/application dependent.
> The less the RD decides about validity of link contents, the better I feel.

It is generally demanded of the base URI that it "MUST be suitable as a
base URI to resolve any relative references given in the registration".
For regular registration that's explicit in the base parameter
description, for simple that follows from the registrant needing to
provide RFC6690 discovery (which doesn't work if links can't be
resolved).

If URIs make no sense, then that's the registrant's fault, and I don't
see how the RD could tell whether they do.

If the URIs can't be resolved (though I'm not sure the 3986 process
defines any error condition at all), then I'd treat that as equivalent
to any other syntax error in the submitted links (and either silently
fail or return Bad Request depending on what comes out of the above on
when the response is sent.)

> * In section 5.4.1 - s/lt,con/lt,base/

Thanks, fixed.

> * In section 5.4.1 - Description of 4.04 failure - I think this should be
> 'may have been garbage collected' as I believe from previous text that one
> should be able to refresh an expired registration.

Should say "may have been removed (explicitly or after its
expiration)"; that removal could have been explicit or as a concequence
of an overly long expiration. Fixed.

> * In section 6.4 - The example is missing the rt="core.rd-ep" attribute.  It
> appears to be required from the second paragraph.

Thanks, fixed (also on other locations).

> * In section 6.4 - Can you give an example of a "Links to endpoints"?  The
> only one that I can think of is 'base'.
> 
> * General - Should there be a value for lt which means infinite?

I think there should at least be a value for "as long as this TCP or
WebSocket connection is open" -- which primarily makes sense with an
additional "and please build a base name for me and act as a forward
proxy" parameter. Both can be covered using extensions.

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