On Tue, Jan 19, 2016 at 2:47 AM, Joe Hildebrand <hildjj@xxxxxxxxxxx> wrote: > One approach would be to register "/.well-known/_srv/" using a specification, then >have that spec allow anyone with an SRV registration to use (for example) >"/.well-known/_srv/_tcp/_mmm" without further registration. Note: this is just >a strawman syntax; there's a nice bikeshed available about how many >underscores to use. Well I like that better than phb_protocol that someone suggested. Tying this back to SRV makes sense. The _tcp part is unnecessary though since this is always going to be over http. On the underscores thing, I think there is a very good argument for dispensing with them when used outside DNS. The folk with GUI type interfaces to SRV records put them in automatically. Particularly if people are serious about the use of the service identifier in URIs. On Tue, Jan 19, 2016 at 3:32 AM, Eggert, Lars <lars@xxxxxxxxxx> wrote: > To cater to their needs without assigning more ports for HTTP, I floated a >slightly different proposal with a few people, namely, to extend the "port" >component in the URL scheme and allow a service name there. The browser >could then look that up against the given host with DNS-SD and connect on the >returned port. > > scheme:[//[user:password@]host[:port]][/]path[?query][#fragment] I am not opposed in principle and would have enthusiastically supported it as an option before we built out legacy infrastructure. The key issue would be whether the legacy infrastructure is going to do unfortunate things. This proposal doesn't address my problem however which as with Jabber is how to get from alice@xxxxxxxxxxx to a Web Service endpoint. All that I am proposing here is a convention from getting from the DNS address and SRV record to a Web Service Endpoint on the http host. There is nothing stopping someone using the same URL space for a different purpose on their server. The only time that becomes a problem is when they cut an SRV record pointing to their host that is doing something else. On Tue, Jan 19, 2016 at 3:46 AM, Eliot Lear <lear@xxxxxxxxx> wrote: > I also agree with Phill on one other point: it seems perfectly > reasonable that should a request for an assignment be denied, the IANA > should as a matter of course refer the applicant to RFC 5226 regarding > the right of appeal. That process is there to allow for oversight of > the designated technical expert and not to test the ability of an > applicant to find the right RFC. This has to happen when the initial application is made. I have never had a problem with a registration being refused. The process problems occur when either the expert hasn't been appointed or the registry is being transitioned from WG to IANA control or the expert never replies. IETF process rarely fails by making the wrong decision. It fails by failing to make a decision at all. Advising people that they have rights is also important for the case where the expert review is used as an opportunity for the DE to bikeshed the specification. Yes you may be a fan of Star Trek TNG but I do not want my bikeshed repainted in LCARS style.