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

"Patrik Fältström " <paf@frobbit.se> Thu, 14 January 2016 03:43 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7868F1A897D for <apps-discuss@ietfa.amsl.com>; Wed, 13 Jan 2016 19:43:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Level:
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sV-VRVBiceYT for <apps-discuss@ietfa.amsl.com>; Wed, 13 Jan 2016 19:43:40 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F97E1A897A for <apps-discuss@ietf.org>; Wed, 13 Jan 2016 19:43:40 -0800 (PST)
Received: from [192.168.1.118] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id D4E20200AE; Thu, 14 Jan 2016 04:43:38 +0100 (CET)
From: Patrik Fältström <paf@frobbit.se>
To: Mark Nottingham <mnot@mnot.net>
Date: Thu, 14 Jan 2016 04:43:38 +0100
Message-ID: <3031216E-42F9-4A5E-BB39-ABC9BE59B724@frobbit.se>
In-Reply-To: <F87BF4D5-98EB-4476-B07B-969BEF842EE2@mnot.net>
References: <CAMm+Lwj=A+KbxOvxFrURZmTmYJuGD3rXvnRToLZ_L+v-Qv_L_w@mail.gmail.com> <F87BF4D5-98EB-4476-B07B-969BEF842EE2@mnot.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_ED3721C2-F7FC-41A2-9519-97E576B0CD86_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (1.9.3r5187)
Archived-At: <http://mailarchive.ietf.org/arch/msg/apps-discuss/Hxx-y081qoQlZszEn2YlufP9FhM>
Cc: Daniel Stenberg <daniel@haxx.se>, General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] RFC 5785: Registration of .well-known services under HTTP to First Come
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2016 03:43:42 -0000

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

On 14 Jan 2016, at 4:35, Mark Nottingham wrote:

> 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 <phill@hallambaker.com> wrote:
>>
>> 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.
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss