Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

From: Mike Jones <[email-masked]>
Date: Mon, 23 Apr 2012 04:11:41 +0000

I agree with your goal of simplicity for clients.  Paul’s example seems about as simple as it can get for clients:
               curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:[email-masked]
It shares the property with your earlier example (below) that clients have a no-branches code path to do discovery:
               curl -s http://example.com/.well-known/host-meta|
               awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|
               sed -e "s/{uri}/[email-masked]/"|xargs curl –s

However, I challenge the assumption in your note below that servers using only static pages must be supported.  I just don’t see the requirement to implement a query parameter as being an impediment in practice, even for hosted domains.  I know of no hosting company that doesn’t provide a means of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP, JSP, etc.  I know you’re trying to make the case for static pages, but in practice, I believe that dynamic pages are always easily available.

Assuming that we’re in an either-or situation with regard to either having single-GET discovery or supporting discovery using only static server pages (and I’d love to have someone demonstrate to us that we’re not), I’d take single-GET discovery for sure, as in some cases, it makes an appreciable difference in user interface latency, and per the paragraph above, I believe that dynamic queries can be implemented on all hosting platforms.

Assuming the WebFinger authors agree, I’d suggest that a logical next step would be for a -04 version of draft-jones-appsawg-webfinger to be published that changes support for the resource parameter from RECOMMENDED to REQUIRED, as that could provide a starting point for a common discovery spec.

                                                            -- Mike

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I’d also suggest adding text making explicit what has been an implicit assumption in both WebFinger and SWD - that depending upon whether and how the client is authenticated, the set of resources returned may vary (as Blaine had pointed out earlier).  That could help deal with some of the privacy perceptions.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: [email-masked]
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

This is the last issue that I've flagged as blocking a new Webfinger / SWD draft.

Mike suggested that being able to request a user's profile with a single request (i.e., that the /.well-known/ profile resource should be able to respond with full profile data immediately, rather than pointing at a second URL that will fulfil the request) is a requirement for this standard.

I'd like to challenge that requirement. The arguments for a direct discovery endpoint are:

1. Fewer requests against the server, since we save (in the worst-case) 50% of requests by bypassing the indirect lookup phase.
2. Lower latency for clients (e.g., mobile clients) owing to the reduced number of lookups.

The arguments for an indirect discovery endpoint are:

1. Trivial and web-standards friendly deployment for domains that won't host their own webfinger/swd profile servers, but want to enable accounts on their domains (e.g., statically hosted sites).
2. A loosening of the requirement that URLs at the bare domain must run dynamic scripts that respond to requests to the /.well-known/ path.

My opinion is that the approach that SWD has proposed for the redirect is problematic. First, the format is very similar in form to the HTML "meta refresh" tag that provided HTTP redirect support from within HTML. That format has been widely deprecated, and in these more enlightened times, we just use the 3xx response codes with Location headers, instead.

Secondly, the SWD request format means that for smaller sites, often those with the least resources, will end up serving static content in a way that's difficult to cache; certainly, more difficult to cache than just serving static content. This is due to the request parameters present in all SWD requests; those request parameters will bust caches.

As for the first argument *for* SWD's approach, I'd suggest we look to DNS, which uses the same indirection approach for NS records, relying on a (relatively) very small set of root servers to handle the traffic for the whole internet. Clearly, this approach works, and webfinger/swd servers are in a much better position to handle this additional traffic. Most of this traffic will be heavily cached, especially for the largest providers.

In fact, in terms of real deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery<http://google.com/.well-known/simple-web-discovery> is much harder than hosting a script at profiles.google.com/profile.json<http://profiles.google.com/profile.json> for all sorts of reasons, so it's my belief that the first argument is a red herring.

The second argument is legitimate, but only if mobile clients will actually be making requests to diverse webfinger/swd hosts. Instead, I strongly believe that we'll see the emergence of DNS-like servers that provide both profile hosting as well as proxy services. For a mobile client, the optimal approach will be to use SPDY to connect to a single host that performs webfinger/swd lookups on the mobile client's behalf, eliminating the latency concerns.

I offer that the two-step lookup can be implemented without conditionals on the client, whereas the direct-unless-not approach cannot be implemented that way (see my earlier curl example for proof). It's simpler, and easier to explain to the (hopefully many) small site owners who we'd like to implement this technology.

Thoughts? Am I missing something?

b.

---

From: Michiel de Jong <[email-masked]>
Date: Mon, 23 Apr 2012 09:06:30 +0200

On Mon, Apr 23, 2012 at 6:11 AM, Mike Jones <[email-masked]> wrote:
> Assuming that we’re in an either-or situation with regard to either having
> single-GET discovery or supporting discovery using only static server pages
> (and I’d love to have someone demonstrate to us that we’re not)

We are a typical use case, because over the coming months, we will be
telling 500 or so Dutch university faculties to implement
webfinger/swd, and usually those websites are run by some marketing
office. If the two-hop option disappears then my hope was i could
still use http redirect. So instead of having to host a static page
with a rare MIME type, they will now have to host a http redirect,
which their cms might even have a built-in option for. Wouldn't that
be an elegant way to have an insitu service when possible, but still
be able to do a redirect when facing bureaucracy?

It's just a suggestion, i hope i'm not sounding stupid here, and i
definitely don't want to meddle in the discussion.

Kudos to all of you! I wish the Middle East could be more like the
open web. :) We'll use whatever you guys decide on.

Cheers,
Michiel

---

From: John Bradley <[email-masked]>
Date: Mon, 23 Apr 2012 12:08:22 -0300

Mike,

I think there is less resistance to making resource parameter REQUIRED than there is to removing the initial host-meta lookup to get the template.

We should probably keep those issues separate.

I agree that supporting indirect discovery of the template via host-meta.jason should probably stay.

The question is if their can be an optimization that allows shortcutting that step if you know that all you want is web finger.

A possible option for that could be using a fixed template in /.well-known/.

That endpoint would return:
a The terminal JRD (like SWD)
b a 3xx redirect to the real endpoint
c a copy of the host-meta.jrd

We would probably only do one of b or c.

c has the advantage of being a static file and you being no worse off than having started with host-meta.json.
b is the simplest for the client and only requires common rewriting rules.

If the redirect is to the same host you could avoid the overhead of two connections by pipelining the requests over the same TCP connection.
SPDY in the future will make that even more efficient.

I will grant Blaine that most openID Connect discovery requests are Server to Server,  However there are Apps that are also clients that should not be ignored.
I personally like the fixed template with a 3xx redirect and  resource parameter returning a JRD due to the simplicity of client coding.

Things needing other sorts of information about the host would still use host-meta or host-meta.json.

John B.

On 2012-04-23, at 1:11 AM, Mike Jones wrote:

> In fact, in terms of real deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery is much harder than hosting a script atprofiles.google.com/profile.json for all sorts of reasons, so it's my belief that the first argument is a red herring.
>  
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Bob Wyman <[email-masked]>
Date: Mon, 23 Apr 2012 11:17:22 -0400

On Mon, Apr 23, 2012 at 12:11 AM, Mike Jones <[email-masked]>wrote:

>  I agree with your goal of simplicity for clients.  Paul’s example seems
> about as simple as it can get for clients:****
>
>                curl -v
> https://packetizer.com/.well-known/host-meta.json?resource=acct:[email-masked]
> ****
>
> It shares the property with your earlier example (below) that clients have
> a no-branches code path to do discovery:****
>
>                curl -s http://example.com/.well-known/host-meta|****
>
>                awk "/lrdd/,/template/"|tr -d '\n'|sed -e
> "s/^.*template='\([^']*\)'.*$/\1/"|****
>
>                sed -e "s/{uri}/[email-masked]/"|xargs curl –s****
>
> ** **
>
> However, I challenge the assumption in your note below that servers using
> only static pages must be supported.  I just don’t see the requirement to
> implement a query parameter as being an impediment in practice, even for
> hosted domains.  I know of no hosting company that doesn’t provide a means
> of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
> JSP, etc.
>

While "hosting companies" might generally allow "putting executable code
behind web pages," many on the Internet today use blogging sites as their
home sites. In many cases, these blogging sites allow no executable code
other than that which is provided by the blogging platform itself although
they often do allow the creation of static pages required by WebFinger.
Thus, bloggers will often find that they would be able to host their
own identities using WebFinger's static pages but they would not be able to
use the SWD approach (or WF resource) unless and until the blog hosting
site provides such support. Even in the case of those web hosting sites
that support hosting executable code, it should be recognized that the
creation, selection, maintenance and deployment of that executable code
requires technical knowledge greater than that enjoyed by many who have
sites on the Internet. We should not raise the bar to deployment unless
there is a truly compelling reason to do so.

If the kind of discovery we're discussing here is useful, we should do our
best to ensure that it is easily deployed by the widest range of Internet
users and the widest range of systems or devices that can host domains. We
should avoid, wherever possible any complexity that hinders the broadest
adoption or allows discovery to become dependent on the willingness of a
third party to support it.

> I know you’re trying to make the case for static pages, but in practice, I
> believe that dynamic pages are always easily available.****
>
> ** **
>
> (and I’d love to have someone demonstrate to us that we’re not), I’d take
> single-GET discovery for sure, as in some cases, it makes an appreciable
> difference in user interface latency, and per the paragraph above, I
> believe that dynamic queries can be implemented on all hosting platforms.*
> ***
>
> ** **
>
> Assuming the WebFinger authors agree, I’d suggest that a logical next step
> would be for a -04 version of draft-jones-appsawg-webfinger to be published
> that changes support for the resource parameter from RECOMMENDED to
> REQUIRED, as that could provide a starting point for a common discovery
> spec.****
>
> ** **
>
>                                                             -- Mike****
>
>   ****
>
> P.S.  As long as draft-jones-appsawg-webfinger is being revised, I’d also
> suggest adding text making explicit what has been an implicit assumption in
> both WebFinger and SWD - that depending upon whether and how the client is
> authenticated, the set of resources returned may vary (as Blaine had
> pointed out earlier).  That could help deal with some of the privacy
> perceptions.****
>
> ** **
>
> *From:* [email-masked] [mailto:
> [email-masked]] *On Behalf Of *Blaine Cook
> *Sent:* Sunday, April 22, 2012 2:15 PM
> *To:* [email-masked]
> *Subject:* [apps-discuss] Webfinger / SWD Issue #3: direct versus
> indirect discovery****
>
> ** **
>
> This is the last issue that I've flagged as blocking a new Webfinger / SWD
> draft.****
>
> ** **
>
> Mike suggested that being able to request a user's profile with a single
> request (i.e., that the /.well-known/ profile resource should be able to
> respond with full profile data immediately, rather than pointing at a
> second URL that will fulfil the request) is a requirement for this standard.
> ****
>
> ** **
>
> I'd like to challenge that requirement. The arguments for a direct
> discovery endpoint are:****
>
> ** **
>
> 1. Fewer requests against the server, since we save (in the worst-case)
> 50% of requests by bypassing the indirect lookup phase.****
>
> 2. Lower latency for clients (e.g., mobile clients) owing to the reduced
> number of lookups.****
>
> ** **
>
> The arguments for an indirect discovery endpoint are:****
>
> ** **
>
> 1. Trivial and web-standards friendly deployment for domains that won't
> host their own webfinger/swd profile servers, but want to enable accounts
> on their domains (e.g., statically hosted sites).****
>
> 2. A loosening of the requirement that URLs at the bare domain must run
> dynamic scripts that respond to requests to the /.well-known/ path.****
>
> ** **
>
> My opinion is that the approach that SWD has proposed for the redirect is
> problematic. First, the format is very similar in form to the HTML "meta
> refresh" tag that provided HTTP redirect support from within HTML. That
> format has been widely deprecated, and in these more enlightened times, we
> just use the 3xx response codes with Location headers, instead.****
>
> ** **
>
> Secondly, the SWD request format means that for smaller sites, often those
> with the least resources, will end up serving static content in a way
> that's difficult to cache; certainly, more difficult to cache than just
> serving static content. This is due to the request parameters present in
> all SWD requests; those request parameters will bust caches.****
>
> ** **
>
> As for the first argument *for* SWD's approach, I'd suggest we look to
> DNS, which uses the same indirection approach for NS records, relying on a
> (relatively) very small set of root servers to handle the traffic for the
> whole internet. Clearly, this approach works, and webfinger/swd servers are
> in a much better position to handle this additional traffic. Most of this
> traffic will be heavily cached, especially for the largest providers.****
>
> ** **
>
> In fact, in terms of real deployments, hosting a script at, e.g.,
> google.com/.well-known/simple-web-discovery is much harder than hosting a
> script at profiles.google.com/profile.json for all sorts of reasons, so
> it's my belief that the first argument is a red herring.****
>
> ** **
>
> The second argument is legitimate, but only if mobile clients will
> actually be making requests to diverse webfinger/swd hosts. Instead, I
> strongly believe that we'll see the emergence of DNS-like servers that
> provide both profile hosting as well as proxy services. For a mobile
> client, the optimal approach will be to use SPDY to connect to a single
> host that performs webfinger/swd lookups on the mobile client's behalf,
> eliminating the latency concerns.****
>
> ** **
>
> I offer that the two-step lookup can be implemented without conditionals
> on the client, whereas the direct-unless-not approach cannot be implemented
> that way (see my earlier curl example for proof). It's simpler, and easier
> to explain to the (hopefully many) small site owners who we'd like to
> implement this technology.****
>
> ** **
>
> Thoughts? Am I missing something?****
>
> ** **
>
> b.****
>

---

From: Bob Wyman <[email-masked]>
Date: Mon, 23 Apr 2012 11:26:53 -0400

On Mon, Apr 23, 2012 at 11:08 AM, John Bradley <[email-masked]> wrote:

> Mike,
>
> I think there is less resistance to making resource parameter REQUIRED
> than there is to removing the initial host-meta lookup to get the template.
>
> The question is if their can be an optimization that allows shortcutting
> that step if you know that all you want is web finger.
>
Causing a 3xx redirect typically requires modification to the configuration
files of a multi-host shared web server. Access to such configuration files
is often restricted in such a way that those responsible from just one or a
few of the sites sharing the common server are not permitted to make
modifications to those files. In many cases, such modifications can be
requested and will only be made after lengthy delays or the payment of
support and maintenance fees.

If we want this sort of discovery to become generally available, and not
just be limited to the "large" sites, we should ensure that it is as simple
as possible to deploy.

> If the redirect is to the same host you could avoid the overhead of two
> connections by pipelining the requests over the same TCP connection.
> I will grant Blaine that most openID Connect discovery requests are Server
> to Server,  However there are Apps that are also clients that should not be
> ignored.
> I personally like the fixed template with a 3xx redirect and  resource
> parameter returning a JRD due to the simplicity of client coding.
>
> JSP, etc.  I know you’re trying to make the case for static pages, but in
> practice, I believe that dynamic pages are always easily available.****
> ** **
> script atprofiles.google.com/profile.json for all sorts of reasons, so

---

From: William Mills <[email-masked]>
Date: Mon, 23 Apr 2012 08:29:09 -0700 (PDT)

I note that some examples are now using the construct (Eran called it a hack, which it probably is, but I like it) host-meta.json to select the data format.  This seems to me to be a workable way to:

-    extend the current WF stuff keeping compatibility 

-    support for JSON without funky logic
-    allow the clients to implement a single simple code path

-bill

>________________________________
> From: Mike Jones <[email-masked]>
>To: Blaine Cook <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Sunday, April 22, 2012 9:11 PM
>Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery
> 
>
> 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
>In fact, in terms of real deployments, hosting a script at, e.g., google.com/.well-known/simple-web-discovery is much harder than hosting a script at profiles.google.com/profile.json for all sorts of reasons, so it's my belief that the first argument is a red herring.
>

---

From: John Bradley <[email-masked]>
Date: Mon, 23 Apr 2012 13:19:21 -0300

I understand that in some environments you may not have access to http rewrite rules.  
Others may preclude any scripts.

We do have to decide what environments we are going to support.

If we stick to static files only then we are just putting some lipstick on Yadis by adding a way to map a email like address to a file.

So yes there are those environments, but that needs to be balanced against the additional overhead on the clients to support that environment.

John B.

On 2012-04-23, at 12:26 PM, Bob Wyman wrote:

> Causing a 3xx redirect typically requires modification to the configuration files of a multi-host shared web server. Access to such configuration files is often restricted in such a way that those responsible from just one or a few of the sites sharing the common server are not permitted to make modifications to those files. In many cases, such modifications can be requested and will only be made after lengthy delays or the payment of support and maintenance fees. 
> 
> If we want this sort of discovery to become generally available, and not just be limited to the "large" sites, we should ensure that it is as simple as possible to deploy.
>

---

From: Bob Wyman <[email-masked]>
Date: Mon, 23 Apr 2012 14:09:55 -0400

On Mon, Apr 23, 2012 at 12:19 PM, John Bradley <[email-masked]> wrote:

> If we stick to static files only then we are just putting some lipstick on
> Yadis by adding a way to map a email like address to a file.
>
> So yes there are those environments, but that needs to be balanced against
> the additional overhead on the clients to support that environment.
>

Yes, of course. We must seek a balance. What have I missed in the following
attempt to balance the proposals?

If we adopt a solution that can't be implemented with static files, then:

   - Positive: Clients which seek only one or two bits of specific
   information may experience less "overhead."
   - Negative: Clients that seek all or many bits of available information
   would experience more overhead.
   - Negative: Many sites that could otherwise provide WebFinger support
   will not be able to.

I guess the question is: "How should we weight the positive against the
negatives?" Personally, I would suggest that the negatives outweigh
(out-balances?) the positive. I believe that is why, for the many years
that WebFinger has been under discussion, that the majority of discussions
have assumed that static files would be sufficient.

bob wyman

> Causing a 3xx redirect typically requires modification to the
> configuration files of a multi-host shared web server. Access to such
> configuration files is often restricted in such a way that those
> responsible from just one or a few of the sites sharing the common server
> are not permitted to make modifications to those files. In many cases, such
> modifications can be requested and will only be made after lengthy delays
> or the payment of support and maintenance fees.
>
>> I will grant Blaine that most openID Connect discovery requests are
>> Server to Server,  However there are Apps that are also clients that should
>> not be ignored.
>> It shares the property with your earlier example (below) that clients
>> have a no-branches code path to do discovery:****
>> only static pages must be supported.  I just don’t see the requirement
>> to implement a query parameter as being an impediment in practice, even for
>> Assuming that we’re in an either-or situation with regard to either
>> having single-GET discovery or supporting discovery using only static
>> server pages (and I’d love to have someone demonstrate to us that we’re
>> not), I’d take single-GET discovery for sure, as in some cases, it makes an
>> appreciable difference in user interface latency, and per the paragraph
>> above, I believe that dynamic queries can be implemented on all hosting
>> platforms.****
>> ** **
>> Assuming the WebFinger authors agree, I’d suggest that a logical next
>> step would be for a -04 version of draft-jones-appsawg-webfinger to be
>> published that changes support for the resource parameter from RECOMMENDED
>> to REQUIRED, as that could provide a starting point for a common discovery
>> spec.****
>> ** **
>>                                                             -- Mike****
>>  ****
>> This is the last issue that I've flagged as blocking a new Webfinger /
>> SWD draft.****
>> ** **
>> Secondly, the SWD request format means that for smaller sites, often
>> those with the least resources, will end up serving static content in a way
>> google.com/.well-known/simple-web-discovery is much harder than hosting
>> a script atprofiles.google.com/profile.json for all sorts of reasons, so

---

From: John Bradley <[email-masked]>
Date: Mon, 23 Apr 2012 15:27:04 -0300

To some extent this hangs on the behaviour of a site that doesn't support the resource parameter.

In the current spec it is optional and if the server doesn't understand it you get back the whole document.

Mike,  would returning the JRD with all the relations be an acceptable response from endpoints not supporting resource?

That way large sites can optimize and small sites could still use static files.

The client would need a bit of extra logic to find the relation, but that should not be a big deal with JSON.

Sites supporting OAuth protected discovery and resource selection would be free to do that and others could have static public files

This is only half the issue.  

The other is sites that can't support a URL rewrite ruler redirect.

That leaves returning the host-meta.json file in the initial response and leaving it up to the client to apply the template.

That is effectively what WF has now.  I am not keen on that answer as it adds a second code path to the client.

John B.

On 2012-04-23, at 3:09 PM, Bob Wyman wrote:

> Yes, of course. We must seek a balance. What have I missed in the following attempt to balance the proposals?
> 
> Positive: Clients which seek only one or two bits of specific information may experience less "overhead."
> Negative: Clients that seek all or many bits of available information would experience more overhead.
> Negative: Many sites that could otherwise provide WebFinger support will not be able to. 
> I guess the question is: "How should we weight the positive against the negatives?" Personally, I would suggest that the negatives outweigh (out-balances?) the positive. I believe that is why, for the many years that WebFinger has been under discussion, that the majority of discussions have assumed that static files would be sufficient.
> 
> bob wyman
>  
> 
> John B.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Apr 2012 12:34:49 -0600

Picking on a minor point here...

> That way large sites can optimize and small sites could still use static

Is there evidence for the assumption that large services will serve
their data via an API whereas small services will serve their data via
static files? It seems clear to me that many small services might not
host static files, e.g., because they use a content management system or
community software application that automatically pulls data out of a
database of users and serves up some of that information in the form
defined by the WebFinger spec (or SWD or whatever). I rather doubt that
large services will host static files, but let's not base our design
decisions on a false premise about smaller services.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Mon, 23 Apr 2012 18:14:24 -0300

It is not my assumption.   

From a practical point of view with openID Connect, you couldn't host a IdP on a server that only supports static pages.

I think that Paul's example of a site supporting
curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:[email-masked]

Is the bar.   There are several ways to do that, so I don't think it is unreasonable.

John B.

---

From: Blaine Cook <[email-masked]>
Date: Mon, 23 Apr 2012 22:44:54 +0100

On 23 April 2012 22:14, John Bradley <[email-masked]> wrote:

> It is not my assumption.
>
> From a practical point of view with openID Connect, you couldn't host a
> IdP on a server that only supports static pages.
>

Really? I disagree. My domain, romeda.org, has only static pages on the
root domain. I've done this intentionally, because I don't have time to
maintain potentially exploitable scripts on a personal domain.

My domain is also a valid IdP; fetching /.well-known/host-meta works, and
so does following the LRDD URI. If you use a valid email address (
[email-masked]; just a dummy address, please don't email it), you'll be
given a valid OpenID Server link (it points to Google, whom I trust to run
an OpenID provider securely more than I trust myself).

curl -v
> Is the bar.   There are several ways to do that, so I don't think it is

The arguments I've heard for this are:

1. Providers can't handle the load of 50% more requests (this argument is
bunk, so we'll dismiss it unless someone provides compelling evidence
otherwise).
2. Mobile clients can't handle the additional latency.
3. A uniform API is nice-to-have. Having a two-stage lookup ruins that
uniformity.

First, argument #2: SPDY and the availability (and likelihood of usage) of
proxies means this argument is slim in the face of making it easy for
anyone to serve a host-meta document.

Argument 3 is genuinely interesting. After doing some experiments
though[1], my conclusion is still that it's easier to write reliable client
code with the two-phase process. Clients that support the
SWD_service_redirect JSON response need to be written either with a while()
loop or using recursive functions. These are vastly more complicated, and
because there's no assumption that the SWD_service_redirect is global,
caching won't work globally nor is it possible to reuse the
SWD_service_redirect response.

If we're going to go with a parameters-first approach, I'd like to see
those issues addressed. I like the uniform protocol flow, but if it means
everyone needs to write recursive functions, it's less than ideal.

b.

[1] https://gist.github.com/b52a05bf14b0d4b5ce18

---

From: John Bradley <[email-masked]>
Date: Mon, 23 Apr 2012 19:01:57 -0300

Blaine,

Rewrite rules could also be used if scripts are not possible.

I am mostly making the third argument.
Make a GET and retrieve the desired JRD.

I don't think we are talking about the SWD_service_redirect currently.

If the response can't be directly retuned, you would issue a 3xx redirect to the static file.

We need to make clients simple.  There are far more clients than servers.

John B.

On 2012-04-23, at 6:44 PM, Blaine Cook wrote:

> Really? I disagree. My domain, romeda.org, has only static pages on the root domain. I've done this intentionally, because I don't have time to maintain potentially exploitable scripts on a personal domain.
> 
> My domain is also a valid IdP; fetching /.well-known/host-meta works, and so does following the LRDD URI. If you use a valid email address ([email-masked]; just a dummy address, please don't email it), you'll be given a valid OpenID Server link (it points to Google, whom I trust to run an OpenID provider securely more than I trust myself).
>  
> 1. Providers can't handle the load of 50% more requests (this argument is bunk, so we'll dismiss it unless someone provides compelling evidence otherwise).
> 3. A uniform API is nice-to-have. Having a two-stage lookup ruins that uniformity.
> 
> First, argument #2: SPDY and the availability (and likelihood of usage) of proxies means this argument is slim in the face of making it easy for anyone to serve a host-meta document.
> 
> Argument 3 is genuinely interesting. After doing some experiments though[1], my conclusion is still that it's easier to write reliable client code with the two-phase process. Clients that support the SWD_service_redirect JSON response need to be written either with a while() loop or using recursive functions. These are vastly more complicated, and because there's no assumption that the SWD_service_redirect is global, caching won't work globally nor is it possible to reuse the SWD_service_redirect response.
> 
> If we're going to go with a parameters-first approach, I'd like to see those issues addressed. I like the uniform protocol flow, but if it means everyone needs to write recursive functions, it's less than ideal.
> 
> b.
>

---

From: Blaine Cook <[email-masked]>
Date: Mon, 23 Apr 2012 23:25:10 +0100

> If the response can't be directly retuned, you would issue a 3xx redirect

Have you tried setting up redirects on statically hosted domains? If you
have .htaccess support, it might be possible, but in practice even if
someone with a domain *does* have access to .htaccess, they probably don't
know how to configure mod_rewrite.

I've often heard the "if only DNS servers were easier", "if only it were
easier to register a domain" complaints; DNS is great, but it requires a
lot of involvement from experts. As far as I'm concerned, webfinger/swd
only works if EVERY domain with a webpage can serve it, and if EVERY domain
owner can get it to work without too much fuss.

>  We need to make clients simple.  There are far more clients than servers.

Agreed – following redirects isn't hard, but I'm not convinced that
redirects are really deployable; also, it's worth noting that for the
"brain-dead" redirect scenario, the server-side needs to properly rewrite
the query string. :-/

DNS has different discovery paths for recursive queries versus "normal"
queries. I'm not sure why we shouldn't have the same approach here.

I've mentioned a few times that we could take the approach with
webfinger/swd that DNS did, and have dumb clients use a proxy server that
does the full recursive lookup on dumb clients' behalf. I think that solves
both problems, no?

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 14:23:14 -0400

Bill,

Host-meta.json was introduced in RFC 6415 as a means of selecting JSON, particularly when the client does not have the ability to indicate via the “Accept” header that it wants “application/json”.  On my server, I return XML by default.  I also honor the “Accept” header and return the type requested.  And, I support host-meta.json, which will return JSON by default (i.e., “Accept” is “*/*”), but I still honor the “Accept” header.  I always given preference to the Accept header, which I think is appropriate, though not explicitly documented anywhere.  This is where the “hack” part comes in.  One should honor what HTTP says, but then how to we treat a request based on the URI path?  Not sure, but I’m inclined to leave it that way until somebody tells me why it’s a bad idea.

In any case, this was not invented as a part of the current draft; it was already defined.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike Jones; Blaine Cook; [email-masked]
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

-bill

  _____  

               curl -s http://example.com/.well-known/host-meta| <http://example.com/.well-known/host-meta%7C> 

               sed -e "s/{uri}/[email-masked]/ <mailto:s/%7buri%7d/[email-masked]/> "|xargs curl –s

                                                            -- Mike

b.

---

From: William Mills <[email-masked]>
Date: Wed, 25 Apr 2012 11:29:16 -0700 (PDT)

Even better.

> From: Paul E. Jones <[email-masked]>
>To: 'William Mills' <[email-masked]>; 'Mike Jones' <[email-masked]>; 'Blaine Cook' <[email-masked]>; [email-masked] 
>Sent: Wednesday, April 25, 2012 11:23 AM
>Subject: RE: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery
> 
>
>Bill,
> 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of William Mills
>>From:Mike Jones <[email-masked]>
>>               curl -s http://example.com/.well-known/host-meta%7C

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 14:30:44 -0400

John,

I don't think we need to decide specific environments we want to support,
but *if* people want to use static files, there are choices we can make
where the resource parameter will still work, even in a static environment.
Previously, I sent out a sample config that allows Apache to handle the
"resource" parameter and still map that to static files.  However, I cannot
do the same with the "rel" parameter, thus we could never mandate that if we
want to have any hope at all for allowing static sites.

I appreciate having the "resource" parameter, but I also appreciate some do
not need (or have the ability to support) an elaborate server.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of John Bradley
Sent: Monday, April 23, 2012 12:19 PM
To: Bob Wyman
Cc: [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

I understand that in some environments you may not have access to http
rewrite rules.  

John B.

 

Mike,

I think there is less resistance to making resource parameter REQUIRED than
there is to removing the initial host-meta lookup to get the template.

I agree that supporting indirect discovery of the template via
host-meta.jason should probably stay.

c has the advantage of being a static file and you being no worse off than
having started with host-meta.json.

Things needing other sorts of information about the host would still use
host-meta or host-meta.json.

John B.

I agree with your goal of simplicity for clients.  Paul's example seems
about as simple as it can get for clients:

               curl -v
https://packetizer.com/.well-known/host-meta.json?resource=acct:paulej@packe
tizer.com

It shares the property with your earlier example (below) that clients have a
no-branches code path to do discovery:

               curl -s http://example.com/.well-known/host-meta|
<http://example.com/.well-known/host-meta%7C> 

               awk "/lrdd/,/template/"|tr -d '\n'|sed -e
"s/^.*template='\([^']*\)'.*$/\1/"|

               sed -e "s/{uri}/[email-masked]/"|xargs curl -s

However, I challenge the assumption in your note below that servers using
only static pages must be supported.  I just don't see the requirement to
implement a query parameter as being an impediment in practice, even for
hosted domains.  I know of no hosting company that doesn't provide a means
of putting executable code behind web pages, be it PHP, Perl, Ruby, ASP,
JSP, etc.  I know you're trying to make the case for static pages, but in
practice, I believe that dynamic pages are always easily available.

Assuming that we're in an either-or situation with regard to either having
single-GET discovery or supporting discovery using only static server pages
(and I'd love to have someone demonstrate to us that we're not), I'd take
single-GET discovery for sure, as in some cases, it makes an appreciable
difference in user interface latency, and per the paragraph above, I believe
that dynamic queries can be implemented on all hosting platforms.

Assuming the WebFinger authors agree, I'd suggest that a logical next step
would be for a -04 version of draft-jones-appsawg-webfinger to be published
that changes support for the resource parameter from RECOMMENDED to
REQUIRED, as that could provide a starting point for a common discovery
spec.

                                                            -- Mike

P.S.  As long as draft-jones-appsawg-webfinger is being revised, I'd also
suggest adding text making explicit what has been an implicit assumption in
both WebFinger and SWD - that depending upon whether and how the client is
authenticated, the set of resources returned may vary (as Blaine had pointed
out earlier).  That could help deal with some of the privacy perceptions.

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: [email-masked]
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

draft.

Mike suggested that being able to request a user's profile with a single
request (i.e., that the /.well-known/ profile resource should be able to
respond with full profile data immediately, rather than pointing at a second
URL that will fulfil the request) is a requirement for this standard.

I'd like to challenge that requirement. The arguments for a direct discovery
endpoint are:

1. Fewer requests against the server, since we save (in the worst-case) 50%
of requests by bypassing the indirect lookup phase.

number of lookups.

1. Trivial and web-standards friendly deployment for domains that won't host
their own webfinger/swd profile servers, but want to enable accounts on
their domains (e.g., statically hosted sites).

2. A loosening of the requirement that URLs at the bare domain must run
dynamic scripts that respond to requests to the /.well-known/ path.

just use the 3xx response codes with Location headers, instead.

Secondly, the SWD request format means that for smaller sites, often those
with the least resources, will end up serving static content in a way that's
difficult to cache; certainly, more difficult to cache than just serving
static content. This is due to the request parameters present in all SWD
requests; those request parameters will bust caches.

As for the first argument *for* SWD's approach, I'd suggest we look to DNS,
which uses the same indirection approach for NS records, relying on a
(relatively) very small set of root servers to handle the traffic for the
whole internet. Clearly, this approach works, and webfinger/swd servers are
in a much better position to handle this additional traffic. Most of this
traffic will be heavily cached, especially for the largest providers.

In fact, in terms of real deployments, hosting a script at, e.g.,
google.com/.well-known/simple-web-discovery is much harder than hosting a
script atprofiles.google.com/profile.json for all sorts of reasons, so it's
my belief that the first argument is a red herring.

The second argument is legitimate, but only if mobile clients will actually
be making requests to diverse webfinger/swd hosts. Instead, I strongly
believe that we'll see the emergence of DNS-like servers that provide both
profile hosting as well as proxy services. For a mobile client, the optimal
approach will be to use SPDY to connect to a single host that performs
webfinger/swd lookups on the mobile client's behalf, eliminating the latency
concerns.

I offer that the two-step lookup can be implemented without conditionals on
the client, whereas the direct-unless-not approach cannot be implemented
that way (see my earlier curl example for proof). It's simpler, and easier
to explain to the (hopefully many) small site owners who we'd like to
implement this technology.

b.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 18:33:57 +0000

Serving anything other than JRD on host-meta.json, while legal HTTP, is odd. I would reject the request if the Accept header is specifying anything other than JRD. The benefit of this approach is that it allows protocol to explicitly specify host-meta.json as the discovery endpoint, which has the same effect of making JSON the required and only format. One issue is that this doesn’t extend to LRDD which means, if the server doesn’t support the query parameters, the client might end up with XML in LRDD links.

We should first decide on how to approach the format issue, then just go and update/replace 6415 accordingly. I don’t think the scale of existing deployment is significant enough to play a major role. It’s ok to break some stuff for a cleaner, clearer future.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul E. Jones
Sent: Wednesday, April 25, 2012 11:23 AM
To: 'William Mills'; 'Mike Jones'; 'Blaine Cook'; [email-masked]
Subject: Re: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

Bill,

Paul

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of William Mills
Sent: Monday, April 23, 2012 11:29 AM
To: Mike Jones; Blaine Cook; [email-masked]<mailto:[email-masked]>
Subject: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

-bill

________________________________
From: Mike Jones <[email-masked]<mailto:[email-masked]>>
To: Blaine Cook <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, April 22, 2012 9:11 PM
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

I agree with your goal of simplicity for clients.  Paul’s example seems about as simple as it can get for clients:
               curl -v https://packetizer.com/.well-known/host-meta.json?resource=acct:[email-masked]
It shares the property with your earlier example (below) that clients have a no-branches code path to do discovery:
               curl -s http://example.com/.well-known/host-meta|<http://example.com/.well-known/host-meta%7C>
               awk "/lrdd/,/template/"|tr -d '\n'|sed -e "s/^.*template='\([^']*\)'.*$/\1/"|
               sed -e "s/{uri}/[email-masked]/<mailto:s/%7buri%7d/[email-masked]/>"|xargs curl –s

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Blaine Cook
Sent: Sunday, April 22, 2012 2:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

b.

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 16:13:20 -0300

If WF were to make resource REQUIRED and rel optional that would be a significant step forward.

Though the Apache http rewrite probably violates the host-meta processing rules Eran just described, if the links from host-meta must be included in order.
You could get around it by restricting the contents of host-meta if you are doing that I suppose.

John B.

On 2012-04-25, at 3:30 PM, Paul E. Jones wrote:

> John,
>  
> I don’t think we need to decide specific environments we want to support, but *if* people want to use static files, there are choices we can make where the resource parameter will still work, even in a static environment.  Previously, I sent out a sample config that allows Apache to handle the “resource” parameter and still map that to static files.  However, I cannot do the same with the “rel” parameter, thus we could never mandate that if we want to have any hope at all for allowing static sites.
>  
> I appreciate having the “resource” parameter, but I also appreciate some do not need (or have the ability to support) an elaborate server.
>  
> Paul
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley

---

From: Blaine Cook <[email-masked]>
Date: Wed, 25 Apr 2012 22:45:05 +0100

*sigh*

This is crazy. There are a half-dozen of us debating theoretical ways to
structure a thing that may or may not ever get used, so that some specs can
get finalised so that *maybe* Microsoft and Google can ship a new version
of OpenID (that doesn't adequately address one of the core usability
shortcomings of the first two OpenIDs).

I don't know if Evan Prodromou or anyone from Diaspora or anyone else who
has *actually tried to deploy* similar things is watching this thread, but
if they are, I hope they pipe up, because there is absolutely zero
consideration for actual implementations happening in this discussion.

Also, keep in mind that if *we're* confused about the host-meta processing
rules, or if my "single-code-path" arguments are being dismissed because
"it's easy either way", then we're in a lot of trouble. Refer to the fact
that we've switched from XML to JSON because XML is too hard for most
developers.

The point of all this is to make it accessible and easy, since we have a
chicken-and-egg problem. If this is going to work, it's going to take the
whole long tail, not just Microsoft and Google. The specs we have right now
clearly don't work, but idle speculation on our part isn't going to make
any of this work.

b.

---

From: Mike Jones <[email-masked]>
Date: Wed, 25 Apr 2012 22:13:30 +0000

I agree that if we’re confused about the host-meta processing rules, etc. it’s a sign that we’re making things too hard.  I believe these are exactly the kinds of reasons that led Yaron to develop Simple Web Discovery.

Maybe it’s time for people to reread http://www.goland.org/simplewebfinger/ and http://www.goland.org/managingfingerservice/ (or to read them for the first time).  I suspect the reasoning in them will resonate more in the context of the current discussion, for what it’s worth…

                                                            -- Mike

P.S.  You can take the viewpoint this is about Microsoft and Google if you like, but in my mind, this is about ubiquitous discovery for the open Web.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Blaine Cook
Sent: Wednesday, April 25, 2012 2:45 PM
To: [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

*sigh*

This is crazy. There are a half-dozen of us debating theoretical ways to structure a thing that may or may not ever get used, so that some specs can get finalised so that *maybe* Microsoft and Google can ship a new version of OpenID (that doesn't adequately address one of the core usability shortcomings of the first two OpenIDs).

I don't know if Evan Prodromou or anyone from Diaspora or anyone else who has *actually tried to deploy* similar things is watching this thread, but if they are, I hope they pipe up, because there is absolutely zero consideration for actual implementations happening in this discussion.

Also, keep in mind that if *we're* confused about the host-meta processing rules, or if my "single-code-path" arguments are being dismissed because "it's easy either way", then we're in a lot of trouble. Refer to the fact that we've switched from XML to JSON because XML is too hard for most developers.

The point of all this is to make it accessible and easy, since we have a chicken-and-egg problem. If this is going to work, it's going to take the whole long tail, not just Microsoft and Google. The specs we have right now clearly don't work, but idle speculation on our part isn't going to make any of this work.

b.

---

From: Blaine Cook <[email-masked]>
Date: Wed, 25 Apr 2012 23:31:07 +0100

On 25 April 2012 23:13, Mike Jones <[email-masked]> wrote:

>  P.S.  You can take the viewpoint this is about Microsoft and Google if
> you like, but in my mind, this is about ubiquitous discovery for the open
> Web.
>

I'll take another look at Yaron's posts when I get a chance, but yes – we
definitely agree on this! :-) I'm just worried that there's a very limited
set of people debating this. I'm working on getting relevant people to
comment. I strongly believe in the consensus process here, but we really
need the code bit in play for this discussion to be fruitful.

b.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 22:46:36 +0000

I would argue that much of the confusion is coming from trying to understand host-meta from a few examples rather than read the (very short) specification. There is value in both proposals in that they represent very different use cases and development experience.

I am not advocating any particular end result here – I am confident I will never need to implement any of this, so my participation here is limited to offering clarification on host-meta and representing about 5 years of community work I’ve been part of.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, April 25, 2012 3:14 PM
To: Blaine Cook; [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

                                                            -- Mike

*sigh*

b.

---

From: Eran Hammer <[email-masked]>
Date: Wed, 25 Apr 2012 23:01:36 +0000

I’ll add one more observation.

Throughout this work, the main challenge – 95% of the problem – has always been adoption. Maybe compromises were made along the way to win the support of major players. The part people on this list have a hard time agreeing is what is the best solution that will lead to the fastest adoption, and who are the most important early adopters.

I have stopped chiming in with my opinions and positions because I have no plans in the foreseeable future to implement this on the client or server. There is little value in a generic discovery framework that is not widely adopted. This discussion would be much more effective if it was held in private among a select few who can quickly agree on something *they* can actually ship to get to a critical mass. But of course, this is not how this community works.

The technical details being debated here matter, but not much. Everything suggested so far will work – if enough people adopt it.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer
Sent: Wednesday, April 25, 2012 3:47 PM
To: Mike Jones; Blaine Cook; [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Wednesday, April 25, 2012 3:14 PM
To: Blaine Cook; [email-masked]<mailto:[email-masked]>
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect discovery

                                                            -- Mike

*sigh*

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 20:37:13 -0400

Eran,

I agree that it’s odd, but clients would never see XML unless they explicitly asked for it.  And, if they do ask for it, it would be equally odd to return JSON, IMO.

For LRDD, if the requestor asks for JSON, I ensure the LRDD link relation returned will also result in JSON being selected.  Ditto for XML.  Again, though, if you visit the LRDD resource that was intended to serve JSON and you explicitly ask for XML, I’ll return XML.

I’m having a hard time justifying ignoring the Accept header.  I think it should always be given priority.

Paul

From: Eran Hammer [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 2:34 PM
To: Paul E. Jones; 'William Mills'; 'Mike Jones'; 'Blaine Cook'; [email-masked]
Subject: RE: [apps-discuss] Is host-meta.json viable? Re: Webfinger / SWD Issue #3: direct versus indirect discovery

EH

Bill,

Paul

-bill

  _____  

                                                            -- Mike

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 21:08:41 -0400

That's exactly what I'd suggest for static sites. don't put resource
specific stuff in host-meta.  For non-static sites, one could be more
flexible.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 3:13 PM
To: Paul E. Jones
Cc: 'Bob Wyman'; [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

If WF were to make resource REQUIRED and rel optional that would be a
significant step forward.

Though the Apache http rewrite probably violates the host-meta processing
rules Eran just described, if the links from host-meta must be included in
order.

You could get around it by restricting the contents of host-meta if you are
doing that I suppose.

John B.

John,

Paul

John B.

 

Mike,

John B.

               curl -v

                                                            -- Mike

b.

---

From: John Bradley <[email-masked]>
Date: Wed, 25 Apr 2012 22:27:47 -0300

Some of the rewriting rules Eran described make putting resource specific stuff in host-meta a challenge for a simple site.

Is their agreement on making resource REQUIRED.   I still have a feeling that some people (Blaine?) may not be bought into that.

I agree that you have a simple solution that covers most of the situations as long as you don't put resource specific stuff in host-meta.

John B.
On 2012-04-25, at 10:08 PM, Paul E. Jones wrote:

> That’s exactly what I’d suggest for static sites… don’t put resource specific stuff in host-meta.  For non-static sites, one could be more flexible.
>  
> Paul
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 25 Apr 2012 21:59:13 -0400

John,

For a static sites, I would expect either everything would come from
host-meta or LRDD, but not both.  I would only expect sites that are running
code to support WebFinger to put stuff in both host-meta and LRDD.

Here's an example of how to do a static site on Apache:

http://www.packetizer.com/webfinger/server.html

(I just wrote that, so I hope it's not full of errors.  It's not even that
late at night, yet, so I have little excuse for the typos I tend to produce
as the evening wears.)

For non-static sites, including small ones and large ones, then it does not
matter.  Size of the site is not a big deal.  It's really 'static' vs
'non-static'.  My site is relatively small, but it's got running code with
live examples pulled from a database.  So, for those who want to run an
"active" server, it's trivial to do.

Paul

From: John Bradley [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2012 9:28 PM
To: Paul E. Jones
Cc: 'Bob Wyman'; [email-masked]
Subject: Re: [apps-discuss] Webfinger / SWD Issue #3: direct versus indirect
discovery

Some of the rewriting rules Eran described make putting resource specific
stuff in host-meta a challenge for a simple site.

Is their agreement on making resource REQUIRED.   I still have a feeling
that some people (Blaine?) may not be bought into that.

I agree that you have a simple solution that covers most of the situations
as long as you don't put resource specific stuff in host-meta.

John B.

Paul

John B.

John,

Paul

John B.

 

Mike,

John B.

               curl -v

                                                            -- Mike

b.