Change:
…. 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 added 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: URL 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 Chris, what is location header? and and empty payload is returned after registration? I approve the restriction on query parameters cheerio, peter chrysn 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 don'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 Hello Peter, Carsten, hello Jim (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) On Fri, Apr 13, 2018 at 09:04:33AM +0200, peter van der Stok wrote: 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 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]: URL I don't know from a procedural PoV -- can we? And how far can that go? Best regards Christian I shouldn't have written all those tank programs. -- Kevin Flynn
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 To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

Discussion:
The following response codes are defined for this interface: <del> 2.01 "Created" or 201 "Created".  The Location header option MUST 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. </del> <ins> 2.01 "Created" or 201 "Created".  The Location-Path option or 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. </ins> 4.00 "Bad Request" or 400 "Bad Request".  Malformed request.

The following response codes are defined for this interface: <del> 2.01 "Created" or 201 "Created".  The Location header 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. </del> <ins> 2.01 "Created" or 201 "Created".  The Location header or Location- 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. </ins> 4.00 "Bad Request" or 400 "Bad Request".  Malformed request.