Re: [core] Questions on draft-ietf-core-resource-directory-12

[peter van der Stok <[e-mail]>]

> 
>> > POST /rd?ep=node1
>> >    - payload contains the set of resources the register.
>> >    - returns a location of /rd/yyyy
>> >
>> > POST /rd/yyyy?ep=node1
>> >    - payload is empty.
>> >
>> > In the first post, the rd will infer a context based on how the
>> > registration is done.  The second post just says that the TTL value
>> > is to be refreshed back to the life-time value.  However, the
>> > inferred context could also be changed.
>> 
>> Thanks for the example; it would take me long to figure this out 
>> otherwise.
>> 
>> Reading the update specification, the ep=node1 is illegal in the 
>> update.
>> Specifying ep means creating a new registration.
> 
> ep=node1 would be ...well not technically illegal (the template would
> put the ep in extra-attrs, and the server hopefully not store it 
> there);
> it is an attribute that is not changing and therefore SHOULD NOT be
> included in the update by the client.

I do not follow.
Registration template:
EP->RD
POST
URI template {+rd}{?ep,d,lt,con,extra-attrs*}

Update template
EP->RD
POST
URI template {+rd}{?lt,con,extra-attrs*}

What distinguishes Update from registration? => the presence of ?ep,d
saying that extra-attrs* can include ep makes life really difficult IMO.

sending a POST to /rd/123 can create a new registration at /rd/123/567, 
according to me, we did not distinguish resources as registration 
resource or general rd resource.

Am I missing something?

> 
> A changed ep would not create a new registration (we're at a
> registration resource already), but simply be refused.
> 
>> sending the update
>> POST /rd/yyy will update the lt value.
>> It is allowed to change the value of con in the update POST 
>> specification.
>> The question is:
>> When an updating ep, different from the registering one, sends the 
>> update of
>> lt, does the context change to the hosts relation value of the 
>> updating ep.
>> 
>> My gut reaction is no. it does not change the context value in the RD
>> because that needs an explicit ?con= in the update specification.
>> 
>> A warning in the RD text to this effect looks reasonable.
> 
> The text is already pretty explicit:
> 
>     "If the parameter is set in an update, it is stored by the RD as 
> the
>     new Base URI under which to interpret the links of the 
> registration,
>     following the same restrictions as in the registration.  If the
>     parameter is not set and was set explicitly before, the previous
>     context value is kept unmodified.  If the parameter is not set and
>     was not set explicitly before either, the source address and source
>     port of the update request are stored as the context."

Do we understand that the hosts relation does not set the parameter?

> 
> This allows for clients that do not keep a good eye on their addresses
> but have their OS pick the latest one.
> 
> Note that nobody other than the endpoint (or CT if created by one) may
> manipulate a registration resource.

but difficult to check or enforce. the registration has no memory of the 
registering ep.

> 
> (If we wanted to allow other hosts to manipulate a different endpoint's
> registration, we'd need something like a ?ct=keep or change in 
> semantics
> to allow that -- but I'd like to have a good reason to do that in the
> first place).
> 
>