Howdy, On Thu, Jul 11, 2019 at 1:02 PM Michael Richardson <[email protected]> wrote:
> > Adam Roach via Datatracker <[email protected]> wrote: > > ยง5: > > >> MASA URI is "https://"; iauthority "/.well-known/est". > > > This doesn't make sense: iauthority is a component of IRIs, not of > URIs. In > > URIs this is simply an "authority." It's not simply a terminology > distinction: > > converting from an iauthority to an authority requires idna > encoding. Please > > consult with an IRI expert (which I do not consider myself to be) to > work out > > the proper terminology and procedures here. If you need help > finding an > > expert, please let me know and I'll track someone down for you. > > okay, this one is my fault. > I agree, we should have consulted an expert. I thought I was being clever. > Please, can you find us an expert, if you think we should go this > direction. > > I thought IRIs were supersets of URIs, and that all URIs were IRIs, and the > only reason to RFC3987 instead of RFC3986 is because one might have legacy > systems that couldn't handle idna. Since I thought we had a greenfield > here, > I figured we could specify the superset. > > It is correct that all IRIs are URIs, but the core purpose of the IRI was to be a presentation format. The presumption was that you turn it into wire-format (that is a URI) whenever you passed it to the protocol machinery that were going to retrieve a resource or take some other action over the network. For something that is already a URI, this is a null transform. For everything else, there's a set of steps in 3987, which includes ToASCII for ireg-name components which are domain names. I would personally not suggest using IRIs here, given that the scheme (https) is expected to retrieve a resource at a well-known location and thus will always have to be mapped to a URI to do the retrieval (rather than used in a string comparison or something similar) . RFC 5280, which this cites, actually goes through the steps pretty well, and I think the complexity there demonstrates the advantage for constrained devices of always using the URI form. Just a personal opinion, obviously, and I also would not class myself as an expert here. Ted > I can easily make this "authority" and RFC3986. > Please advise. > > Some background: this text is slightly new, and is the result of interop > failures. I had placed "https://example.com/"; in the certificate, while > another implementer placed "example.com:9443/.well-known/est" in, > assuming that > "https:" was naturally implied. > > So, we disagreed what the base was, and we then agreed that there were > sometimes reasons to include the the entire URL, but that less is better. > We then looked for what the term for the "hostname:port" part was, and > found 3986 and 3987. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | IoT > architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > > > > > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
