Draft: draft-ietf-core-resource-directory

Commentary: Contributes - To : WIP , will continue there tomorrow ( checking whether any other place in the document needs adaption , whether there 's any place where to reiterate  's " is not expected to validate UTF-8 encoding ( but is not prohibited from doing so ) and does n'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   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 ,  chrysn schreef op 2019 - 03 - 11 10:12 : Links : [ 1 ] [ 2 ] 
 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 ca n'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 do n'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 ca n't be represented in RFC6690 as they are n'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 wo n'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 LwM2 M 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 which should have said " Closes " rather than " Contributes - To " in retrospect . 
 I do n't see any conflict with rd - dns - sd , a reference from rd - dns - sd to the RD draft looks appropriate .
Paragraph (version A):
Endpoint name (mostly mandatory).  The endpoint name is an
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.
Paragraph (version A):
Sector (optional).  The sector to which this endpoint belongs.
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.
Paragraph (version B):
Endpoint name (mostly mandatory).  The endpoint name is an
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.
Paragraph (version B):
Sector (optional).  The sector to which this endpoint belongs.
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.