Draft: draft-ietf-core-resource-directory

Commentary: … . Location - Path Location - Query has not been allowed so far but not forbidden either . This makes a decision against allowing a query component on grounds of potential conflict with query arguments later at the Registration Update operation . The issue of URI templates that would need modification to do the right thing ( become { & lt , con , ... } for registration update rather than { ? lt , con , ... } if query is present ) additionally weighs in favor of disallowing them . Various occurrences of " Location " , " Location - Path " and " location " throughtout the document have been updated to use the correct term for the HTTP header , the CoAP option and the resulting URI , respectively . Closes : Submitting a " no Location - Query " proposal as announced on ; I happily make the opposite proposal based on this too if someone has an idea of how to deal with the conflict in the update operation and feels strongly torwards the other direction . 
 Hi  , what is location header ? and and empty payload is returned after registration ? I approve the restriction on query parameters cheerio ,   schreef op 2018 - 04 - 17 18:31 : 
 The Location header is HTTP 's equivalent to the Location- * ( Location - Path , Location - Query ) options of CoAP . Yes , but I think it 's not explicit ; can add that . 
 We currently do n't say anything about a Location - Query that could be possible in a response to an initial registration ( ie . whether the registration resource 's URI can have a query parameter in it ) . Opinions are divided on whether we should have it at all , but if we want to have it , we need to do something about URI template weirdnesses . See discussion on
Mailing list commentary: There would not be a conflict with use in links descriptions , but still would be with extra parameters in a registration update . On those grounds I 'll propose a text to rule out query parameters . Thanks Christian
Hello , , hello ( responding cross - thread to the Location - Query point ) , ( removing DNS - SD from the thread because I do not expect those topics to be particularly interesting there ) yes , as I am finally going thorough the existing issues and changes . The good reason is that we are using URI templates in the registration update operation : { + location}{?lt , con , extra - attrs * } While it should be intuitively obvious that for location="x://y / z?a = b " and lt="42 " , the produced URI is " x://y / z?a = b&lt=42 " , RFC6570 Section 3.2.8 does not describe peeking back at what has been expanded to the left side , but prescribes a " ? " to be used before the first value , so the produced URI would be " x://y / z?a = b?lt=42 " ( or possibly ? a = b%3Flt=42 but not ? a = b&lt=42 ) . If I ' m reading RFC6570 wrong here , Location - Path can be allowed and I 'd be happy . Otherwise , we have to choose between using formal URI templates here ( vs. saying that some query parameters can be appended ) and allowing Location - Query . ( Requiring anyone to understand ? foo = bar?baz = qux as two keyswould be madness so it 's not an option . ) link - json/-cbor is not helping with the issue of [ 1 ] . Whoever receives a link - format+json document and wants to follow a link given there needs to take the href and the anchor , and look up in RFC6690 Section 2.1 , which is the very root of my misgivings about the situation . [ 1 ] : I do n't know from a procedural PoV -- can we ? And how far can that go ? Best regards Christian
Paragraph (version A):
be included in the response when a new registration resource is
created.  This Location MUST be a stable identifier generated by
the RD as it is used for all subsequent operations on this
registration resource.  The registration resource location thus
returned is for the purpose of updating the lifetime of the
registration and for maintaining the content of the registered
links, including updating and deleting links.  A registration with
an already registered ep and d value pair responds with the same
success code and Location as the original registration; the set of
links registered with the endpoint is replaced with the links from
the payload.
Paragraph (version B):
Location header MUST be included in the response.  This location
MUST be a stable identifier generated by the RD as it is used for
all subsequent operations on this registration resource.  The
registration resource location thus returned is for the purpose of
updating the lifetime of the registration and for maintaining the
content of the registered links, including updating and deleting
links.  A registration with an already registered ep and d value
pair responds with the same success code and location as the
original registration; the set of links registered with the
endpoint is replaced with the links from the payload.  The
location MUST NOT have a query or fragment component, as that
could conflict with query parameters during the Registration
Update operation.  Therefore, the Location-Query option MUST NOT
be present in a successful response.
Paragraph (version A):
be returned in response to a successful group CREATE operation.
This Location MUST be a stable identifier generated by the RD as
it is used for delete operations of the group resource.
Paragraph (version B):
Path option MUST be returned in response to a successful group
CREATE operation.  This location MUST be a stable identifier
generated by the RD as it is used for delete operations of the
group resource.  As with the Registration operation, the location
MUST NOT have a query or fragment component.