Change:
Contributes-To: URL WIP, will continue there tomorrow (checking whether any other place in the document needs adaption, whether there's any place where to reiterate RFC6690's "is not expected to validate UTF-8 encoding (but is not prohibited from doing so) and doesn't need to perform any UTF-8 normalization", and whether RD-DNS-SD still uses ep and d as it did where the 63 byte limit came from.
It seems no further changes are needed – when ep gets encoded it is passed into Link Format which is already Unicode; lookup filtering also draws from there; those references also pull in the no-need-to-decode parts (and when it comes to accepting endpoint names, that's a policy issue anyway). RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays.
RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays. actually that is explicitly mentioned, Peter chrysn schreef op 2019-03-11 10:12: Links: [1] URL [2] URL
All we know from the draft is that it is ≤ 63 bytes. But we need to say that it is a UTF-8 string. Not entirely sure we want as an endpoint name either. Same for sector.
(via Jaime)
We certainly want to allow people to use license plate numbers as endpoint names, so at very least we need to support before they register as . More seriously, there are different uses of the endpoint name that may all warrant some restrictions to make them simpler (one could forbid the (quotation mark) character to ease RFC6690 serialization, the (ampersand) character to ease the representation of the registration operation's resource as a URI, forbid the (solidus) to allow RDs to use the ep in the registration URI, forbid the (full stop) character as DNS host names can contain dots but those can't be encoded in a URI), but at the same time there are applications for some of them (eg. dots are suggested in the NAI examples ). Limitations to which Unicode code points are there would be hard to enforce reliably, and I don't see a compelling reason to just "rule out everything that's not ASCII". If anything, one could think about the code points 0-31 (except some combinations of whitespace) and 127, which can't be represented in RFC6690 as they aren't part of RFC2616's TEXT (whoever then misses ANSI-colored endpoint names can fall back to QuakeIII style of – those examples may sound mocking, but serve to illustrate that we won't easily catch all the characters that are bad anywhere without becoming very restrictive). Being valid UTF8 is a requirement that we should just put in there (and check for others like sector). Any further limitations should IMO be policy-based, typically by the ep being limited to devices with known names anyway.
UTF-8 or even more restricted. Certainly not impose a structure.....
A suggestion from Wednesday's interim was to look into the URI/IRI ABNF rules for reasonable sets of characters. The sets in RFCs / are not directly helpful as their production rules either rule out the LwM2M patterns of using URNs in there (which require at least ":" to be permitted) or bring in URI structure which would be imposing structure – the "[i]query" rule, for example, would only permit many URNs, but contains the pct-encoded rule that says percent signs are only OK if followed by two hex digits. I've also looked into any restrictions we currently implicitly have would stem from there (given ep and d are passed in via URI template variable), but that's very relaxed, talks of strings and percent-encoding almost anything ("eplaced by its value as a string after pct-encoding any characters not in the set of unreserved URI characters"). For lack of better concrete options I'd reach into what can be used in link-format, phrased in RFC8288/7230 terms as HTAB / SP / 0x21-7E / 0x80-FF as long as it is valid UTF-8 (which is the innards of quoted-string with no exceptions for '"' or '' as those are escaping issues) and prepare text for that. (It also dawns to me that the cause of us having the problem of defining identifiers is that we did not think this with enough web in mind, that endpoint names should always be URIs (as that's the uniform identifier we have in the web) and that consequently a registration's endpoint name should not so much be an attribute but a typed link to the abstract definition of that endpoint – but given there are RDs out there already and we'd like to finish this draft, that can of worms stays closed for now.)
HT is evil. Must not be used. To me it now seems all of UTF-8 minus C0 (0x00..0x1f) minus 0x7F is desired. Or, if we also want to exclude C1, i.e. all 65 Unicode control characters:
Closed by d07dde44d4875091dcd8c7eb0380e3675e339d7a which should have said "Closes" rather than "Contributes-To" in retrospect.
I don't see any conflict with rd-dns-sd, a reference from rd-dns-sd to the RD draft looks appropriate.

Discussion:
defines a set of links as defined for /.well-known/core.  A Registration has six types of attributes: <del> a unique endpoint name ("ep") within a sector </del> <ins> an endpoint name ("ep", a Unicode string) unique within a sector </ins> a Registration Base URI ("base", a URI typically describing the scheme://authority part)

a registration resource location inside the RD ("href"), <del> optionally a sector ("d") </del> <ins> optionally a sector ("d", a Unicode string) </ins> optional additional endpoint attributes (from iana-registry)

RD, as obtained from discovery. Endpoint name (mostly mandatory).  The endpoint name is an <del> identifier that MUST be unique within a sector.  The maximum length of this parameter is 63 bytes.  If the RD is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </del> <ins> identifier that MUST be unique within a sector.  As the endpoint name is a Unicode string, it is encoded in UTF-8 (and possibly pct-encoding) during variable expansion (see RFC6570 Section 3.2.1).  The endpoint name MUST NOT contain any character in the inclusive ranges 0-31 or 127-159.  The maximum length of this parameter is 63 UTF-8 encoded bytes.  If the RD is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </ins> Sector (optional).  The sector to which this endpoint belongs. <del> The maximum length of this parameter is 63 bytes.  When this parameter is not present, the RD MAY associate the endpoint with a configured default sector or leave it empty.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </del> <ins> When this parameter is not present, the RD MAY associate the endpoint with a configured default sector or leave it empty. The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </ins> Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the