I was going to let this lie like Stephen suggested. But I think we might actually have a basis for agreement here. Reading your response here, it is clear that you misunderstand what the implications of merging the registries is. No, there was no proposal to require every protocol that uses .well-known to make use of SRV signaling or vice versa. There is in fact no separate registry for SRV. When a protocol uses SRV signaling it uses a code point from the registry whose full name is "Service Name and Transport Protocol Port Number Registry". But only a minority of protocols make use of SRV signaling. There is an entry for 'DNS' in that registry for a start. While SRV discovery of DNS resolvers might well make sense to some people, it is not something to be attempted without an RFC covering that exact usage. All that the use of the "Service Name and Transport Protocol Port Number Registry" for SRV means is that IF the protocol uses SRV THEN those are the identifiers to be used. And that is all I have proposed for .well-known so far. Nor is that use of the registry limited to SRV. People have been looking at using the same identifiers for a variation on DANE and other proposals for making use of DNSSEC for security policy. Whether you want to make use of _dnt._tcp SRV records in your protocol or not, you probably don't want someone else registering that identifier in the "Service Name and Transport Protocol Port Number Registry" for a completely different purpose. Even if you don't want any of the current mechanisms based on putting a service prefix in the DNS, how can you be so certain that there is no possibility of such a need? This is a registry that effectively has two parts. There are registrations for assigned ports which do have some oversight or there are pure service name allocations for use with SRV, URI, DANE, etc. that do not deplete a finite resource and are issued on a First Come First Served basis. All we are talking about here is defining a mechanism that preserves all the information from the use of SRV for discovery. We could capture the same information with a header like we did with the Host: header. But that is a deprecated hack anyway. The proper place for that information is in the request URI. The only objection I have to using /.well-known/srv/ as the prefix is that will turn the 24 existing registrations into special cases which will inevitably end up as corner cases that future specifications have to work around. In general, once a name is registered in the "Service Name and Transport Protocol Port Number Registry" it really should not appear in any other registry unless it has the same meaning. That does not mean that reserving xxx in the protocol registry means that a URI scheme for xxx: or urn:xxx: will be created. But anyone wanting the same identifier for something else probably should be refused. It seems to me that folding the .well-known registry into the "Service Name and Transport Protocol Port Number Registry" is the best course of action. But that course of action would clearly be inappropriate if there was an actual justification for 'specification required'. It also seems to me that in conceding /.well-known/srv/ mirroring the SNTPPNR you are effectively conceding the point that there is no reason not to make the registry first come first served. So it really comes down to whether we want to introduce yet another noise prefix or dare to do without. On Wed, Jan 20, 2016 at 11:03 PM, Roy T. Fielding <fielding@xxxxxxxx> wrote: >> On Jan 20, 2016, at 6:04 PM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >> >> On Wed, Jan 20, 2016 at 7:32 PM, Mark Nottingham <mnot@xxxxxxxx> wrote: >>> On 21 Jan 2016, at 12:47 am, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >>>> >>>> The reason I picked on 5785 is that it was the one that the DE refused to give any explanation of the need for when I asked in private. >>> >>> Since you bring it up - >>> >>> You sent me one brief e-mail making a couple of suggestions about how the registry process could be changed, motivating them with your "mmm" proposal. >>> >>> I responded affirmatively to an observation you made, and to the suggestions noted: >>> >>> """ >>> The relationship with that registry was discussed in LC, and we explicitly decided NOT to tie them together, IIRC. >>> """ >> >> That was why I re-raised the issue on apps-discuss. You didn't seem >> interested in giving an explanation of the need for the registry then >> either. Instead you stated that a decision had been reached as if that >> was the end of the matter. >> >> I do not expect you to provide statistics as DE. However when you make >> a series of assertions about the need for the registry characterizing >> it as essential to protect the integrity of the Internet, I do expect >> that you would justify such a surprising claim with instances where >> you believe that to have been the case. >> >> You have repeatedly asked me to provide technical details and then >> completely ignored the explanations I have given. >> >> >> Finally, what you took as being 'bad behavior' on my part was when I >> pointed out that I knew that you were the DE rather than another >> individual. Which I did at the request of an AD who thought that it >> appeared that I was suggesting the registry be merged on account of >> his behavior. >> >> From the start you appear to have been attempting to find an excuse to >> refuse to engage with the substance of my proposal questioning the >> form, the technology and finally after one of your allies makes two >> very personal ad hominem attacks, calling my proposal 'mindbogglingly >> stupid' and then calling me a liar you are attempting to call an end >> to the discussion by alleging bad behavior on my part. > > The apps-discuss discussion of which you speak is entirely archived > and available for anyone to review: > > https://mailarchive.ietf.org/arch/search/?email_list=apps-discuss&gbt=1&index=P2fsI3FuxG1-GoRyxKnHR7o9zic > > The only person who ever used the word "stupid" is you. What I did write in > > https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJP86U > > is "brain-numbingly poor use of those protocols", which has an entirely > different meaning than the one you represent here. It isn't a personal > attack (nor is it ad hominem, which means the same thing). After repeated > misrepresentation of what I wrote, IN QUOTES, I sent the following message > > https://mailarchive.ietf.org/arch/msg/apps-discuss/f2D7iH0Gdv4Ay4VSd2WgtaOpLP8 > > to which you responded with more misrepresentation. And above you have > chosen to quote the phrase 'mindbogglingly stupid', with indirect attribution > to me, which cannot be found in any of my correspondence because > I DID NOT WRITE IT! > > Regardless, all of that was on apps-discuss. None of it is a registration > request for the .well-known registry, nor is it reasonable to expect a DE > to respond to private email discussion as if it is a registration request. > > Actual registration requests go to the wellknown-uri-review mailing list: > > https://mailarchive.ietf.org/arch/search/?email_list=wellknown-uri-review > > where anyone can see several instances of the registry working quite fine, > as defined by the RFC, with fairly quick responses regardless of any > disagreements. FWIW, Mark does a good job even when I disagree with a > particular use of .well-known. > >> For the record, I have yet to hear one argument from you, or for that >> matter anyone else as to why two separate registries are needed at >> all. > > The simplest argument is because most of the existing wk registry entries > are not services and don't want to be listed as SRV names. I certainly > don't want the name "dnt" to be associated (in any way) with SRV. > It should be clear that most of the others wouldn't fit either. > > http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml > > The purpose of the registry is defined here: > > http://tools.ietf.org/html/rfc5785#section-1.1 > > and it makes no mention of the use of .well-known for service redirection. > Nor should it. > > However, I personally have no objection to registering something like > /.well-known/srv/ as a namespace under which you can FCFS whatever names > you might like (or automatically adopt SRV names), unencumbered by a DE, > and that would accomplish the exact same purpose. Mark made a similar > suggestion in his first response to you. All you need to do is write a > spec that defines the purpose for which the namespace has been allocated. > > ....Roy >