[core] Comments on draft-ietf-core-resource-directory-11

[Jim Schaad]

1. In section 5.2 para 2 - Not sure if this is wrong or not. However I
would think that rt=core.rd-group is used to discover the URI path for RD
group operations not rt=core.gp. I note that core.gp is not listed in the
set of valid rt values in the template.

2. I am unclear of the proper interactions of the following items:
* The anchor attribute - does it override the context query parameter
* What happens if a full URI is given as the target? How does this
interact w/ the context query parameter?

3. For simple registration. If the client has needed to find the RD so it
knows where to do the post, why is the post not done to the RD rather than
to the /.well-know/core point?

4. It is not clear to me what if the patch payload of {data} should be
accepted. Looking at the document as JSON, there is always an array wrapper
around it so that this template never matches the resulting document. It
seems as if this should always be [{data}] instead. Is there an implicit
add of the array if absent? If you have a pattern of {data} and you match
multiple items, is that an error?

5. Is there an implication that if the resources associated with an
endpoint expire, that the endpoint expires from all of its groups as well?
Is there a different way that endpoints are registered with the RD?

6. Can an endpoint register zero items with an RD?

7. should there be some text on interactions between ETag and page/count
query parameters? What happens if there is a an update of the registry in
the middle of doing a sequence of queries about the links using these
options?


Jim


Typo
s/ecample.com/example.com/

[peter van der Stok]

Hi Jim,

thanks for these remarks, they do help in getting the text better.

Post by Jim Schaad
1. In section 5.2 para 2 - Not sure if this is wrong or not. However I
would think that rt=core.rd-group is used to discover the URI path for RD
group operations not rt=core.gp. I note that core.gp is not listed in the
set of valid rt values in the template.

absolutely, spot on. archaeological remains to be removed.

Post by Jim Schaad
* The anchor attribute - does it override the context query parameter
* What happens if a full URI is given as the target? How does this
interact w/ the context query parameter?

@Michael or @Christian, can you react; my web vocabulary does not always
suffice.

Post by Jim Schaad
3. For simple registration. If the client has needed to find the RD so it
knows where to do the post, why is the post not done to the RD rather than
to the /.well-know/core point?

section 5.3.1 refers to 5.3.2 where the client posts to the RD; and the
RD reacts.
Do you want more explicit text in 5.3.1? OR 5.3.1 and 5.3.2 integrated?

Post by Jim Schaad
4. It is not clear to me what if the patch payload of {data} should be
accepted. Looking at the document as JSON, there is always an array wrapper
around it so that this template never matches the resulting document.
It
seems as if this should always be [{data}] instead. Is there an implicit
add of the array if absent? If you have a pattern of {data} and you match
multiple items, is that an error?

I'm sorry, not to understand this remark.
we refer to section 5.4.4?
The template specifies nothing about the payload apart from the format
application/merge-patch+json
which is defined in RFC 7396.
RFC7396 allows arrays and simple objects in curly brackets in the
payload
Is the example incorrect? Do you want to remove the array brackets
because it is a single object?

Post by Jim Schaad
5. Is there an implication that if the resources associated with an
endpoint expire, that the endpoint expires from all of its groups as well?
Is there a different way that endpoints are registered with the RD?

Will put in additional text that removal of endpoint implies removal
from groups as well.

Post by Jim Schaad
6. Can an endpoint register zero items with an RD?

I expect so. Text can be added that registration of an endpoint with
zero links does not create the endpoint.

Post by Jim Schaad
7. should there be some text on interactions between ETag and
page/count
query parameters? What happens if there is a an update of the registry in
the middle of doing a sequence of queries about the links using these
options?

Correct remark.
In the CoMI draft I added warning text about interleaving with the block
option.
Do you consider that a warning note in the text is sufficient?
Getting interleavings handled correctly may lead to massive amounts of
code (and specification text); so to me a warning seems sufficient.

Post by Jim Schaad
Jim
Typo
s/ecample.com/example.com/

Noted
many thanks,
hope this meets your questions (partially)

Peter

Post by Jim Schaad
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core