Subject: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Jan 2016 17:31:05 -0500

Last week I released my set of build tools for specifications and
services on sourceforge.
https://sourceforge.net/projects/phb-build-tools/

One of the tools is a JSON protocol compiler. This makes it really
easy to write a Web Service, all the code required to map API data to
HTTP messages is done for the programmer. The tools also create
entries for the reference section in the spec.

I am just writing a note on the conventions that are used to perform
this mapping which I will forward to the list in due course. In short
I could not care less what the mapping is but I do care that
everything does things in the exact same way and the approach respects
sound principles of layer abstraction etc.

Now for the problem. This is how I describe the discovery process:

"Beginning with a DNS address of the service (e.g. example.com), the
client identifies a specific HTTP URL at which to access the service.
The DNS SRV record [!RFC2782] and Well Known Service [!RFC5785]
mechanisms are used for this purpose."

So the basic idea is that given an address 'example.com' and a
protocol 'mmm', the client first attempts to resolve a host using an
SRV lookup:

_mmm._tcp.example.com 0 5 80 host1.example.com

Having found our host, we now use it to construct the web service endpoint:

To: host1.example.com
POST /.well-known/mmm/
Host: example.com

OK, so the spec is all well and good. The problem is that to make this
work, I need two separate registrations. One for the SRV record and a
second for the Well Known. That might be acceptable but the next bit
really is not, getting an SRV record is first come first served,
getting a Well Known is specification required.

This is an inconsistency in approach for a start. The two
registrations serve essentially the same purpose, there should be
essentially the same approach to registration.

I attempted to bring this up with the author but the response was
'people decided different'. Well now I am pointing out that the result
is inconsistent.

In general we should encourage as many people as possible to be using
the IANA registries and put as few obstacles in their way as possible.
We should not worry about the possibility of 'damaging the Internet'.
The people I deal with on a daily basis have been actively attempting
to destroy it for two decades without much success. And the biggest
potential for causing problems in this particular case is two people
attempting to use the same identifier - the very problem that the
registry is there to avoid.

I will also note that the use of the .well-known registry has been
negligible to date
http://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

I suggest we adopt one of two solutions to this:

1) Make the criteria for listing the same as SRV (first come)

2) Delete the registry completely and fold it into the Well Known
protocols registry used for SRV so that anyone registering an SRV
protocol access prefix will get the Well Known automatically.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Jan 2016 14:35:57 +1100

SRV isn't used by HTTP, so I'm not seeing a strong motivation for aligning the policies. Given that .well-known is a mechanism for allocating a URL on *every* Web server on the planet, and that space is ceded to standard uses by server authorities (the actual owners of that name space), having a higher bar to entry than FCFS seems like a good idea. 

> On 14 Jan 2016, at 9:31 am, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

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

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 14 Jan 2016 04:43:38 +0100

This goes back to the preference of one group of people to have things in DNS (like the URI resource record) and via DNS lookup know what URI to fetch over HTTP, and the preference from another group of people to have the redirect in HTTP from a well known URI to whatever URI to fetch over HTTP. And we have had this discussion the now last 20 years. Without really resolving it.

We all use our favorite tools, right? ;-)

My point is that regardless of whether method A or method B is in use, each one of them should be allowed to in the IETF to be designed properly.

What is actually deployed is what Daniel implements in libcurl anyway, right? :-D

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 00:26:03 -0500

> SRV isn't used by HTTP, so I'm not seeing a strong motivation for aligning the policies. Given that .well-known is a mechanism for allocating a URL on *every* Web server on the planet, and that spa…

SRV is used for discovery of many Web Services. The obvious pattern being:

1) Resolve the DNS address to a host using the SRV record

2) Use the .well-known convention to identify the service endpoint on
the specified host.

I do not see the logic in your assertion that space is being reserved
on every Web server on the planet. That was already done when
.well-known was allocated in the first place. The question now being
how to best prevent conflicts within that space.

Having to pass through a review to get a code point allocation is
empirically the least effective way of avoiding conflict.

Since I have a code generator I can simply write something into the
tool to generate the request for the code point allocation and send it
to the registry review expert but I suspect that would not be
appreciated.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 Jan 2016 16:34:22 +1100

You can also register /.well-known/phks-protocols/ and do whatever you like under it.

> On 14 Jan 2016, at 4:26 pm, Phillip Hallam-Baker <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 00:37:43 -0500

On Wed, Jan 13, 2016 at 10:43 PM, Patrik Fältström <[email-masked]> wrote:
> This goes back to the preference of one group of people to have things in
>DNS (like the URI resource record) and via DNS lookup know what URI to
 >fetch over HTTP, and the preference from another group of people to have
 >the redirect in HTTP from a well known URI to whatever URI to fetch over
 >HTTP. And we have had this discussion the now last 20 years. Without
 >really resolving it.

There are two models of Internet development. One is to let chaos
reign and the other is to keep control at all costs. The first
invariably wins in the end.

Existing practice is that most developers simply ignore the
registration process unless they are proposing the protocol to the
IETF.

I know about the URI record of course. I just can't use it with my
service provider which is a very large one using the same DNS
configuration tool used by most of the other service providers.
Deployment of new DNS record types remains a challenge.

> We all use our favorite tools, right? ;-)

No, I use the tools that are expedient and get the job done.

Since I want to make use of service identifiers inside other
identifiers, there is actually a real difference to me between
example.com and http://example.com/foo/bar. I can use the first to
construct a reasonable account identifier for the service:

[email-masked]

I really don't think people will accept identifiers of the form

alice@http://example.com/foo/bar

And no, that isn't as far fetched as it might sound. The original
OpenID proposal was to use URLs for user identifiers. And the people
involved were utterly wedged on that lunacy (someone had a patent on a
scheme to make the names friendly).

> My point is that regardless of whether method A or method B is in use, each one of them should be allowed to in the IETF to be designed properly.

+1 absolutely.

> What is actually deployed is what Daniel implements in libcurl anyway, right? :-D

Not in this case as these are all Web Services that are built way
above the level of 'fetch data'.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 00:44:42 -0500

I would prefer something shorter, how about /.well-known/phb/

And since I would fill it with the well known services registry,
shouldn't it be as short as possible. And isn't phb a little ego
centric. I suggest /.well-known// That does exactly what I want (after
canonicalization).

Seriously, I am not buying the need to review here.

---

From: t.petch <[email-masked]>
Date: Thu, 14 Jan 2016 12:04:42 +0000

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "Mark Nottingham" <[email-masked]>
Cc: "General discussion of application-layer protocols"
<[email-masked]>
Sent: Thursday, January 14, 2016 5:44 AM

> shouldn't it be as short as possible. And isn't phb a little ego

Per Hop Behavior?

// is fine until it becomes /// or //// as in file://////  so I would
prefer something short and pronounceable rather than just // such as
/id/ /et/  etc

Tom Petch

> >>> SRV isn't used by HTTP, so I'm not seeing a strong motivation for
aligning the policies. Given that .well-known is a mechanism for
allocating a URL on *every* Web server on the planet, and that space is
ceded to standard uses by server authorities (the actual owners of that
name space), having a higher bar to entry than FCFS seems like a good
idea.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 Jan 2016 16:01:07 +0100

Mark,

> You can also register /.well-known/phks-protocols/ and do whatever you like under it.

By your own words, that's simply not true unless there is a
specification tied to it, and personally I think that's a very high
bar.  On the one hand this is not like port numbers- there are a near
infinite number of possible subtrees under .well-known, as compared to
the somewhat constrained port number space.  On the other hand,  one
doesn't want to create a land rush on mnemonics.  IMHO this is possible
to fix.  Simply allocate a random string of 8 characters or so for a
developer to use (not for them to choose).  This should suit developers
who do not wish to publish their specifications or otherwise have reason
to apply more meaning or structure as you mention in Section 3 of 5785,
but otherwise do not wish to produce specifications.  For those who
still want a mnemonic, they can produce a spec.

Eliot

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 14 Jan 2016 10:15:14 -0800

> On Jan 14, 2016, at 7:01 AM, Eliot Lear <[email-masked]> wrote:
> 
> Mark,
> 
> bar.

Why is it a high bar to require a written description of the identified
space?  It doesn't require an IETF spec.  Mark is right -- if there is a
spec of why the identifier exists, the owner can do anything with further
identifiers under that space.  A review is desired because almost half of
all proposed uses of .well-known are poorly conceived and more effectively
accomplished with a single link.  But the review does not require consent.

For example, PHB wants to do a standard name search of SRV after doing a
DNS lookup and then use the SRV record to redirect to a reserved URI space.
Sorry, that is brain-numbingly poor use of those protocols.  If the
standard name is standard enough to use under .well-known, then it is
standard enough to assign directly within DNS (just like www) by the
same admin that would have crafted an SRV record, which saves two
completely useless application redirects and a whole lot of ridiculous
discussion on IETF registration lists.

The discussion does not prevent a person from registering the space
anyway, if they happen to be as stubborn as any one of us, but at least
it gives us a record of why the identifier exists and maybe some legacy
understanding of bad uses of that space.

....Roy

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 Jan 2016 20:18:07 +0100

Roy,

On 1/14/16 7:15 PM, Roy T. Fielding wrote:
> space?  It doesn't require an IETF spec.

Quoting RFC 5785:

>   Well-known URIs are registered on the advice of one or more
>    Designated Experts (appointed by the IESG or their delegate), with a
>    Specification Required (using terminology from [RFC5226]).  However,
>    to allow for the allocation of values prior to publication, the
>    Designated Expert(s) may approve registration once they are satisfied
>    that such a specification will be published.
>

That to me is problematic.  And so a spec does have to exist, and then
expert review has to happen.

>   Mark is right -- if there is a

I don't exactly know what you mean by that last sentence.
> understanding of bad uses of that space.

Maybe that is the practice but that is not typical of other expert
reviews, Roy.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 14:51:34 -0500

On Thu, Jan 14, 2016 at 1:15 PM, Roy T. Fielding <[email-masked]> wrote:
> Sorry, that is brain-numbingly poor use of those protocols.

How about you apologize for the insult and try again?

You are certainly not expert enough in this space to be calling anyone
or their proposal mind numbingly stupid.

In fact it is precisely the attitude you are demonstrating here that
is the reason why I want to eliminate the registry troll from this
particular process.

No, being a designated expert is not an excuse to piss over other
people's proposals from a great height.

I will explain the reason for my architecture after you have apologized.

If the

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 14 Jan 2016 12:00:18 -0800

> On Jan 14, 2016, at 11:51 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 

I didn't.  You read it that way.  I am sorry that you read it that way, given
that I know you quite well to be extremely smart.  That does not, however, prevent
you from using a protocol in a brain-numbingly poor way.  The brain, in question, is mine.

Please, Phillip, don't for a second believe that you can abuse social etiquette
police as a way to silence criticism.  That isn't a skill worth displaying given
the amount of criticism you have poured on others.

....Roy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 22:08:03 -0500

> still want a mnemonic, they can produce a spec.

Actually SRV and .well-known are both very much like ports in that
they serve different aspects of the same function without the port
number restriction.

The original Internet discovery mechanism had two steps:

1) Conversion of the DNS name of the service to a network host
(identified by IP address) via DNS A record lookup

2) Identifying the protocol to the host at the specified address.

The SRV record was originally proposed as a replacement for both parts
of this problem and equally importantly, to provide the fault
tolerance and load balancing capabilities that the MX record provided.

The fact that HTTP does not use SRV records is irrelevant because Web
Services have used SRV since the very first Web Services standards
were written. I know because I wrote those parts of the specs.

People developing Web Services certainly want to use a mechanism like
SRV records to get the benefits of the fault tolerance mechanism.
Using an SRV record we specify the priority, wieghting, port number
and host name of each server providing a service:

_mmm._tcp.example.com 0 20 80 host1.example.com
_mmm._tcp.example.com 0 80 80 host2.example.com
_mmm._tcp.example.com 1 5 80 voldemort.example.com

This specifies three hosts that can provide service for the domain.
When host1 and host2 are both available, host2 gets 80% of the
requests and host1 gets the rest. If a client can't connect to either,
they connect to voldemort.

The reason SRV isn't sufficient for Web services by itself is that Web
Service hosts typically host multiple services and it would be really
inconvenient (and inefficient) to separate them by port number.

Some other means of separating the Web Services is required. Some time
ago now Patrik suggested the URI scheme which is a perfectly sensible
way to achieve the objective but it does introduce other problems.

One of these is that there are now two different mechanisms for
discovery and the person configuring the protocol has to know which
one to use. Another is that many ISPs do not provide a means to
configure URI records, only SRV is supported.

So just as Netscape discovered that it was necessary to add the Host:
header to the original HTTP protocol, there is now a need to add the
SRV prefix which serves the equivalent function. The most
straightforward way to do that is to use the .well-known convention.

The logic of this approach over the URI RR becomes apparent when the
design of a HTTP successor protocol that is specifically for Web
Services is considered. Most Web services make almost no use of HTTP
features beyond the protocol identification described above and the
message framing. If one was developing a protocol that was only for
Web Services, it would not have features such as caching which are
almost never desirable. Such a protocol would probably treat URLs that
are outside the .well-known set as the exceptions.

So far I have not seen a single technical argument been made against
this approach. It quite definitely works and it is certainly as well
founded as a published RFC written by someone who was an IAB member at
the time.

The only arguments I have seen are about the need for gatekeepers to
protect the integrity of the Internet. Which in this case are being
made by the gatekeeper in question. I think that we need to know the
following:

* Approximately how many requests are made each year?
* Of these what proportion are accepted / rejected / abandoned?
* In what cases have changes been made to a protocol in order to make
it acceptable?

But regardless of the answers to these questions, there is a much
larger policy question which is what should be the IETF policy for
assignment of code points in registries that have an effectively
unlimited supply?

I am genuinely troubled by a situation in which being a domain expert
for an IANA registry seems to be giving one individual a degree of
power we do not afford the IESG. When the response to raising such
issues is personal attacks, then I take offense.

In answer to Eliot's issue, I do not see SRV prefix squatting as being
a problem. It certainly hasn't been a problem to date. The worst that
can happen is that we run out of easy to remember prefixes and people
have to use unmemorable ones. But the only practical alternative being
to start with unmemorable ones, I can't see it helping.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Jan 2016 09:55:06 -0500

Just to clarify a point people have brought up with me in private.

Yes, I am aware that Mark Nottingham is the DE for assignment of
.well-known URIs and not Mr Fielding.

That is something I was hoping Mark would point out himself. The
information is public, but it isn't necessarily something people
reading the conversation are aware of.

The reason I originally brought this up is because of complaints about
IETF process that I have received. The external perception of IETF is
that there is an inside clique who effectively gets to decide
everything through control of registration of code points. And right
now I have to agree with them.

I want this registry gone because I think it is an anathema to what
the IETF claims to stand for. Review by a Designated Expert is not an
open process. Review by a DE is not a consensus process. Review by a
DE is a distinctly unequal situation in which one party is Pope, the
other a supplicant.

Now there are cases where DE review is necessary because the code
points are limited. But this is not one of those cases and those cases
simply should not exist above the Transport layer.

The way to get architectural consistency is to describe an
architecture with sufficient clarity that people follow it as the
natural and easiest course to follow. My experience of multiple DE
reviews of URIs is that each has made demands that are completely the
opposite of the previous reviewers.

There is also a policy issue here which I think we are going to need
to discuss on the IETF list rather than here which is what level
policy should be set on such issues. Introducing a gatekeeper into the
process of deploying Internet applications is not a matter for one
working group or even one area.

---

From: "Darrel Miller" <[email-masked]>
Date: Fri, 15 Jan 2016 10:18:43 -0500

Philip,

> From: apps-discuss [mailto:[email-masked]] On Behalf Of
Phillip Hallam-Baker
>
> Most Web services make almost no use of HTTP features beyond the protocol
identification described above > and the message framing. If one was
developing a protocol that was only for Web Services, it would not have >
features such as caching which are almost never desirable. 

I believe the assertion you make here is evidence that a designated expert
is required.  You and I obviously live in very different parts of the web.
My role on a daily basis is to interact with developers who are building
services on the web.  My experience over the last two years is that
developers are attempting to make more use of HTTPs capabilities as an
application protocol and are shunning the use of HTTP simply as tunnel for
bytes.

I fully support the use of designated experts to control what becomes part
of standard registries even though I have seen registrations refused that I
believed should have been accepted.  I would much rather the bar be set high
than see registries filled with poor practices.

Darrel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 15 Jan 2016 12:20:51 -0500

> application protocol and are shunning the use of HTTP simply as tunnel for

People keep making such assertions. I have yet to see anyone make a
specific example.

When I make a proposal, I give the technical basis for it. I do not
say that people should do it my way because I am the expert which is
essentially what you are doing here.

Now the inexperienced designer might take your claim to expertise at
face value and accept it. However the fact that you are trying to
one-up one of the original designers of HTTP by pulling rank suggests
that you are rather less expert than you might imagine.

This is yet another example of the insider clique behavior that I want
to see ended.

> than see registries filled with poor practices.

Again, no specifics.

The bar to participation in this forum is an opinion and a keyboard.
It is deliberately set low because that is how the Internet emerged in
the first place.

There were plenty of people telling Clark, Cerf et al that their
design was 'mindnumbingly stupid' and the people telling them that
considered themselves to be the experts.

What you are proposing is actually contrary to one of the canons of
layered architecture. Dependencies between layers should be kept to a
minimum. I do not want a presentation layer that interacts with my
application layer. I want to decouple the two to the maximum extent
possible.

I suggest that you consider your arguments more carefully before this
discussion moves to the IETF list.

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 16 Jan 2016 09:26:52 +1000

I'm not quoting any previous discussion, I just want to make an
observation: wasn't .well-known acknowledged to be an anti-pattern when it
was set up? And isn't the DE role therefore to turn proposals away which
would be better served by a (positive) pattern elsewhere, along with that
explanation?

The bar for .well-known should be very high because http != gopher, nor
should it ever be.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 14 Jan 2016 20:51:43 +0000 (UTC)

Roy,
That is not acceptable behavior to me and I hope it is not acceptable to the AD or Jari (Ccd)
Using that type of language to describe a proposal is creating an environment that  I consider to be hostile. Now given that I have done at least as much in the field as you, I am not likely to be intimidated. But plenty of folk would be if they received a message like that from you and then careful avoidance of an apology that followed.
I see this type of behavior as being a type of bullying. I do not like bullying. Trying to bully people and then accusing them of being in the wrong for complaining about it is a very common pattern.
You are going to treat everyone and their proposals with respect. The fact that you do not understand a proposal does not make it stupid.

Sent from Outlook Mobile

    _____________________________
From: Roy T. Fielding <[email-masked]>
Sent: Thursday, January 14, 2016 3:00 PM
Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come
To: Phillip Hallam-Baker <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, Eliot Lear <[email-masked]>, General discussion of application-layer protocols <[email-masked]>

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jan 2016 14:40:04 +1100

> now I have to agree with them.

Speaking personally:

I'm very interested in improving the operation of Web-related registries, because some in those communities think that we shouldn't have registries at all, and any issues encountered only bolster that argument.

So while I've heard complaints as well, I've chosen to attempt to improve things constructively (e.g., the HAPPYIANA list, the "custodian" draft, experiments in the 5988bis draft). 

Unfortunately, you appear to be wanting to rearrange the registry operation for your personal convenience and alignment with your specific view of how the Internet works, rather than the overall good of the community.  If that's not the case, please show us how.
 
Speaking as DE for the registry under discussion:

If you have a complaint about the actual operation of the registry, I'd love to hear it so I can address it, and escalate the issue if that fails. If you have a suggestion for how to improve the registry process, perhaps an I-D and a constructive discussion is in order.

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jan 2016 04:59:25 +0000 (UTC)

I think you are projecting here.
I did not accuse you of protecting your own position as DE. In fact I only brought it up because other people thought I should
I think that the community would be best served by removing you from this process. I have repeatedly asked for specifics of the benefit you provide. You have ignored them and have just accused me of a personal agenda. 
What really worries me is that you attempt to claim both the benefit of protecting the Iternet from other people's folly and claim not to be an obstacle. Well which is it? Those are incompatible 
This is not an open process. Therefore the process must change. 

Sent from Outlook Mobile

On Sat, Jan 16, 2016 at 7:40 PM -0800, "Mark Nottingham" <[email-masked]> wrote:

Speaking personally:

 

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jan 2016 16:16:51 +1100

> On 17 Jan 2016, at 3:59 pm, Phillip Hallam-Baker <[email-masked]> wrote:
> 

OK.

> I did not accuse you of protecting your own position as DE. In fact I only brought it up because other people thought I should

Good to hear.

> I think that the community would be best served by removing you from this process. I have repeatedly asked for specifics of the benefit you provide. You have ignored them and have just accused me o…

As pointed out, there is a process for changing a registry, and that process was followed when this one was set up. If it's to change, that process should be followed too.

> What really worries me is that you attempt to claim both the benefit of protecting the Iternet from other people's folly and claim not to be an obstacle. Well which is it? Those are incompatible 

Where did I make such claims?

> This is not an open process. Therefore the process must change. 

That seems like a very premature conclusion.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jan 2016 01:02:49 -0500

> That seems like a very premature conclusion.

Well despite me asking you repeatedly to give concrete examples of the
benefits you claim you have ignored these requests. Similarly you have
not responded when I asked how many requests were made, how many
refused, how many abandoned, etc.

Yes there is a process, but the first part of any IETF process is discussion.

The problem is that you seem to have a very different idea of what
your role should be than the Tao of the IETF suggests. You are arguing
that you add value as a gatekeeper. Yet you aren't actually explaining
what the criteria you are using are.

Then there are your supporters. The first of which tried to shut down
any discussion. I would be really disappointed if the price for
getting approval was to align protocols with the particular ideology
of protocol design he is known for. Because as his behavior in this
thread demonstrates, considering other people's ideas or points of
view is not something he is good at.

Finally, no, this is not about my convenience, far from it.

I keep making technical arguments and you utterly refuse to engage on
them. The idea of using SRV + .well-known together to resolve
identifiers of the form [email-masked] is well founded and fairly
obvious. Other approaches are possible (e.g. Patrik's URI scheme) but
the only mechanism that is compatible with the legacy infrastructure
is SRV + .well-known

The fact that you ignore my many technical arguments and then demand
more technical justification is the reason I can't take your
statements seriously. I do not think your request for an ID here is
made in good faith.

This is not the venue that we will be discussing this issue. Make sure
that you have better arguments for the wider IETF community.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jan 2016 17:25:53 +1100

> refused, how many abandoned, etc.

When (as in, message IDs)? I received no such requests from you or anyone else - neither once nor "repeatedly".

But to answer regardless -- the DE isn't required to gather such statistics, nor to present them upon demand. Your best bet would be to ask IANA, or the check the mailing list yourself.

> what the criteria you are using are.

This discussion would be much more productive if you stopped making this about me and started making it about the registry policy. There was consensus for the current policy, so the burden is upon you to convince people if you want it changed.

> view is not something he is good at.

Um, Roy didn't refer to me at all. I haven't referred to him at all. Have any requests been refused based upon his argumentation? AFAICT, he's only posted to the wellknown-uri-review mailing list twice; once to argue against "dnt-policy.txt" (registered), and once to request "dnt" (registered).

But it's nice to know I have supporters. I'll cherish them.

> the only mechanism that is compatible with the legacy infrastructure

Perhaps your technical arguments are failing to convince people.

> more technical justification is the reason 

When did I do that?

> I can't take your statements seriously.

That's beginning to be mutual, Phillip.

> I do not think your request for an ID here is made in good faith.

Since you presume that I'm participating in bad faith here, there's not much point in my continuing. I'll bow out until the adults decide something needs to be done.

Cheers and Happy New Year,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 17 Jan 2016 09:24:58 -0500

> But to answer regardless -- the DE isn't required to gather such statistics, nor to present them upon demand. Your best bet would be to ask IANA, or the check the mailing list yourself.

That is not an answer, it is a refusal to give an answer.

You have asserted that your role is essential to prevent bad things
happening. The burden of proof is on you.

> This discussion would be much more productive if you stopped making this about me and started making it about the registry policy. There was consensus for the current policy, so the burden is upon…

You and Roy have both made unprovoked personal attacks on me for
merely daring to suggest that the role is unnecessary. I have not
attacked you personally. You are the person who has tried to make the
issue personal.

What you seem to be doing here is attempting to create a situation
where nobody can discuss the issue by deliberately making it personal.
You and Roy keep making personal attacks, apparently in an attempt to
claim that a breach of etiquette prevents you continuing the
discussion.

All IETF policies are subject to revision. And no, the burden of proof
is not on those that want to make change. That is an assertion you
made.

> Perhaps your technical arguments are failing to convince people.

Or perhaps this isn't about technical issues at all and your demand
for technical arguments was not in good faith.

You suggested that there was a problem with my technical argument.
Then you refused to justify it.

I note that there hasn't exactly been a flood of people supporting
your position either.

> Since you presume that I'm participating in bad faith here, there's not much point in my continuing. I'll bow out until the adults decide something needs to be done.

When you make personal attacks, that is the only conclusion I can draw.

I note that you have refused to provide evidence for a single one of
your assertions.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 17 Jan 2016 19:54:02 -0500

I'm going to step in here because I think there's some useful
discussion to continue here, amid the upset and the tensions.  I'd
like to set those latter things aside, and get us to have that useful
part of the discussion.  You'll note that my comments don't talk about
this specific situation, because what's useful, perhaps important,
here is how the Expert Review process works in general, not with any
specific registry or expert.

>>> refused, how many abandoned, etc.
...
>> But to answer regardless -- the DE isn't required to gather such statistics,
>> nor to present them upon demand. Your best bet would be to ask IANA, or
>> the check the mailing list yourself.
>

Actually, I don't think any burden of proof lies with the DE.  It's
the IETF community, as part of the IETF consensus that backed the
approval of the document and its terms for the registries it created,
that has stated that they need a designated expert and the value that
expert adds.  As AD, I have been pushing for all documents that create
such registries to provide guidance to the DE, to set community
expectations of how the DE will perform her reviews and why her
reviews are needed.  I think that's an important part of things, and I
know that too many registries were created without such guidance (that
includes the registry we're talking about here, but see below).

Also, as many of us know that, while a DE can handle reviews quietly
on her own, interacting only with IANA, it's often better to make the
process more open.  For that, we often create a public mailing list
and require discussion of registration requests on that mailing list
(as we've done in the case we're talking about here).  If the DE's
decision is notably at odds with the discussion on the mailing list,
that's a flag for the responsible AD to have a look at the situation
and see what happened and why the discrepancy is there (see below for
further comments about openness).

Formally, IANA tracks all request and the process path they take.  So
Mark is right that you can get the answers about the statistics you're
looking for from IANA.  Any DE can, of course, keep her own
statistics, but she's not required to... and most don't.

> what the criteria you are using are.

As I see it, Mark isn't arguing anything of that nature.  Discussion
needs to happen in public, which it's doing on apps-discuss and which
it can also do, in this case, on wellknown-uri-review, and the DE's
job is to use that discussion to inform his decision.  I'll note that
the RFC that controls this case, as do many such RFCs, specifically
says that the DE is expected to explain an unfavourable decision and
suggest what changes might make the request successful.  Again, see
below about openness.

> is not on those that want to make change.

I believe it is, in that we have a process that was approved by IETF
consensus, and, while IETF consensus can and surely sometimes should
change, with new information and experience since the initial
consensus, the change has to be proposed by someone, an I-D eventually
has to document the proposal, and that I-D has to go through the same
consensus process.  While IETF rough consensus isn't really a "burden
of proof" thing, I do think it's up to those who want things to change
to justify their change request and drive the consensus -- we very
much *are* (for better or worse) in a world where we have to have
rough consensus *for* the change, and things otherwise stay as they
are.

Of course, not everyone agrees with everyone, and one thing we need to
be good at, collectively, is accepting that people who disagree with
our ideas are not always (indeed are not usually) stupid, stubborn,
obsolete, or harbouring personal agendas and personal grudges.  We
have to support our cases clearly and firmly, but also graciously
accept disagreement and continue to work with each other on other
issues.  And, of course, on the other side we have to consider others'
arguments with the assumption that there might be some good stuff
there, and only reject them when we've weighed the technical
considerations.  (On all that, see the "finally" paragraph below.)

Now, on the openness of the Expert Review process, there is an
important discussion to be had: *Is* that process sufficiently open
for the IETF?  Should we, more generally, alter the process to make it
more open, with more accountability for the DEs?  As I mentioned,
there are some registries where the DE just gets a request from IANA
and returns a response, and it's up to the registrant to push the
issue if things are refused.  There are other registries where there's
at least some public discussion.  Is there still value (in general,
not for this particular case) in having registrations in some
registries reviewed by DEs?  Should we abandon that entirely?  Should
we limit it to fewer registries, and make more registries FCFS?  Or
make more registries IETF Review?  Or something else?

I think that discussion needs to happen, and should be taken to
<[email-masked]> to see where it goes.

Finally, let me ask everyone to take a step back and not discuss
anyone's motives or attitudes.  If you feel that offense has been
given you, take the higher ground and don't respond in kind, thus
avoiding escalation.  If you think someone's suggesting a bad idea, be
clear about why you think the idea is not a good one, and avoid using
inflammatory terms to describe it... and definitely avoid having that
spill out from the idea to the person proposing it.  We'll all
accomplish more if we can discuss this sensibly, even when we
disagree.

Barry, ART AD

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Jan 2016 08:01:33 +0100

Hi Barry,

Thanks for stepping in.

I'd like to make clear that my concern isn't so much about whether
expert review is needed but whether a public specification should be
required.  That is the high bar to which I referred.  The latter
eliminates the possibility of proprietary uses.  As a reviewer for other
registries, I entirely recognize the convenience of having a public
specification available.  However, a specification is not necessary to
determine the appropriateness of the use of a proposed use if the
application is sufficiently detailed.  And to me, given that the TCP/UDP
port space is far more constrained than this registry, my question is
why such a requirement exists.

The classic example of this would be a proprietary web-based management
system that has to ensure that there is no conflict with any other name
in the space.  The people developing the system don't want to publicly
expose all of their interfaces, but want to management version control
on both ends of the connection.  If a specification is required, they
simply won't bother doing one and what happens next is that the TCP/UDP
port reviewers get a request for a service that is identical to HTTP in
all ways, except for its use.  We've already seen these sorts of TCP
port requests prior to .well-known, and in fact I have raised this issue
with Apps ADs in the past.  .well-known offers us an opportunity to
tackle the problem, but not if "Specification Required" is the bar.

Eliot

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Jan 2016 18:48:47 +0000 (UTC)

Sent from Outlook Mobile

    _____________________________
From: Matthew Kerwin <[email-masked]>
Sent: Friday, January 15, 2016 6:27 PM
Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come
To:  <[email-masked]>

I'm not quoting any previous discussion, I just want to make an observation: wasn't .well-known acknowledged to be an anti-pattern when it was set up? And isn't the DE role therefore to turn proposals away which would be better served by a (positive) pattern elsewhere, along with that explanation?   

The bar for .well-known should be very high because http != gopher, nor should it ever be.  
No, it was asserted but never conceded. More importantly, the IETF reviewed and agreed the RFC which makes no mention of such a position. The position of DE is not meant to be an opportunity to impose a private view of Internet architecture on anyone. It certainly isn't an opportunity to tell people that they should 'do it my way' and especially not when that turns out to be implement someone's 20 year old thesis.I am well aware of the style of architecture that people are suggesting it is the role of the DE to impose. It is a style that I played as much of a part in creating as anyone else did. It is a style that I have used and have since abandoned because I think other approaches are better.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 19 Jan 2016 08:43:14 -0800

On Jan 16, 2016, at 10:48 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> [Matthew Kerwin wrote:]
>> wasn't .well-known acknowledged to be an anti-pattern when it was set up? And isn't the DE role therefore to turn proposals away which would be better served by a (positive) pattern elsewhere, along with that explanation?
>> 
> No, it was asserted but never conceded. More importantly, the IETF reviewed and agreed the RFC which makes no mention of such a position. 

http://tools.ietf.org/html/rfc5785#section-1.1 <http://tools.ietf.org/html/rfc5785#section-1.1>

> The position of DE is not meant to be an opportunity to impose a private view of Internet architecture on anyone. It certainly isn't an opportunity to tell people that they should 'do it my way' and especially not when that turns out to be implement someone's 20 year old thesis.

The .well-known namespace has nothing whatsoever to do with REST.  It is based on the
general idea originally exposed by /robots.txt: a set of well known resources for which no link
is necessary, such that a client can attempt to perform some defined (standard) prerequisite
action before some other "normal" action on that same origin server.

> I am well aware of the style of architecture that people are suggesting it is the role of the DE to impose. It is a style that I played as much of a part in creating as anyone else did. It is a style that I have used and have since abandoned because I think other approaches are better. 

You have not made a registration request of the DE, nor has anyone suggested that your
poor use of DNS, SRV, and .well-known had anything to do with Web Services vs REST.
Darrel Miller disagreed with your characterization of caching and use of HTTP as an
application tunnel, which is what you should expect when making statements on a mailing
list like apps-discuss that directly contradict all known experience with an IETF protocol.

https://mailarchive.ietf.org/arch/search/?email_list=wellknown-uri-review <https://mailarchive.ietf.org/arch/search/?email_list=wellknown-uri-review>

Mark suggested here that you need to pick a name to register, in accordance with the RFC.

https://mailarchive.ietf.org/arch/msg/apps-discuss/CACiBdiDnlW1X7JsnXdEXW22m1U <https://mailarchive.ietf.org/arch/msg/apps-discuss/CACiBdiDnlW1X7JsnXdEXW22m1U>
https://mailarchive.ietf.org/arch/msg/apps-discuss/X_MTE2a4xKeaPh2zOSlt4qmjNmg <https://mailarchive.ietf.org/arch/msg/apps-discuss/X_MTE2a4xKeaPh2zOSlt4qmjNmg> 

I suggested here that you can register a name even if the DE disagrees with your usage,
as there is plenty of actual evidence of that in the mailing list, that a registration discussion
is helpful for preventing misinformed folks from cluttering up the space when they actually
want something else (usually a Link header field), and that such discussion is also useful
for providing a historical record of why registrations are made regardless of suitability.

https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJP86U <https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJP86U>

The purpose of a DE is to ensure that the registrations meet the criteria of the namespace
as defined by the relevant RFC. Equating all namespaces with port numbers is nonsense.
Port numbers cannot contain trademarks, offensive slogans, or blatant categorical errors.
The .well-known space would be misused under a first-come first-served basis.

And, no, SRV would not have been used by "http" in 1992, nor would it be used in
2016, since having multiple independent Web servers per host has always been a desired
feature (to escape the largely MIS-controlled gopher phenomenon) and it is still common
today to identify configuration websites by local host names and IP addresses.
The MX record as architecture is ideal for the social characteristics of email hosting,
not for the comparatively anarchic nature of website deployment.

Since then, you have repeatedly misquoted and misrepresented what we said in your own
self-serving arguments. If anyone wants to discuss the larger role of DEs within the IETF,
I hope that they do so based on actual events and not on your fabrications.

....Roy

---

From: "Phillip Hallam-Baker" <[email-masked]>
Date: Tue, 19 Jan 2016 12:22:22 -0500

Roy's response accuses me of lying, I regard that as defamatory.

From: apps-discuss [mailto:[email-masked]] On Behalf Of Roy
T. Fielding
Sent: Tuesday, January 19, 2016 11:43 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: General discussion of application-layer protocols
<[email-masked]>
Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services
under HTTP to First Come

On Jan 16, 2016, at 10:48 AM, Phillip Hallam-Baker <[email-masked]
<mailto:[email-masked]> > wrote:

[Matthew Kerwin wrote:]

wasn't .well-known acknowledged to be an anti-pattern when it was set up?
And isn't the DE role therefore to turn proposals away which would be better
served by a (positive) pattern elsewhere, along with that explanation?

No, it was asserted but never conceded. More importantly, the IETF reviewed
and agreed the RFC which makes no mention of such a position. 

http://tools.ietf.org/html/rfc5785#section-1.1

The position of DE is not meant to be an opportunity to impose a private
view of Internet architecture on anyone. It certainly isn't an opportunity
to tell people that they should 'do it my way' and especially not when that
turns out to be implement someone's 20 year old thesis.

The .well-known namespace has nothing whatsoever to do with REST.  It is
based on the

general idea originally exposed by /robots.txt: a set of well known
resources for which no link

is necessary, such that a client can attempt to perform some defined
(standard) prerequisite

I am well aware of the style of architecture that people are suggesting it
is the role of the DE to impose. It is a style that I played as much of a
part in creating as anyone else did. It is a style that I have used and have
since abandoned because I think other approaches are better. 

You have not made a registration request of the DE, nor has anyone suggested
that your

poor use of DNS, SRV, and .well-known had anything to do with Web Services
vs REST.

Darrel Miller disagreed with your characterization of caching and use of
HTTP as an

application tunnel, which is what you should expect when making statements
on a mailing

list like apps-discuss that directly contradict all known experience with an
IETF protocol.

https://mailarchive.ietf.org/arch/search/?email_list=wellknown-uri-review

Mark suggested here that you need to pick a name to register, in accordance
with the RFC.

https://mailarchive.ietf.org/arch/msg/apps-discuss/CACiBdiDnlW1X7JsnXdEXW22m
1U

https://mailarchive.ietf.org/arch/msg/apps-discuss/X_MTE2a4xKeaPh2zOSlt4qmjN
mg 

I suggested here that you can register a name even if the DE disagrees with
your usage,

as there is plenty of actual evidence of that in the mailing list, that a
registration discussion

is helpful for preventing misinformed folks from cluttering up the space
when they actually

want something else (usually a Link header field), and that such discussion
is also useful

for providing a historical record of why registrations are made regardless
of suitability.

https://mailarchive.ietf.org/arch/msg/apps-discuss/s0JohIW0qcr7ajHUDyJD4bJP8
6U

The purpose of a DE is to ensure that the registrations meet the criteria of
the namespace

as defined by the relevant RFC. Equating all namespaces with port numbers is
nonsense.

Port numbers cannot contain trademarks, offensive slogans, or blatant
categorical errors.

The .well-known space would be misused under a first-come first-served
basis.

And, no, SRV would not have been used by "http" in 1992, nor would it be
used in

2016, since having multiple independent Web servers per host has always been
a desired

feature (to escape the largely MIS-controlled gopher phenomenon) and it is
still common

today to identify configuration websites by local host names and IP
addresses.

The MX record as architecture is ideal for the social characteristics of
email hosting,

Since then, you have repeatedly misquoted and misrepresented what we said in
your own

self-serving arguments. If anyone wants to discuss the larger role of DEs
within the IETF,

....Roy