On Tue, Jan 19, 2016 at 2:47 AM, Joe Hildebrand <hildjj(_at_)cursive(_dot_)net>
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(_at_)netapp(_dot_)com>
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(_at_)example(_dot_)com 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(_at_)cisco(_dot_)com> 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.