Phillip One of the points you make below is that the supervision of a registry should be determined by its place in the protocol stack, higher means less. I think that the syntax of an entry should also play its part. When the entry is numeric (e.g.port) then the syntax is fairly well defined and the scope for inappropriate or mischievous entries is limited. When the entry is textual, even if the character set is limited to US-ASCII, then that scope is considerable so I would argue that any such registry should have someone keeping an eye on it, to query, perhaps reject, proposed entries that might be intended to subvert, to malign, to breach IPR and so on. I would argue this as the starting point for all registries where the entry is textual and otherwise unconstrained. Tom Petch ----- Original Message ----- From: "Phillip Hallam-Baker" <phill@xxxxxxxxxxxxxxx> To: "IETF Discussion Mailing List" <ietf@xxxxxxxx> Sent: Monday, January 18, 2016 10:07 PM > Protocol registries play an important part in the Internet. If two > parties attempt to use the same code point to represent different > concepts, the protocol may break. Or worse, may appear to have > succeeded when it has actually broken. Contrawise, if two parties are > both capable of understanding a particular concept but have different > name for them, they can't interact even though they have all the code > they need. > > While all protocol registries have the function of providing on > ontology [1] of unambiguous common terms. Some registries have other > functions. These may include preserving a small number of scarce code > points and 'protecting the Internet'. > > The management of protocol registries are something that the entire > IETF community has a stake in, not necessarily just the Working Group > that originally developed. > > Registrations that require a published specification or expert review > or an RFC certainly provide benefits in certain situations. But there > are definitely costs. On past occasions my requests for code point > assignment have in some cases taken more than a year and required me > to do quite a bit of work managing the application. And every process > that requires a published specification prevents that mechanism being > used for proprietary protocols. > > [As an aside here, I will point out that even if you think every > Internet protocol should be open as a matter of course, there are > often very good reasons to avoid premature publication. Even if the > ultimate objective is an Open Standard, the initial draft is likely to > be a proprietary proof of concept.] > > It it my position that the degree of review required for an assignment > is something that should flow from the Internet architecture and in > particular the ideas behind the End-To-End principle rather than the > opinions of the people who happen to have worked on a particular > platform. When I write a Web Service with a HTTP binding, I am using > HTTP as a platform, that does not give the HTTP WG the right to look > over my shoulder and second guess any more than the TCP designers > would if I was using raw TCP. > > Rather than being an argument as to where certain functions should > occur, the End-to-End paper actually discusses the consequences of two > approaches to managing complexity. If you are designing a network that > has a single purpose that is fixed for all time, then putting the > complexity in the center of the network allows a lot of opportunity to > optimize for that application. The client end points can then be made > very simple. If however, you want a network that is not limited to > just one function and is capable of adapting to many different > functions then it is best to make the network as simple as possible > and keep the complexity at the endpoints. > > So one consequence of the end to end principle, which I fully endorse > is that there are legitimate reasons to have a high barrier for code > point assignments at the lower layers of the stack regardless of > whether the number of code points is limited or not. In particular, > proposals for a new version of Internet Protocol need to be considered > with very great care because they have the potential to add complexity > to the network core. Proposals for new transport or routing protocols > likewise demand scrutiny. > > At the application end of the stack, the reverse principle should > apply, not as a consequence of the End to End principle but as a > direct consequence of the goals that the end to end principle was > meant to serve. The whole point of the Internet was to set people free > to develop new ways of using networks, to explore new ideas, and most > important of all, to have the possibility of failure. Because if you > don't ever permit something that might fail, you will never permit > anything that might be important. > > Regardless of whether you agree or disagree with my particular > argument, I think that it is clear that this is a matter that the IETF > as a whole should decide not merely the platform provider. > > In recognition of these principles, the IETF decided to change the > designation of the Well Known Ports registry to First Come First > Served some time ago. I believe that the same designation should apply > to every application level registry unless there is a very specific > and fully documented reason not to. > > In 24 years of participation in IETF, I have frequently encountered > cases in which people have raised intestinal arguments as to why > something should not happen. In each and every one of those cases the > 'gut feeling' they claim has turned out to be completely and utterly > wrong. > > At present we have a registry that is critical to Web Services which > is 'specification required'. I would like to have this changed for the > reasons stated above and because the registry is functionally > redundant. > > In the original Internet architecture, The DNS was used to identify > the address of a host and the TCP or UDP port number was used to > identify the application protocol a client was requesting the host > participate in. > > RFC 2052 (1996) introduced the SRV record which provides a mechanism > for locating Internet services. Instead of using port numbers to > identify the protocol to be used, the protocol name from the Well > Known Services registry is used instead. This has a number of > important advantages, not least being port conservation. It is no > longer necessary to issue a new port number for every new protocol. > But equally important for my purposes, the SRV record provides the > fault tolerance and load balancing capabilities of the MX record. > > Had the SRV record been defined in 1992, we would have used it for > HTTP. In fact something of the sort was developed at NCSA with their > round robin DNS record hack out of extreme need. Now that we are doing > Web Services, the use of an SRV like record has obvious benefits over > A/AAAA. > > Note that a Web Service is merely a protocol that happens to use HTTP > as transport. Some Web Services are limited to information retrieval > but many are not. In particular, the Web Services I design are > typically using multiple layers of encryption/authentication, they are > not idempotent, they have side effects such as causing robots to move > or data to be published. > > There are two major advantages to using HTTP as the transport, one is > that the HTTP ports are most likely to be open at the firewall level. > Another is that there is an infrastructure for managing multiple HTTP > services on a single machine on the commonly used platforms. So for > example, in the .NET,and .NETCore frameworks, a program can register > to receive and respond to requests sent to a particular http:// prefix > in the same way as they might register to service a TCP port. Apache, > nginix, IIS provide similar capabilities. > > When using SRV discovery to locate a HTTP Web Service, a problem > arises. How does the client identify the Web Service Endpoint on the > destination host? > > Patrik Falstrom proposed the URI record a while back as one way to do > this. This record specified a URI rather than a domain name and port. > But it turns out that most hosting providers now know to support SRV > but few support URI. Also any attempt to use a DNS discovery mechanism > in the real world has to include some mechanism that falls back to > only using A/AAAA and CNAME lookups or access will be blocked in a > non-negligible number of network locations. > > RFC5785 specifies a registry for prefixes in the /.well-known/ space > of a HTTP server. > > So for example, I have registered mmm as the SRV prefix for the > Mathematical Mesh portal protocol. This is used to resolve > transactions that are bound to an account identifier in RFC822 style > format. e.g. alice@xxxxxxxxxxx. > > A service provider might advertise service on host1 and host2 with DNS > entries as follows: > > _mmm._tcp.example.com SRV 0 20 80 host1.example.com > _mmm._tcp.example.com SRV 0 80 80 host2.example.com > mmm.example.com CNAME host1.example.com > > It is natural for the client resolving alice@xxxxxxxxxxx to use the > following Web Service Endpoints: > > http://host1.example.com/.well-known/mmm/ > http://host2.example.com/.well-known/mmm/ > > In effect we are providing the SRV prefix to the HTTP server using the > URI request line in the same way that we use the Host: header to tell > the server which service is being accessed (example.com in either case > as following the prcedent set for CNAME lookup. we give the original > DNS query name, not the internal DNS translations). > > Now people may or may not like this particular proposal. Heck, I might > not even like it after I have used it for a while. But it is certainly > based on the Internet architecture to the extent any of it has been > written down. It is consistent with current practice and with the > requirements of the RFCs I have read. Nobody who has objected to this > approach has ever given me a technical argument as to why it is wrong. > > My problem is that while the SRV registry is first come, the > .well-known registry is 'specification required'. This creates two > problems: > > 1) It is quite possible that following current registration practices, > someone else might apply for mmm and the registration would be > granted. And then my only recourse might be a lawsuit. > > 2) I may not be able to provide the specification, either because the > protocol is experimental or proprietary. > > Having the name of the protocol be different in the DNS and HTTP > spaces is utterly unacceptable to me. Equally unacceptable is that > someone else might register the name of my Web Service. This is not a > constrained name space, the only reason for doing it deliberately > would be spite. > > Once it is recognized that both registries serve the same purpose, > namely to identify protocols to prevent collisions, it is obvious both > should have the same registration criteria. If as some people have > asserted, their are mysteries of the HTTP protocol that require expert > attention, these are not known to me as one of the original > contributors to that protocol and incidentally the first person to > write a working Web Service since the POST method was utterly broken > until I fixed it. But even if such issues did exist, the remedy should > be to fix HTTP rather than throw up obstacles for people trying to be > polite when they are using it. > > At the end of the day, requesting IANA registrations is a matter of > politeness and nothing more. The people that the net does need > protecting from don't know to ask or they know to ask but don't > bother. > > Like the original Internet architects, I believe in as much > experimentation at the application layer as possible. Otherwise, I > would not have spent the past 3 years building an infrastructure > designed to make cryptography easy for everyone to use. Contrary to my > critics in governments, I am not oblivious to the consequences of my > work. > > If however, people think that the registry should remain as it is, > then there is going to have to be further action by IETF to ensure > that the process does meet the requirements of being open. > > Specifically RFC 5226 specifies an appeals process but does not state > that there is a requirement to tell parties accepting a registration > that they have a right to make an appeal or under what circumstances. > In particular, what happens when the DE does not respond in a timely > manner? What happens if they acknowledge the request but neither > accept or reject it. My biggest delays have come from the case where > the request has been accepted by the DE but the DE has failed to > assign the actual code point in a timely manner. > > PHB > > [1] Here I am using the term 'ontology' in the AI sense of a 'shared > vocabulary' and not as a system of being which is the definition in > philosophy.