Re: [dispatch] Web Service Discovery

Ben Campbell <ben@nostrum.com> Sun, 15 July 2018 15:35 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70376130ED6 for <dispatch@ietfa.amsl.com>; Sun, 15 Jul 2018 08:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 RHT8ByyY_Pfp for <dispatch@ietfa.amsl.com>; Sun, 15 Jul 2018 08:35:27 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69658130EFC for <dispatch@ietf.org>; Sun, 15 Jul 2018 08:35:27 -0700 (PDT)
Received: from [10.5.10.6] (ip-81-232-239-173.texas.us.northamericancoax.com [173.239.232.81]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6FFZMEx087936 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 15 Jul 2018 10:35:24 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-81-232-239-173.texas.us.northamericancoax.com [173.239.232.81] claimed to be [10.5.10.6]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <D6D7FC35-0C14-400D-ACEC-4E3890F65710@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1896578D-8701-442B-9B81-9C131F383DE4"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Sun, 15 Jul 2018 11:35:21 -0400
In-Reply-To: <CAMm+Lwhby6Sub_4FDpfBrDx-vOjZ_Ed_qHiJY3Up4qU_KS7b7Q@mail.gmail.com>
Cc: dispatch@ietf.org
To: Phillip Hallam-Baker <phill@hallambaker.com>
References: <CAMm+Lwhby6Sub_4FDpfBrDx-vOjZ_Ed_qHiJY3Up4qU_KS7b7Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/XXRVWGJmLjoSRpJY9UJ1ghwl97U>
Subject: Re: [dispatch] Web Service Discovery
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jul 2018 15:35:37 -0000

Just a general reminder for everyone interested in this topic:

We’ve got a  list specifically for discussion of HTTP "well-known" topics at https://www.ietf.org/mailman/listinfo/Http-well-known

Thanks!

Ben.



> On Jun 14, 2018, at 12:50 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> Following our last meeting, I have put together a draft describing the approach I am using to perform Web Service Discovery which I would like to discuss in Montreal
> 
> https://datatracker.ietf.org/doc/draft-hallambaker-web-service-discovery/
> 
> My approach is largely constrained by existing RFCs and 'common sense' but these are not enough to remove all variability in approaches.
> 
> The goal here is to enable discovery of Web Services by means of a compact account identifier in the form users are used to using. That is alice@example.com.
> 
> 
> I am aware of previous work in this space. In particular the original OpenID specification that tried to tell people http://example.com/alice was an account identifier, XRI, etc. and a large number of 'open' protocols with proprietary infrastructures. So there are now multiple services using the same 'open protocol' but the users can't talk to each other because the user names don't provide for federation.
> 
> In my view, none of those are as good as the approach established in rfc822 and descendants which users are already familiar with.
> 
> It will be noted that the approach does allow for negotiating across presentation protocols. For example, http vs QUIC or COAP. I have not gone down that rabbit hole at this time.
> 
> 
> I would like to move forward with this document either as an independent draft or as a Working Group. Which is appropriate really depends on whether there is an interest in defining additional discovery description keys to the three specified in the documentation. The keys I have defined are narrowly focused and the scope for variation is limited to deciding whether we should use abbreviations for the key names or not.
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch