Subject: Re: [dispatch] Web Service Discovery

From: Ben Campbell <[email-masked]>
Date: Sun, 15 Jul 2018 11:35:21 -0400

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 <[email-masked]> 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 [email-masked].
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ben Campbell <[email-masked]>
Date: Sun, 15 Jul 2018 11:59:03 -0400

Oops, it has been brought to my attention that I was mistaken about the scope of the http-well-known mailing list. Please ignore my previous email :-)

Ben.

> On Jul 15, 2018, at 11:35 AM, Ben Campbell <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Jul 2018 23:08:37 -0400

What the draft is trying to do here is to join up the dots between the Web
Services world, the DNS world and the HTTP-ish world which are actually
more separate than might be expected.

The use of .well-known is only one part of the draft and is a default (but
a necessary one).

On Sun, Jul 15, 2018 at 11:59 AM, Ben Campbell <[email-masked]> wrote:

> Oops, it has been brought to my attention that I was mistaken about the
> scope of the http-well-known mailing list. Please ignore my previous email
> :-)
>
> Ben.
>
> > 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.
> >
> >
> >
> >> 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
> >>
> >> 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
> [email-masked].
> >>
> >>
> >> 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.