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

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Christian M. Amsüss <[e-mail]>
> Sent: Sunday, December 16, 2018 5:34 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: Questions and comments against the github version
> 
> 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.

Ok, I can accept this.

> 
> > * 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.)

My issue was not with the question of can the URI be referenced, but the
vague memory that I had where there were some things that one could have
that would make sense in terms of /.well-known/core but did not make any
sense when the same links were delivered from a RD.  It may be that by
always returning fully resolved URIs we have dealt with this problem and I
am just having bad memory echoes.

> 
> > * 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.

I was thinking in terms of the CT case for the small system that Peter had
referenced to for simple registration.  If the CT can go in and say that
this is good forever and does not need to leave some system around that is
going to need to do refresh of the registration information since it is not
ever expected to change.  I recognize the inherent risks in that a device
may be taken out of service and the registration not removed but I think it
may be a simple system optimization.

Jim

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