Change:
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.

Discussion:
…. 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