Subject: On IETF policy for protocol registries

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Jan 2016 17:07:51 -0500

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. [email-masked].

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 [email-masked] 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.

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 19 Jan 2016 08:47:02 +0100

> On Jan 18, 2016, at 11:07 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

> protocol is experimental or proprietary.

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.

-- 
Joe Hildebrand

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 19 Jan 2016 08:32:26 +0000

Hi,

> DNS query name, not the internal DNS translations).

as a reviewer for the ports registry, we frequently see requests for port assignments for services over HTTP/HTTPS where the applicant states that port 80/443/8080/etc. are already "taken". So they want to be able to use URLs with a fixed port other than those.

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 don't feel strongly about this variant either. I would love to see some scheme that would allow folks to run HTTP services on arbitrary dynamic ports without burning more port numbers. Happy to help write something up.

Lars

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Jan 2016 09:46:56 +0100

Hi,

> as a reviewer for the ports registry, we frequently see requests for port assignments for services over HTTP/HTTPS where the applicant states that port 80/443/8080/etc. are already "taken". So they…

As another reviewer of that registry, I concur that this is a problem.
> I don't feel strongly about this variant either. I would love to see some scheme that would allow folks to run HTTP services on arbitrary dynamic ports without burning more port numbers. Happy to h…

I would prefer not to modify scheme names.  It seems that .well-known is
well suited for this sort of approach.  I like Joe's suggestion, but
would go further and suggest (as I have done on apps-discuss) that
"specification required" is indeed too high of a bar, because there are
such things as proprietary approaches that we as port reviewers cater
to, and this .well-known registry is far less constrained.

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.

Eliot

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 19 Jan 2016 19:24:10 +1000

On 19/01/2016 6:35 PM, "Eggert, Lars" <[email-masked]> wrote:
>
> as a reviewer for the ports registry, we frequently see requests for port
assignments for services over HTTP/HTTPS where the applicant states that
port 80/443/8080/etc. are already "taken". So they want to be able to use
URLs with a fixed port other than those.
>
> 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.
> I don't feel strongly about this variant either. I would love to see some
scheme that would allow folks to run HTTP services on arbitrary dynamic
ports without burning more port numbers. Happy to help write something up.
> Lars

I'm feeling a little doughy after a long day of staring at logs. Is this
idea to allow folk to mint a URL like "http://example.com:foo/" and have
the UA use example.com's DNS to look up what port 'foo' is?

Presumably because example.com is running a server on some random port,
which speaks a particular protocol-over-HTTP. Other folk might know that
the protocol-over-HTTP is 'foo', but not know what random port it's served
over on this machine at this time.

I like the idea of avoiding a query to a mundane (non-foo-speaking) web
server whose whole purpose is just to tell you where to go to speak 'foo',
or even the need to have such a thing. Can DNS-SD tell you what path to
query (along with server and port), in case the foo-speaking part of the
server is nested within the regular port-80 web server?

I also like that it means you don't have to split up your 'foo' (most of it
served on port :foo, but some running on port :80 under /.well-known/)

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 19 Jan 2016 11:03:14 +0000

On 2016-01-19, at 10:24, Matthew Kerwin <[email-masked]> wrote:
> I'm feeling a little doughy after a long day of staring at logs. Is this idea to allow folk to mint a URL like "http://example.com:foo/" and have the UA use example.com's DNS to look up what port 'foo' is?

Yes.

> Presumably because example.com is running a server on some random port, which speaks a particular protocol-over-HTTP. Other folk might know that the protocol-over-HTTP is 'foo', but not know what random port it's served over on this machine at this time.

Correct. And service names are assigned FCFS, since there are many more than port numbers.

> I like the idea of avoiding a query to a mundane (non-foo-speaking) web server whose whole purpose is just to tell you where to go to speak 'foo', or even the need to have such a thing.

That is exactly the downside I see with the .well-known approach.

> Can DNS-SD tell you what path to query (along with server and port), in case the foo-speaking part of the server is nested within the regular port-80 web server?

I'm not sure. But would you even need that? You can just make foo resolve to 80.

> I also like that it means you don't have to split up your 'foo' (most of it served on port :foo, but some running on port :80 under /.well-known/)

Yep.

Lars

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 08:47:41 -0500

On Tue, Jan 19, 2016 at 2:47 AM, Joe Hildebrand <[email-masked]> 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 <[email-masked]> 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.
>

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 [email-masked] 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.

> 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.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 19 Jan 2016 14:48:46 +0100

On 2016-01-18 23:07, Phillip Hallam-Baker wrote:
> ...
> ...

How does "First-Come-First-Serve" make that better? Doesn't it even make 
it worse?

> ...

"Experimental", as far as I understand, isn't a problem per se.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 08:57:08 -0500

On Tue, Jan 19, 2016 at 8:48 AM, Julian Reschke <[email-masked]> wrote:
> How does "First-Come-First-Serve" make that better? Doesn't it even make it
> worse?

My proposal was to abolish the .well-known registry altogether and use
the Well Known Ports and Services registry for both. So my
registration of MMM in one, automatically registers mmm in the other.

This is incidentally how the SRV registry went away. There were drafts
circulating proposing a registry for years. I think there was even a
registry created at one point. But people thought
about the problem and realized that the best and simplest approach is
to have one registry.

There are only 24 .well-known registrations today. Merging the
registries would not be difficult.
Just create Well Known Port & Service entries for the few code points
that don't have one already.

But even if that doesn't happen, it is fairly easy to make requests
for both registries simultaneously if they are FCFS.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 09:06:03 -0500

> "Experimental", as far as I understand, isn't a problem per se.

Sorry, hit return too soon. Have undone all the effect of merging my
earlier responses.

The reason I might not want to publish an experimental spec is to
avoid it becoming a competitor to a standard we intend to create later
on.

For example, right now in the lab I have a dalek we are fitting with a
drive system, motorizing the dome, manipulator arm, gun etc. The
current design has message level authentication and encryption. The
point being to demonstrate that applying crypto at the lowest levels
of circuit design is practical. I am planning to share that code in
the dalek building community and with other builders of similar
robots. But the protocols themselves are very specific. I would not
want to propose them as the basis for a standard, any standard would
be built on what we learned.

Point is that I don't want my standards proposals competing with my
experiments. We had that with HTTP/0.9 which was a pain in the
patootie for over a decade despite the fact it was only active for
less than a year.

---

From: tom p. <[email-masked]>
Date: Tue, 19 Jan 2016 17:45:24 +0000

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 14:02:42 -0500

> all registries where the entry is textual and otherwise unconstrained.

That is a good point. And a corner case that we don't seem to have
faced to date. Though I can imagine we might end up doing so in the
future.

I think that the issue certainly merits a treatment in any new rules
for registries but I don't think the answer is prior restraint. Rather
the approach that we have generally encouraged on the Web and managed
to get most jurisdictions to recognize is one where anyone can publish
anything but they may suffer consequences for doing so and ISPs are
required to take down material after being advised it is
objectionable.

Applying this principle to IETF process, anyone can register anything
in a first come first served registry but there would obviously be
legal issues if someone other than Twitter registered TWITTER as a
well known service with the objective of sabotaging deployment of a
planned product.

Rather than attempting to anticipate such issues, it is probably best
to simply note that assignments can be revoked by IESG decision.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Jan 2016 08:29:38 +1300

On 19/01/2016 21:46, Eliot Lear wrote:
...
> applicant to find the right RFC.

Emphatically +1.

Also, any expert review that takes longer than, say, one month should
be red-flagged in some way. RFC 5226 talks about "a few weeks" and
"a reasonable period of time" but doesn't really have teeth, so
it's unclear how long is too long and when a delay is itself a valid
groaund for appeal.

It's late in the day, but I think draft-leiba-cotton-iana-5226bis
should fix that. Like:

OLD:
   Appeals of protocol parameter registration decisions can be made
   using the normal IETF appeals process...

NEW:
   Appeals against protocol parameter registration decisions and
   unreasonable delays in such decisions can be made using the normal
   IETF appeals process...

 Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 14:55:49 -0500

+1 and I would like the process document to require that the
registrant is advised of this right.

The delays I have incurred in getting code points assigned have not
been due to issues with the request. They have been caused by the DE
not responding. Or responding that they plan to get to the request. Or
approving the request and then not acting on it. Then when reminded,
starting the whole thing again.

Having specific deadlines is probably a good way of persuading people
who have taken on rather too many responsibilities that being the DE
on a registry should not be one of them or if it is that it needs the
same attention as the ones that do come with tight deadlines.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Jan 2016 19:17:05 -0500

>    unreasonable delays in such decisions can be made using the normal

It's not that late in the day, because the document will have to go
out for last call again, once that laggard of an editor has taken care
of the needed updates.  As I happen to know said editor very well, I
can tell you that he agrees with you and plans to incorporate your
suggestion.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Jan 2016 19:21:35 -0500

> same attention as the ones that do come with tight deadlines.

Indeed, though we do need to remember that we're all volunteers here,
and we do what we can.  Delays on handling some things (let's say, the
final editing of 5226bis, for example) shouldn't directly be grounds
for action.  Consistent patterns of delays, or delays that appear to
be targeted and/or purposeful, should definitely be brought to an AD's
attention for investigation and appropriate action.

Barry

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 16:51:10 -0800

On 1/19/2016 11:29 AM, Brian E Carpenter wrote:
> ground for appeal.

Note that many expert reviews take a long time because of the delays
caused by applicants responding to review queries, not simply the delay
in the expert review side of the process.

When we've had very long delays, it's often because we took many cycles
to explain how port assignment worked. We can certainly shorten review
times by reducing that community service, but I would hesitate to
recommend that approach.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 16:51:16 -0800

On 1/19/2016 12:32 AM, Eggert, Lars wrote:
> as a reviewer for the ports registry, we frequently see requests for
> port assignments for services over HTTP/HTTPS where the applicant states
> that port 80/443/8080/etc. are already "taken". So they want to be able
> to use URLs with a fixed port other than those.

Some context on these requests:

They typically fall into two categories:

1) I want to run a configuration system, monitoring system, etc. using
existing web interfaces

2) I have a completely custom protocol that happens to be encoded over
HTTP/HTTPS

#2 is no different than X over SOAP, etc. That's just another encoding,
and is a separate service.

#1 is the difficulty. It becomes nearly impossible to determine how this
is a distinct "service" from ports 80/443. However, there is a
legitimate need to run multiple "services" over an encoding.

There are two ways to handle this case:

	- build the differentiator into HTTP
		as Lars suggested using a new URL extension
		(which would work only for HTTP sharing)

	- build the differentiator into TCP
		see draft-touch-tcpm-sno
		which would work for any X over Y service

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 16:58:30 -0800

>    unreasonable delays in such decisions can be made using the normal

That won't work without defining "unreasonable".

Additionally, time of year matters, e.g.:

	- the US often goes on a 2-week hiatus at the end of the year

	- the EU often goes on a 4+ week hiatus in late summer

So as long as we accept that some regions have people that will be
inaccessible for several weeks in a row, it's not reasonable to expect
that reviews will happen on a 1-week turnaround 365 days a year.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 17:02:30 -0800

> faced to date. Though I can imagine we might end up doing so in the

We actually do review SRV requests for exactly this sort of thing and
recommend alternatives to the applicant (which they typically either
accept or suggest their own alternatives), although I don't know what
would happen if the applicant insisted otherwise.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 20:47:33 -0500

> would happen if the applicant insisted otherwise.

At the end of the day, if it is a protocol code point, all that should
matter to the protocol is uniqueness rather than the value itself.
Unless of course the protocol is already in use or whatever.

Having been in one or two registry businesses, (PKI, VeriSign), I tend
to think of preventing people registering 'bad names' as an
aspirational goal.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Jan 2016 20:49:50 -0500

> That won't work without defining "unreasonable".

I think it will, because I think that in most cases the registrants
and the DEs and/or IANA do engage in reasonable consideration of
delays, but that once we get to a point where the DEs and the
registrant are sufficiently at odds that the registrant feels the DEs
are being unreasonable, by whatever definition, and explanations
aren't being accepted, it's time to get an AD involved and to let the
DEs get back to the other work they're doing.  We'll never be able to
define "unreasonable", but we will know such a situation when we see
it.

In any case, I think I would change it to this:

NEWNEW
   Appeals against protocol parameter registration decisions and
   unreasonable delays in such decisions can be made using the normal
   IETF dispute resolution process, including escalation to an appropriate
   Area Director, and possible a formal appeal...

(...keeping in mind that 2026 specifies that formal appeals start with
the full IESG, but that one should start by dealing with the
responsible AD first.)

Barry

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 19 Jan 2016 20:54:19 -0500

> attention for investigation and appropriate action.

I don't think deliberate problems are the issue, the problem I see is people
taking on more work than they can do.

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 18:12:33 -0800

> Unless of course the protocol is already in use or whatever.

That's true, but there are other considerations that applicants don't
always take into account - e.g., clarity, potential for confusion, etc.

> to think of preventing people registering 'bad names' as an

I don't recall "bad" names coming up, FWIW. More like "names that could
be better".

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 18:17:01 -0800

On 1/19/2016 5:49 PM, Barry Leiba wrote:
> DEs get back to the other work they're doing.

FWIW, we already do that. That doesn't necessarily need an escape
clause, especially one that escalates it to a formal "appeal".

> We'll never be able to

Everyone who writes rules always thinks this is the case, but it really
isn't - but, regardless, what's the benefit? Applicants already can
escalate things to the level of appeal basically any time they want anyway.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jan 2016 18:29:53 -0800

On 1/19/2016 5:54 PM, Phillip Hallam-Baker wrote:
> taking on more work than they can do

FWIW, this whole process is managed manually right now. It's quite easy
to lose track of things in that process.

We process quite a few requests. For example, according to my logs,
we've been averaging about 130 requests/year, and each requests averages
around 8 emails, or about 20 messages a week - as a team.

I monitor all of these, as well as participating in 1/Nth of the reviews
and as backup on late reviews. My turnaround is approximately 1 business
day, excepting vacations (about 1 week most of the time).

Yes, we do have occasional delays, but they're as often on the applicant
side as the reviewer. A lot of our delays are the result of incomplete
or incomprehensible applications, FWIW.

Overall, I think our team has been doing a pretty good job, though. Yes,
there are some corner cases - and those are the ones you all hear about
more, but I don't think it's a significant enough fraction of the
overall workload to warrant over-managing with mechanism to address
these rare exceptions.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jan 2016 08:22:59 +0100

Hi Phill,

On 1/20/16 2:54 AM, Phillip Hallam-Baker wrote:
> I don't think deliberate problems are the issue, the problem I see is
> people taking on more work than they can do. 

While I'm sure it's different for different people, when I'm late it's
almost certainly because I am in fact overloaded.  This is a balance:
one must give deference to the reviewers or one won't have reviewers. 
And of course it should be a consideration for both working groups and
the IESG as they create and manage registries.  I know of registries out
there where we would be very hard pressed to find a replacement.  To me,
THAT is a strategic issue that the IAB and IESG should consider taking
on.  Back in the IANAPLAN working group, one person suggested to me that
the protocol parameters registry should be a wiki that could be edited. 
I don't know if I would go that far, especially when it comes to certain
registries like IP version numbers, but let's acknowledge that expert
review requires resources that the IETF does itself not control.

This having been said, I don't know that this is a serious problem with
the 5785 registry, nor do I believe we should make changes based on a
single request/response.  My experience is that there is no perfect
policy; and actually I appreciate that Mark and company are willing to
donate their time to the cause.

Eliot

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 20 Jan 2016 18:45:29 +1000

On 19/01/2016 9:04 PM, "Eggert, Lars" <[email-masked]> wrote:
> > Can DNS-SD tell you what path to query (along with server and port), in
case the foo-speaking part of the server is nested within the regular
port-80 web server?
> I'm not sure. But would you even need that? You can just make foo resolve
to 80.

Because I might have strong reasons to make my service available under
http://example.net/foo/ ... so I'd need a well known location that links to
the relevant entry points under "/foo" -- be that special headers or markup
in "/", or something in "/.well-known/", or something else.

At which point I'd have to ask, why not just use .well-known in the first
place?

I'm assuming that either: the person minting the URL doesn't know my server
setup (otherwise they could include the full path *and* the numerical port
from the start, and skip the whole dance); or this is for resolving non-URL
identifiers (like "foo:[email-masked]")

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2016 08:47:06 -0500

> one must give deference to the reviewers or one won't have reviewers.

Or one has to seriously consider why it is necessary to have reviewers
at all and only introduce gatekeepers when they are absolutely
necessary.

> there where we would be very hard pressed to find a replacement.

And at the lower end of the stack, that is almost certainly because
the code points are scarce and the impact on the Internet core is
large.

> To me,

One thing that does worry me is that these are control points and
anyone guarding a control point is liable to be a target for the
governments who want control. Crypto algorithm registries are really
problematic in that regard.

> donate their time to the cause.

I didn't choose the 5785 registry as the starting point because there
was a specific problem. I think the issue that needs to be addressed
is at the meta level. However, having meta discussions without a
specific course of action is not usually very useful in IETF.

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. Then
when I raised it on the apps-area list my proposal was attacked by
another individual as 'mindbogglingly stupid' and called a liar. If
nothing else, there is very clearly evidence that any consensus that
may be claimed is the result of bullying and intimidation rather than
actual technical arguments. Most people seem to give up when faced
with that type of tactics. Which is of course the reason why they have
to end.

No, I do not think the fact that someone is a 'volunteer' is an excuse
for that type of behavior.

Having been involved in the creation of a few registries, I think that
the designation of the registry should be determined by the Internet
architecture rather than the personal taste of the people who wrote
the specs.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2016 09:06:42 -0500

> identifiers (like "foo:[email-masked]")

This is indeed about resolving such identifiers. And also about being
able to use identifiers in DNS records and config files without
extraneous syntax. Every bit of syntactic noise that is introduced is
another opportunity to make a config error.

With ids the problem is not just that
http://openid.example.com/ids/alice is simply not going to be
acceptable to 99% of Alices. The other part of the problem is that we
often want to use an account identifier inside another protocol URI.
So lets say I have a FTP url with an account specifier:

ftp://[email-masked]/file/path

That syntax really isn't going to work if you have a URI inside a URI:

ftp://{http://openid.example.com/ids/alice}/file/path

People can make up whatever they like for translating the contents of
{} into a URI safe fashion, I can't see it being viable.

Point is that syntactic clutter tends to accumulate. So being able to
strip everything back to just the domain name and the service
identifier is actually very useful.

One of the biggest hassles I find using SSH is having to type in the
entire key into config files rather than the fingerprint of a key.
Such choices have consequences.

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2016 10:49:52 -0800

> architecture rather than the personal taste of the people who wrote

The specs are the result of either individual contributions or IETF
process. In the former case, who else should be involved? In the latter
case, the entire community is already involved in the review of the
proposed registry management procedures.

This sounds like the result of a problem with a particular registry and
its particular oversight. I don't see a good reason to upend all of
registry processes to address this corner case. That's what we already
have the appeals process for.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jan 2016 08:07:58 +1300

> the full IESG, but that one should start by dealing with the

Yes, that's better than my proposal. And yes, it's OK to use a judgement word
like 'unreasonable' in the description of an appeal process, because any
appeal intrinsically involves an element of judgement.

   Brian

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Wed, 20 Jan 2016 15:27:08 -0500

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> 
> The specs are the result of either individual contributions or IETF process. In
> the former case, who else should be involved? In the latter case, the entire
> community is already involved in the review of the proposed registry
> management procedures.

I don't see it that way.

Part of the problem with IETF process is that every working group tends to be left to choose its own color to paint its bikeshed when many times it would be a lot easier if there was at least some guidance.

The design of the Internet is supposed to be guided by a very specific set of principles, namely simplicity and stability at the core, anarchy and chaos at the edges. If those are what we accept as the principles it follows that we should not get in the way of innovation at the edges without very good reason.

One of those very good reasons right now is the fact that assigned port numbers are a finite and dwindling resource. The point of the proposal to use SRV and .well-known in combination is to provide a direct replacement for an assigned port number that works for a very large fraction of the problem space (most new protocols are built on HTTP even if they don't call themselves Web Services).

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jan 2016 15:46:07 -0500

--On Wednesday, January 20, 2016 08:22 +0100 Eliot Lear
<[email-masked]> wrote:

> This having been said, I don't know that this is a serious
> problem with the 5785 registry, nor do I believe we should
> make changes based on a single request/response.  My
> experience is that there is no perfect policy; and actually I
> appreciate that Mark and company are willing to donate their
> time to the cause.

Agreed.  While I understand and sympathize with the various
grievances, much of this very long thread has seemed to me to be
mostly fairly minor, falling into issues that should either be
taken up with the relevant AD (as Barry suggested) or handled as
appeals if the AD is non-responsive, or as proposed amendments
to 5785, either to change the model or to conclude it wasn't
such a good idea in the first place.  In either of the latter
cases, I would have expected to see an I-D and, if needed, a
request for a separate mailing list long before this.

However, one branch of the conversation, of which the following
seems to be a member, seems to call for comment on the IETF list.

> Because I might have strong reasons to make my service
> available under http://example.net/foo/ ... so I'd need a well
> known location that links to the relevant entry points under
> "/foo" -- be that special headers or markup in "/", or
> something in "/.well-known/", or something else.
> 
> At which point I'd have to ask, why not just use .well-known
> in the first place?
> 
> I'm assuming that either: the person minting the URL doesn't
> know my server setup (otherwise they could include the full
> path *and* the numerical port from the start, and skip the
> whole dance); or this is for resolving non-URL identifiers
> (like "foo:[email-masked]")

The above, and some postings like it, seem to me to raise two
issues that I believe we should be thinking about more broadly:

(1) The Internet has gained a good deal of robustness and,
arguably, much of its worldwide availability and utility, from
its extremely distributed nature.  If I want to do something for
myself or within my family, a small circle of friends, or even
my country, I generally don't need to get the permission of the
IETF or anyone else.  We know there are exceptions that require
some sort of central administration, at least at the top level,
with the root of the DNS and IP addresses being the examples
that are most visible to the broader community but we have
traditionally tried to minimize the number and impact of such
cases. Parts of the community have been pushing the issues of
which this is a part as "permissionless innovation".  

The importance of that robustness and distributed decision model
suggests that we need to be very careful about creating new
mechanisms that, in turn, create a greater requirement for
central administration, regardless of the style of that
administration and who performs it.  Registries for the
convenience of others in avoiding collisions but that do not
create requirements because collisions are unlikely are in a
sort of in-between area.  

In that context, these arguments about ".well-known" or anything
else that requires making global decisions about what does and
does not match the category, with probably high risk of
collisions, especially if the main criteria for wanting to be in
the registry starts with "I want to do..." suggest that the
whole idea may be, on balance, a bad one.  Given the history of
the last 10 or 15 years, it is not hard to imagine demands for
national control over names, requirements that ".well-known" be
defined for a dozen (or many more) languages other than English
(with or without restrictions to Latin script).  From my point
of view, getting into those positions are bad for the Internet
and their tendency to draw in those who main interests lie in
centralized control and policy debates are an unfortunate
symptom, but one could equally argue that the latter are the
problem and the implications for the Internet are just
collateral damage.  Either way, I do not suggest that we should
never have such things (and .well-known in URLs in particular),
only that we should be insisting on a level of justification for
them  --including analysis of whether other, less-centralized,
alternatives are available--  that is strong enough to overcome
the risks and costs.  In the case of RFC 5785, it may be time to
hold that discussion more intensely than was the case when it
was approved (rather than picking at the review and approval
mechanisms).  We might perhaps also wonder why the discussion
about principles didn't occur in more depth earlier and what
might be done to facilitate discussions of that type in the
future.

(2) It seems to me that some of the comments on this thread come
close to demonstrations of the old adage about hammers and
things that look like nails.   While it is clear that
.well-known has good and useful applications, it doesn't seem to
me to be the only way to think about some of the possibilities
that have been mentioned.    Looking at the examples above,
"foo:[email-masked]" could be a perfectly good URL in the foo
scheme.  matty.example.net could point to an DNS record with a
URI RRTYPE.  I don't remember whether urn:foo:[email-masked]
could be valid, but urn:foo:matty.example.net certainly could
be.  And it is likely that other approaches are possible, ones
that do not have the same dependencies and tradeoffs that
.well-known does (even if they have some of their own).  So I
would encourage people to try to be clear about the problems
they are trying to solve and then consider the full range of
options for solving them:  if one option seems problematic,
whether because of the technology or its administration, then
look at, or if necessary invent another one.   And, unless what
you want to invent is something like a new URI scheme bound to
some unique identity of your own, try to avoid arrangements that
require central administration, review, or approval... at least
unless you like discussions like the one we've been having.

  best,
   john

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2016 14:41:45 -0800

On 1/20/2016 12:27 PM, Phillip Hallam-Baker wrote:
> Part of the problem with IETF process is that every working group
> tends to be left to choose its own color to paint its bikeshed when many
> times it would be a lot easier if there was at least some guidance.

Agreed so far...

> The design of the Internet is supposed to be guided by a very 
> specific set of principles, namely simplicity and stability at the
> core, anarchy and chaos at the edges. If those are what we accept as
> the principles it follows that we should not get in the way of
> innovation at the edges without very good reason.

Although those are generally accepted as driving principles, we don't
have anything that forces them either. I.e., for the same reason that
you want flexibility at the edge, others want it in the core.

> One of those very good reasons right now is the fact that assigned
> port numbers are a finite and dwindling resource.

Yes and no. At our current rate of assignment, which has been basically
stable for the past 13 years, we still don't run out for another 80
years (see RFC 6335, Sec. 7).

> The point of the
> proposal to use SRV and .well-known in combination is to provide a
> direct replacement for an assigned port number that works for a very
> large fraction of the problem space (most new protocols are built on
> HTTP even if they don't call themselves Web Services).

There are two types of such services:

- those which are services, i.e., stand-alone, custom protocols

	these already qualify for port assignments and have been
	receiving them as fast as they've been requested; this has
	not appeared to put a new or higher load on port assignment

- those which are not services, but are duplicates of HTTP

	these are the "I really wanted port 80, but it's already
	taken, but I need to run my own web server so users can
	open a browser window to see how to monitor or configure
	my device"

	these have been turned down, but not at any astounding rate.
	They are declined as duplicates of HTTP, the same way that
	requesting your own DNS port or NFS port would be.

What we really need is a way for many interfaces to be able to
"register" with their local web server, to reserve URL prefixes, etc.

This is not at all related to services over HTTP.

Joe

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 Jan 2016 18:05:28 -0500

Joe,

A question just to try to understand your position...

> This is not at all related to services over HTTP.

It sounds to me that what you are looking for would be satisfied
by something resembling 

   http://Domain.example.com<d>service/...
or
   http<d>service://domain.example.com/...

(where <d> is some appropriately-chosen delimiter) as contrasted
with 

   http://domain.example.com:port/

which, by your reasoning as I understand it (and fwiw, by mine)
is basically a bad idea.

If one ignores for the moment the differences in difficulty of
fitting them in as extensions to the URI spec (RFC 3986) the
first two examples are assumed to be semantically equivalent or
what we used to call syntactic sugar.  The definition of
<service> would ultimately depend on the domain, not some
necessary global convention although standardization of names
would help prevent confusion and duplication.  But, in any
event, they would be service names, not different port numbers
for the same protocol.

Is that understanding correct?

     john

---

From: Joe Touch <[email-masked]>
Date: Wed, 20 Jan 2016 15:27:36 -0800

>> "register" with their local web server, to reserve URL

So here's the issue:

	There are two reasons people want to use HTTP:

	1) they want to run a webserver

	2) they want a framing protocol over TCP

#1 occurs because you want to really run a webserver, or because you've
decided that a webserver/client are a quicker way of writing a remote
management console, e.g., for a printer, home router, etc.

#2 occurs because you either want to just use HTTP framing because there
are existing generation and parsing tools, or because you're developing
something called a "web service" - which, IMO, are a lot like
subroutines you can call from HTTP.

---

Requests for assigned ports for #1 are commonly rejected because they
duplicate ports 80/443. It's really one service - generic web server,
which is being used for different purposes.

Requests for assigned ports for #2 are commonly approved because framing
isn't the issue; the issue is whether the service has a distinct
protocol that doesn't replicate an existing service. Consider that both
HTTP and telnet both use ASCII encodings, but HTTP is a different
service because the language is restricted, the semantics are different
etc. That's what's sought by reviewers.

------

That said, I'm not entirely sure what .well-known is needed for. I'm now
beginning to understand it might be for web services, not for duplicate
uses of generic web servers.

>    http<d>service://domain.example.com/...

A little. It's like having a service name that can be parsed or
automatically generated - which is closer to http<d>service, AFAICT.

> which, by your reasoning as I understand it (and fwiw, by mine)

I don't think it's a bad idea. I think allocating a new assigned port
for this purpose is a bad idea. You can run whatever service on whatever
port you want - either by mutual agreement with the other endpoint or as
indexed by mDNS records.

What I don't like is assigning port after port after port for vendors
who want to use web browsers to access their devices configuration and
control interface. Yes, there's a problem if many system entities want
to 'register' web pages for remote access with a single web server, but
that's not a port number problem. That's a web page registration problem.

> event, they would be service names, not different port numbers

Yes, but as I noted, X over HTTP where X is a custom protocol or service
is already eligible for its own port number, and we do that a lot already.

Joe

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Jan 2016 11:32:51 +1100

On 21 Jan 2016, at 12:47 am, Phillip Hallam-Baker <[email-masked]> 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.
"""

Your e-mail asked *no* questions beyond a closing "Thoughts?", and you did not follow up with any response to my note.

How *exactly* did I "refuse to give any explanation when you asked"?

You seem very willing to claim bad behaviour and besmirching of character by others, while remaining blind to your own foibles.

You also seem to presume that DEs are there to serve you -- sometimes upon a poorly-voiced wish -- rather than being appointed volunteers with a very prescribed role. The DE is not responsible for gathering statistics, summarising the consensus that led to the registry's establishment, or answering any other queries outside the scope of the registry. If someone asks nicely, I usually take the time to respond, but you didn't ask nicely -- in fact, you didn't ask at all.

I very much agree that registry process is an important area that could be substantially improved in IETF process, and have largely held my tongue despite your bad behaviour, because experience shows that engaging in this kind of petty online bickering is so rarely productive. 

However, I will not tolerate your mischaracterising my actions to the list in an attempt to justify your own poor behaviour. 

Kind regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Jan 2016 21:04:23 -0500

> 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.

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.

If you do in fact have such an argument, this is the forum that the
ART AD concerned has asked the discussion take place in. The floor is
yours.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Jan 2016 02:38:45 +0000

This thread is getting fantastically surreal, (normally, I'd
quite like that but:-) in this case, I'd say it'd be better
dropped and then re-started more calmly in a while. But since
I (think I) was mentioned...

On 21/01/16 02:04, Phillip Hallam-Baker wrote:
> Which I did at the request of an AD who thought that it
> appeared that I was suggesting the registry 

I sent Phill an offlist mail wondering if he knew that Mark
and not Roy was the relevant DE. Phill said he did, and that I'd
misinterpreted his earlier mails to apps-discuss, which I had.

> be merged on account of

That bit just puzzles me, I've no idea what you mean Phill
about merging.

But once again, I'd say letting this lie for a week and then
more calmly starting another thread is likely the better
thing here from everyone's POV.

S.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 Jan 2016 20:03:48 -0800

> On Jan 20, 2016, at 6:04 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

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.

> matter anyone else as to why two separate registries are needed at

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Jan 2016 00:33:50 -0500

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.

---

From: Joe Touch <[email-masked]>
Date: Thu, 21 Jan 2016 10:06:30 -0800

> of SRV signaling or vice versa.

That is a very strong rationale for NOT merging the two registries.

We merged the port service names and SRV registries because they both
define protocols that run over IETF transport layers, i.e., TCP, UDP,
SCTP, and DCCP.

> is "Service Name and Transport Protocol Port Number Registry". 

These were separate until merged by the action of RFC 6335.

> But
> only a minority of protocols make use of SRV signaling. 

Any of the entries can be used in an SRV record. Only a very small
number use additional TXT records for additional context for signalling.

> There is an

See RFC 6762.

> those are the identifiers to be used. And that is all I have proposed

But these are completely different things. SRV-specific and
non-SRV-specific service names run over IETF transport protocols.
.well-known runs over HTTP/HTTPS.

> Registry" for a completely different purpose.

This is the crux of the issue, and I cannot see why it matters. These
are completely different service layers.

> Even if you don't want

If the two can't be used in the same protocols or index mechanisms,
there's no reason that the two need to be merged.

Joe

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 22 Jan 2016 06:58:09 +0100

> On Jan 21, 2016, at 6:33 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

Just as there is no need for protocols that have registered a service name to use the SRV lookup that is implied, there is no need for protocols that use SRV to use the /.well-known/srv URL that is implied.  There may be good reasons to use a different /.well-known URL, such as in RFC 7711-7712 (POSH).  For POSH, we wanted a security slice through several protocols that might use /.well-known for other protocol-specific reasons, and didn't want to have to mix the security information into several different document formats.

Given this, there will continue to be other registrations in /.well-known not in /.well-known/srv, and we shouldn't let the messiness stop us from making progress.

-- 
Joe Hildebrand

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 22 Jan 2016 09:08:43 +0000

> "register" with their local web server, to reserve URL prefixes, etc.

Right. Or the ability to run multiple web servers on different ports in a way that results in a priori known URLs, such as result from assigning unique ports and then including them in the URLs. (That is why I earlier in the thread proposed to start allowing service names in addition to ports in URLs.)

Lars

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2016 10:42:18 +0100

On 1/22/16 10:08 AM, Eggert, Lars wrote:
> Right. Or the ability to run multiple web servers on different ports
> in a way that results in a priori known URLs, such as result from
> assigning unique ports and then including them in the URLs. (That is
> why I earlier in the thread proposed to start allowing service names
> in addition to ports in URLs.)

But .well-known could easily provide, if nothing else, a redirect to
such services.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2016 09:37:21 -0500

> Right. Or the ability to run multiple web servers on different ports in a way that results in a priori known URLs, such as result from assigning unique ports and then including them in the URLs. (T…

Some platforms already have this. On the Windows platform, there is a
Web Server that is tightly coupled with the TCP/IP stack so that you
can register to serve a subset of the http:// space on the machine.

The system is quite comprehensive, you can specify permissions at the
system level so that different users have permission to bind to
http://example.com/foo and http://example.com/bar. It really is very
clever if you are fortunate enough to find the pages on Stackoverflow
where the missing bits of the documentation are explained. It would be
so much easier to use if there was a note in the API documentation to
tell people they need to configure netsh http urlacl.

Referring to Joe Touch's post yesterday, yes this is a different
protocol layer to transport. But it isn't an application layer. One of
the problems of HTTP/2 was that there is a tension between the use of
HTTP as an application protocol in the browser and as a platform in
Web Services. And as he points out, we are using different identifiers
to transport layer, so it certainly isn't transport.

What I think has emerged is a new layer between transport and
application. We could call it presentation layer but people seem to
resist that because of the OSI history. So for the sake of argument,
call it the platform layer.

Unlike the OSI presentation layer, the platform layer is very thin. It
is basically using SRV or SRV+TXT to resolve domain+service to
domain+port rather than using A/AAAA to resolve domain+port to a TCP
or UDP endpoint.

It is also a bit confused because the SRV record is a bit of a hack
and doesn't have all the information we need. The specification of TCP
or UDP should have been an output of the SRV query rather than an
input.

In fact I agree with pretty much all the statements Joe T. makes in
his post. The only thing I disagree with is the assertion that being a
separate layer means this needs to be a separate registry.

It seems to me that it is worthwhile looking into such issues here
because when all is said and done, understanding of that type of issue
is going to have a lot more impact on the future of the net than the
choice of location for future IETFs.

I agree that the redefinition of SRV registrations did make the
Services and Ports registry somewhat odd. Normally we expect a
registry to be a mapping from an code point to a set of related data.
By merging in SRV the way we did, the S&P registry is now a mapping of
two sets of identifiers of different types to a data record.

[Port#] -> [Service description]
[String-ID] -> [Service description]

Is this really a problem? The issue not unique, it turns up in
cryptography as well where we have different ways to identify
algorithms in ASN.1, XML, PEM and now JOSE.

In this case the relevant parts of the two registries are both
functions of the form:

[String-ID] -> [Service description]

By 'merging the registries' I mean adding in a constraint so that a
given String-ID has the same meaning wherever it appears. This can be
achieved in different ways:

1) Merging the registry tables.

2) Establishing a constraint that an identifier that appears in one is
automatically reserved in the other and cannot be registered there.

3) Establishing a constraint  that an identifier that appears in one
is automatically reserved in the other and cannot be registered there
except for the same service.

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 22 Jan 2016 14:57:57 +0000

> But .well-known could easily provide, if nothing else, a redirect to

If whoever wants to deploy this other service has the ability to change the configuration of the server running on 80/443, to add that redirect. For the IANA assignment requests we see, they usually don't. (Fragile or impossible due to permissions to have one software install change the configuration of another.)

Allowing a service name in the URL that is looked up with DNS-SD

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 22 Jan 2016 14:59:09 +0000

> Allowing a service name in the URL that is looked up with DNS-SD

(sorry, fat-fingered "send")

...avoids this issue.

Lars

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2016 16:16:53 +0100

Hi Lars,

> Allowing a service name in the URL that is looked up with DNS-SD

I guess the question should be asked: what would break if changed the
grammar of a URI?  I think the answer is "quite a lot", and some of it
might be in places we really don't want it to break.

But you may be right that this won't solve it for every applicant we see
in the port registry.  Maybe it should be acceptable to say to the
applicant, “you need inform (somehow) the process owner  to redirect
this guy to the real management app,” and then reject the request. 
.well-known seems perfectly reasonable for that.  As Phill wrote,
Microsoft has had this forever, and with .well-known there really is no
excuse for this sort of thing to continue.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2016 10:55:12 -0500

> Allowing a service name in the URL that is looked up with DNS-SD

Just to see we are discussing the same issue:

Alice is the administrator of the system, she is running a Web Server
for the company on http://example.com/ with a redirect mapping from
http://www.example.com/*

Bob wants to setup an XXX service which is a Web Service with a HTTP
binding. Alice will let him run that service but does not want to
grant unrestricted access to the corporate Web service on port 80/443.
How do we support that?

Like many other IETF questions, this is one that comes up repeatedly
and consistency is important. It is not at all helpful if the answer
for protocol X is different from that for protocol Y.

The tools we have at our disposal are:

1) TCP/UDP port assignments
2) SRV Records
3) .well-known

Port assignments are a finite resource which was one of the reasons
SRV was invented in the first place. The other equally important
benefit of SRV is that we can direct services to different ports.

One solution to the permissions problem is to use SRV

* Alice assigns Bob the use of a port - 666 say and configures the SRV
record to point to that port:

_xxx._tcp.example.com SRV 0 10 666 example.com

Note that it is not necessary for 666 to be reserved, it is a purely
local choice. It doesn't even need to be constant at the same site.
For testing purposes, this is my current config:

_mmm._tcp.example.com SRV  0 10 9001 mmm.test.com
_mmm._tcp.example.com SRV  0 10 9002 mmm.test.com

Running both service host instances on the same machine makes
debugging the clustering code rather easier.

SRV solves the need to isolate Web Services from the corporate Web
service without needing to assign a separate port per service at the
global level. Bob can run a completely different Web Server which is
quite likely necessary if the Web Service is a standalone executable
with its own server code.

The only problem with this approach is that you don't always want to
burn a port on the local machine. Let us say that Bob has permission
to deploy multiple Web Services. Alice is willing to cut as many SRV
records as he likes but she doesn't want to give him multiple ports
because she has to reconfigure the firewall for each one.

That is what makes use of .well-known the natural adjunct to SRV.

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 22 Jan 2016 17:04:26 +0100

> That is what makes use of .well-known the natural adjunct to SRV.

This is why we in 2005 started working on URI that is the extension of SRV records in the form of being able to redirect same owner as SRV but to a URI and not only port and host. That way multiple services can run on same port (for the named service) but with different path.

   Patrik

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 22 Jan 2016 11:16:53 -0500

Hi Lars,

--On January 22, 2016 at 2:57:57 PM +0000 "Eggert, Lars" <[email-masked]> 
wrote:

> If whoever wants to deploy this other service has the ability to change
> the configuration of the server running on 80/443, to add that redirect.
> For the IANA assignment requests we see, they usually don't. (Fragile or
> impossible due to permissions to have one software install change the
> configuration of another.)
>

Actually I think that concern is overblown.

The original draft version of RFC 6764 (SRV+well-known for CalDAV and 
CardDAV) just used an SRV record and a well-known registration. After some 
comments during IETF last call I was persuaded to add an addition TXT 
record mechanism that would allow an alternative URI path to be used 
instead of /.well-known/xxx. The principal argument for that was what you 
stated above.

The reality is no one has deployed TXT record mechanism. Current 
deployments for this for some major service providers can be seen here:

dig _caldavs._tcp.google.com srv
dig _caldavs._tcp.yahoo.com srv
dig _caldavs._tcp.icloud.com srv
dig _caldavs._tcp.fastmail.com srv

They all support both caldavs and carddavs. None of them have matching TXT 
records and I am pretty sure none of the client implementations look for 
TXT either.

What's important here is that CalDAV and CardDAV are major services that 
will almost certainly be associated with a dedicated host (A-record) 
different from the providers top-level DNS entry (which you can see via 
those dig commands). In that case, the calendar/contacts server admin does 
have control over the /.well-known paths for port 80/443 so there is no 
issue with configuring those.

For smaller web-services, if those end up being deployed on a dedicated 
host, then the SRV record can simply point to that one and whoever has 
control over the config for port 80/443 can add the .well-known since they 
will likely already be adding config to support the web services 
themselves. I believe the same is true if the service ends up being hosted 
on the top-level HTTP server too. i.e., since the config will already need 
to be changed to add the actual web service, the extra cost of setting up a 
redirect for a .well-known is negligible.

So rather than saying that setting up .well-known is too difficult, we must 
instead encourage HTTP server vendors to make it easy to add .well-known 
redirects/hooks in the config (just as we had to persuade the people 
writing DNS server config UIs to support the ability to configure SRV 
records - something that was always seen as a hinderance for use of SRV, 
and in some cases still is).

-- 
Cyrus Daboo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2016 11:17:43 -0500

> This is why we in 2005 started working on URI that is the extension of SRV records in the form of being able to redirect same owner as SRV but to a URI and not only port and host. That way multiple…

And that would have been a perfectly reasonable approach if it had
been made instead of SRV. Or the IETF had published the RFC in 2005
rather than 2015.

Unfortunately, virtually every registrar supports SRV now but support
for URI is nowhere near as common. To use URI with my provider, I have
to run my own DNS.

The other problem is that URI supplements rather than replaces SRV.
And discovery is much cleaner if there is one mechanism regardless of
the service in question rather than having to know the mechanism for
the particular service.

As Joe T. pointed out, there are also some services that have prefixed
TXT records used in the discovery process and some that don't as well.

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 22 Jan 2016 18:50:50 +0100

On 22 Jan 2016, at 17:17, Phillip Hallam-Baker wrote:

> been made instead of SRV.

Yes, but SRV is as we all know much older.

> Or the IETF had published the RFC in 2005
> rather than 2015.

Well, the DNS RR Type was approved many many many years earlier.

We also did that as a test, and as you here also imply, people do not understand RRTypes registered according to the process. In reality an RFC is needed.

> for URI is nowhere near as common. To use URI with my provider, I have

Or use a DNS provider that do support "unknown" RR Types.

> The other problem is that URI supplements rather than replaces SRV.

Correct.

> TXT records used in the discovery process and some that don't as well.

Yes, but that is even worse, I think, as you know.

   Patrik

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Jan 2016 10:30:42 -0800

On 1/22/2016 8:16 AM, Cyrus Daboo wrote:
> They all support both caldavs and carddavs. None of them have matching
> TXT records and I am pretty sure none of the client implementations look
> for TXT either.

caldav SRV defines only one related TXT record:

	path=<context path>

Many other SRVs do not define any TXT records.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Jan 2016 10:59:46 -0800

On 1/22/2016 6:37 AM, Phillip Hallam-Baker wrote:
...
> protocol layer to transport. But it isn't an application layer. 

Then it doesn't belong in the IANA ports registry, IMO.

> One of

That's fine, but that then argues that it legitimately a separate
namespace, defined only in the context of HTTP.

There should be no issue at all with collisions between that namespace
and port/SRV names. port/SRV names are the entire stack to the user
above IETF transport.

> domain+port rather than using A/AAAA to resolve domain+port to a TCP

I have no idea how to parse that. If you're running over HTTP/HTTPS, the
SRV will either resolve to 80/443 or a dynamic port that's locally
assigned. You still need a way to coordinate that you're using this
service - which means the service indicator still needs to be inside the
URI passed over HTTP/HTTPS.

> and doesn't have all the information we need.

Right - when that information is common across all uses of a port
number, that extra info is in the TXT record associated with the SRV.
But there's no way to coordinate that information once you have a port
number and transport - that info has to be exchanged in-band or used
only locally.

When that information is local to a specific HTTP/HTTPS connection, it
ought to be coordinated in-band over HTTP - e.g., in the URI.

> The specification of TCP

SRV tells you how you MAY connect; you have to decide how you WANT to
connect. Depending on the way you query the DNS, you might be able to
wildcard the transport.

> separate layer means this needs to be a separate registry.

I do understand that this is your position, but I still don't quite
understand why. Can you focus on this point?

...
> [String-ID] -> [Service description]

SRV records are supposed to be:

	SRV [IP-addr, String-ID] -> [port number]
	TXT [IP-addr, String-ID] -> [name=value pairs]

More specifically:

	_service._proto.name. TTL class SRV priority weight port target.

	where:
		service is the String-ID
		proto is an IETF transport protocol (tcp/udp/stcp/dccp)
		name is a domain name where this definition is valid
		TTL, class, priority, and weight determine the nature
		of the record and how to handle multiple entries
		port is the port number
		target is the CNAME of the machine providing the service

Note that none of these actually are a "service description", and that
the lookup is from the left to the right - you provide the
service/proto/name tuple and get the rest back.

The TXT record is only meaningful if the SRV record exists, and in the
context of that SRV record. Both are for a given IP address.

I don't know of any reverse lookup support for SRV, but if there were,
it would be from [IP-addr, port] -> [String-ID]. There's no real
"description" of a service in an SRV record.

> [String-ID] -> [Service description]

That'e the issue - they're really not. Can you tell me what .well-known
returns?

> given String-ID has the same meaning wherever it appears.

In order for that to be appropriate, it has to make sense.

I can't imagine what that means, though - unless you're now proposing
that every IANA assigned port and SRV name might also be a service that
runs over HTTP.

I *really* think that's a bad idea.

> This can be achieved in different ways:

Before we consider how to achieve it, we really need to understand why
it is necessary to have these namespaces be mutually distinct.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Jan 2016 11:14:25 -0800

...
> assigning unique ports and then including them in the URLs. (That is why
> I earlier in the thread proposed to start allowing service names in
> addition to ports in URLs.)

This has nothing to do with merging .well-known and SRV.

The need to run multiple URI namespaces on a single webserver with
dynamic registration is a path coordination issue. The URI already
provides more than enough information to differentiate these uses by
path. Yes, this is a problem, but not solved by the proposed merging.

--

The proposed merging of .well-known and SRV doesn't make sense for URIs.
A URI starts with a scheme - many of which are IANA port services BUT
NOT ALL ARE. I.e., URI schemes and SRVs are not coordinated either.

.well-known is defined in the context of *one* scheme. It makes even
less sense to merge these with SRV names.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Jan 2016 14:27:24 -0500

> and port/SRV names. port/SRV names are the entire stack to the user

If we were designing from a clean slate, sure. Having XXX mean
different things at different layers of the stack isn't a problem.

But this problem is difficult precisely because the response to the
port shortage has been addressed piecemeal and gradually as a result
of a series of individual initiatives rather than through a top-down
directive.

I can design a protocol with very clear separation between my protocol
layers but I can't guarantee that anyone else will follow them.
Looking at this thread it looks pretty clear that other people have
different opinions about where they should go.

I am also rather curious as to where the TXT convention came in.
RFC6335 does not contain the string TXT. It seems to have evolved. Now
that is something that should have probably have been in a separate
registry.

We seem to be building things in an ad-hoc way in which every service
designs its own discovery mechanism. I want to see consistency.

One of the big obstacles that has held back use of SRV has been the
lack of API support on many platforms. I had to write my own DNS
library to implement it for .NET. And Patrik's URI proposal faces the
same problem.

I don't think we can really blame the platform providers when this is
being left to a handful of individuals to push in a bottom up fashion.
If any of these mechanisms is going to be adopted by all the platforms
and become ubiquitous it needs to have backing from IETF as a whole.

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Jan 2016 13:23:07 -0800

> of a series of individual initiatives rather than through a top-down

I don't see how this is related to port shortage per se. It is clearly
related to the issue of layer - i.e., that transport service names
describe the entire stack from layer 5-7, but some systems want to split
those out.

However, that cat is already out of the bag for URIs - again, "scheme"
includes some port/SRV names, but has other names as well, and there's
no attempt to merge *that* registry with port/SRV names.

.well-known is even less justified in merging registries.

> different opinions about where they should go.

Agreed; that seems like an open problem. Way too early to recommend
merging all registries at all layers into a single namespace.

> I am also rather curious as to where the TXT convention came in.

rfc6763

> RFC6335 does not contain the string TXT. 

It points to [DNS-SD], a precursor to rfc6763.

> It seems to have evolved. Now

They were, but the SRV names to which they are linked were deemed
essentially identical to port names. We could have had a separate
registry for each SRV name that used TXT records, but it seemed compact
to include them in the portname/SRV list.

> designs its own discovery mechanism. I want to see consistency.

Consistency is only important if we expect orthogonal design - the
Internet hasn't evolved that way. We don't have services over services
most other places except HTTP, and the services we run over HTTP don't
really have a relationship to the services we run over TCP/UDP/etc.

> library to implement it for .NET. And Patrik's URI proposal faces the

That's going to be a problem for any solution.

> and become ubiquitous it needs to have backing from IETF as a whole.

Agreed, but again, I don't see any of this as a rationale for merging
.well-known and SRV.

Joe

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 31 Jan 2016 13:50:19 +1100

There's an important point under all of this.

> grant unrestricted access to the corporate Web service on port 80/443.

It's exceedingly difficult. The Web has for some time set most meaningful security boundaries at the origin level -- i.e., (scheme, host, port). 

Allowing Bob access to <https://www.example.com/.well-known/bob> still gives him a considerable amount of leeway to content and capability on other parts of the origin, including:

* reading and writing cookies
* reading and writing LocalStorage
* setting ServiceWorkers to intercept requests and synthesise responses for the whole host
* access to use and set permissions for capabilities like camera access, microphone access, geolocation
* provide content -- including active content (e.g,. JavaScript) -- for execution with escalated privilege
* ability to set origin policy such as CSP, HSTS, etc.

This is a small, incomplete sample. Alice can try to limit Bob's capabilities by controlling the headers and content that he sets, but that's probably a losing battle; it requires her to keep up with every development in the Web platform, and code her containment perfectly.

The takeaway here is that .well-known is *not* a sandbox to put content into, and treating it like that can have serious security implications.

Cheers,