Subject: [apps-discuss] The /.well-known/webfinger resource

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 3 Nov 2012 20:32:05 -0400

Folks,

So far, reaction has been positive in favor of option (2).  As noted, this
would mean that WebFinger is, more-or-less, the equivalent of the LRDD
resource as defined in RFC 6415, except that the default representation will
be application/json rather than application/xrd+xml.

Before we start working on the new text, I do want to understand if folks
agree to the following usage & results.

$ curl -v 'https://packetizer.com/.well-known/webfinger'
-- returns 404, as there is no specified resource
-- Should there be a different response code? If so, what?

$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:[email-masked]'
-- returns a JRD for the specified resource
-- Example:
{
  "subject" : "acct:[email-masked]",
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
    }
  ]
}

$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:[email-masked]&
           rel=vcard'
-- returns a JRD for the specified resource, filtered to include only
   the space-separated list of link relations in the "rel" parameter
-- Example:
{
  "subject" : "acct:[email-masked]",
  "links" :
  [
    {
      "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
    }
  ]
}

In all cases, the "resource" parameter might be any URI for which that
WebFinger server might be able to provide an answer.  It might be an "acct:"
URI, "mailto:" URI, "http:" URI, etc.  I think that was generally agreed
before, though we had the dialog about how to deal with the "tel:" URI and
other such URIs that do not have domain names associated with them.

Paul

---

From: William Mills <[email-masked]>
Date: Sat, 3 Nov 2012 21:48:16 -0700 (PDT)

I'm gonna ask something I should probably know, why is the resource parameter required?  Is there no use case for generic discovery here in the current SF style?  I find this surprising.

>________________________________
> From: Paul E. Jones <[email-masked]>
>To: [email-masked]; [email-masked] 
>Sent: Saturday, November 3, 2012 5:32 PM
>Subject: [apps-discuss] The /.well-known/webfinger resource
> 
>Folks,
>
>_______________________________________________
>apps-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 4 Nov 2012 14:45:13 +0100

> other such URIs that do not have domain names associated with them.

Should the email address appear somewhere in the data?

Consider an analogy with RDBMS.

1. SELECT * from users where email = 'mailto:user@host'

Would normally return the email too.

In the slightly more complex version webfinger users it's something more
like:

2a. SELECT * from users where primary_key = 'acct:user@host'

or

2b SELECT resource from users where primary_key = 'acct:user@host'

In a traditional data lookup you might expect to see an email come back, in
the result set, as that's the foreign key from which the whole dance starts
:)

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 4 Nov 2012 11:04:07 -0500

William,

The purpose of the "resource" parameter is to allow the client to ask the
server what it wants to know about.  If the client wants to know about
acct:[email-masked], for example, it uses that as the value of the
resource parameter.

RFC 6415 has the notion of issuing a request to the host-meta resource
without parameters.  The response is an XRD document that contains host-meta
information and "template" types that allow the client then then further
query for resource-specific information, replacing the "{uri}" part in the
template URI with that of the URI for which the client is seeking
information.

Paul

From: William Mills [mailto:[email-masked]] 
Sent: Sunday, November 04, 2012 12:48 AM
To: Paul E. Jones; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] The /.well-known/webfinger resource

I'm gonna ask something I should probably know, why is the resource
parameter required?  Is there no use case for generic discovery here in the
current SF style?  I find this surprising.

  _____  

Folks,

$ curl -v 'https://packetizer.com/.well-known/webfinger'
<https://packetizer.com/.well-known/webfinger%27> 
-- returns 404, as there is no specified resource
-- Should there be a different response code? If so, what?

Paul

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 4 Nov 2012 09:55:33 +0100

Yes, I support this simplified spec.

> -- Should there be a different response code? If so, what?

I'm not sure there's a need to specify the exact error code here.  I think
I'd probably return a 400 Bad Request with text "Missing 'resource' query
parameter" but if others returned a 404 or even a 500, I wouldn't be
offended.  Just document that it must contain a resource parameter.  Not
worth specifying rare parts that people will ignore anyway.

>    the space-separated list of link relations in the "rel" parameter

Why space-separated?  I can live with that, but it seems like the more
natural thing to do would be to use multiple rel parameters:

webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server

Also, I don't recall, but I assume it's only a SHOULD that the server
filter the returned list for the requested rels?

If a server instead only looked at the "resource" parameter and always
returned all link relations on every request, I think that'd be nice to
still be a compliant server.  That might also satisfy the
increasingly-small-but-still-existent camp who want webfinger to work with
"static" webservers: a URI rewrite rule like mod_rewrite can regexp out the
"resource=([^&]+?) from the query and map it to a file on disk.

> other such URIs that do not have domain names associated with them.

Don't disallow tel: for sure.  (I can certainly think of a phone number of
mine I'd love to see work with webfinger...)  But don't go out of your way
specifying how to it should or shouldn't work.

- Brad

---

From: Christian Weiske <[email-masked]>
Date: Sun, 4 Nov 2012 10:42:28 +0100

Hello Brad,

> > Before we start working on the new text, I do want to understand if
> > folks agree to the following usage & results.
> I'm not sure there's a need to specify the exact error code here.  I
> think I'd probably return a 400 Bad Request with text "Missing
> 'resource' query parameter"

That'd be the correct solution. The resource parameter is required, and
failing to provide it is a user error.

In contrast to a 404, it says "we support webfinger, but you didn't
give us all we need to answer the request". A 404 says "we don't
support webfinger".

> > -- returns a JRD for the specified resource
Yep.

> > -- returns a JRD for the specified resource, filtered to include
> > only the space-separated list of link relations in the "rel"
> > parameter

Space separation would introduce problems with rel URLs that have
spaces in them. You'd need to take care of double encoding the rel URL,
while single-encoding the " " that separate the rels.

> webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server
Because of the double-encoding issue, I support the multiple rel
parameter approach.

> filter the returned list for the requested rels.
I second that, too - because it would be impossible to serve the files
statically.

> > WebFinger server might be able to provide an answer.
> Don't disallow tel: for sure.  (I can certainly think of a phone
> number of mine I'd love to see work with webfinger...)  But don't go
> out of your way specifying how to it should or shouldn't work.

Yes, there should be no restriction on what URIs are allowed. If I want
to host a book information system that provides webfinger for ISBN
numbers, the spec should not try to hinder that.

-- 
Regards/Mit freundlichen Grüßen
Christian Weiske

-=≡ Geeking around in the name of science since 1982 ≡=-

---

From: Blaine Cook <[email-masked]>
Date: Sun, 4 Nov 2012 16:25:59 +0000

In practice, the scheme will be irrelevant. Requests for "
acct:[email-masked]", or "mailto:[email-masked]", and "[email-masked]"
will be treated the same. I suspect that owing to Postel's Law, Google et.
al. will just strip out the scheme (as with SMTP).

Likewise, if "tel:" URIs are supported by webfinger hosts, then webfinger
providers will work very hard to translate "things that look like phone
numbers" into "normalised representations of phone numbers", since there is
so much inconsistency in input formats of telephone numbers.

I don't think this has any bearing on the spec, but perhaps worthwhile
noting.

b.

On 4 November 2012 16:04, Paul E. Jones <[email-masked]> wrote:

> William,****
>
> ** **
>
> The purpose of the “resource” parameter is to allow the client to ask the
> resource parameter.****
> ** **
> without parameters.  The response is an XRD document that contains
> host-meta information and “template” types that allow the client then then
> further query for resource-specific information, replacing the “{uri}” part
> in the template URI with that of the URI for which the client is seeking
> information.****
>
> ** **
>
> Paul****
>
> ** **
>
> ** **
>
> *From:* William Mills [mailto:[email-masked]]
> *Sent:* Sunday, November 04, 2012 12:48 AM
> *To:* Paul E. Jones; [email-masked]; [email-masked]
> *Subject:* Re: [apps-discuss] The /.well-known/webfinger resource****
>
> ** **
>
> current SF style?  I find this surprising.****
>
> ** **
>
> ** **
> ------------------------------
>
> *From:* Paul E. Jones <[email-masked]>
> *To:* [email-masked]; [email-masked]
> *Sent:* Saturday, November 3, 2012 5:32 PM
> *Subject:* [apps-discuss] The /.well-known/webfinger resource****
>
>
> Folks,
>
> ****

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 4 Nov 2012 11:45:40 -0500

Melvin,

Bit off topic, but as a matter or practice, I never use "*" in an SQL
statement.  If you ask for fields explicitly, you get what you want every
time.  If you use "*", it works today, but then if somebody modifies the
underlying table and introduces a new field or moves a column, then the
impact on the application can be quite unpredictable.

To your question, though, the thing being queried does come back as the
"subject" in the JRD document.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Melvin Carvalho
Sent: Sunday, November 04, 2012 8:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] The /.well-known/webfinger resource

Folks,

$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:[email-masked]
<mailto:[email-masked]> '
-- returns a JRD for the specified resource
-- Example:
{
  "subject" : "acct:[email-masked]
<mailto:[email-masked]> ",
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    },
    {
      "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
    }
  ]
}

$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:[email-masked]
<mailto:[email-masked]> &
           rel=vcard'
-- returns a JRD for the specified resource, filtered to include only
   the space-separated list of link relations in the "rel" parameter
-- Example:
{
  "subject" : "acct:[email-masked]
<mailto:[email-masked]> ",
  "links" :
  [
    {
      "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
    }
  ]
}

or

Paul

---

From: William Mills <[email-masked]>
Date: Sun, 4 Nov 2012 08:47:28 -0800 (PST)

It might have templates, or it might have straight link relations.  An example of somethign generally interesting to know about a site might be the security contact address, or cusotmer care, etc.  

How do I query for general information about the site itself?  Do we then have to define a new relation for this?  If so then this draft should do that.

>To: 'William Mills' <[email-masked]>; [email-masked]; [email-masked] 
>Sent: Sunday, November 4, 2012 8:04 AM
>Subject: RE: [apps-discuss] The /.well-known/webfinger resource
> 
>
>William,
> 
>The purpose of the “resource” parameter is to allow the client to ask the server what it wants to know about.  If the client wants to know about acct:[email-masked], for example, it uses that as the value of the resource parameter.
> 
>RFC 6415 has the notion of issuing a request to the host-meta resource without parameters.  The response is an XRD document that contains host-meta information and “template” types that allow the client then then further query for resource-specific information, replacing the “{uri}” part in the template URI with that of the URI for which the client is seeking information.
> 
>Paul
> 
> 
>From:William Mills [mailto:[email-masked]] 
>>From:Paul E. Jones <[email-masked]>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 4 Nov 2012 11:57:26 -0500

Brad,

Comments below:

I'm not sure there's a need to specify the exact error code here.  I think I'd probably return a 400 Bad Request with text "Missing 'resource' query parameter" but if others returned a 404 or even a 500, I wouldn't be offended.  Just document that it must contain a resource parameter.  Not worth specifying rare parts that people will ignore anyway.

PEJ: OK.  We can settle on something later.  400 might be a good response, since the missing resource parameter would be a bad request.

$ curl -v 'https://packetizer.com/.well-known/webfinger?
           resource=acct:[email-masked] <mailto:[email-masked]> &
           rel=vcard'
-- returns a JRD for the specified resource, filtered to include only
   the space-separated list of link relations in the "rel" parameter

Why space-separated?  I can live with that, but it seems like the more natural thing to do would be to use multiple rel parameters:

PEJ: The reason for space-separating was to be consistent with HTML.  That’s exactly how you’ll find multiple link relation values appearing in an HTML document.  An issue with using the same parameter multiple times in the URL is that I suspect many (or most) protocol libraries would either take the first one or the last one it sees and discard the others.

Also, I don't recall, but I assume it's only a SHOULD that the server filter the returned list for the requested rels?

If a server instead only looked at the "resource" parameter and always returned all link relations on every request, I think that'd be nice to still be a compliant server.  That might also satisfy the increasingly-small-but-still-existent camp who want webfinger to work with "static" webservers: a URI rewrite rule like mod_rewrite can regexp out the "resource=([^&]+?) from the query and map it to a file on disk.

PEJ: Oh, definitely think it should be either SHOULD or MAY.  That does make it optional, but it’s one of those things that only has benefit when the returned document is enormous or when a client is seeking very specific piece of information. 

Don't disallow tel: for sure.  (I can certainly think of a phone number of mine I'd love to see work with webfinger...)  But don't go out of your way specifying how to it should or shouldn't work.

PEJ: WebFinger would accept any URI, but not every WF server would know what to do with every URI.  The “right” thing to do with a “tel” URI is query DNS and convert that into an “acct:” URI or something else.  That said, if one wants to have a client that has a “default domain” against which it makes queries using “tel” URIs, that should be legal.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 4 Nov 2012 12:18:10 -0500

Christian,

> In contrast to a 404, it says "we support webfinger, but you didn't give
> us all we need to answer the request". A 404 says "we don't support
> webfinger".

Agreed.  I think 400 is best for when the param is missing, 404 if the thing queries is unknown.
 
> Space separation would introduce problems with rel URLs that have spaces
> in them. You'd need to take care of double encoding the rel URL, while
> single-encoding the " " that separate the rels.

In addition to HTML following this convention, it is specified this way in the Web Linking document (RFC 5988), too.  I think it is best that we follow the same format as existing specs.  Link relation types are always space-separated.  I'd suggest we just define link relation types such that they do not have spaces.

> Because of the double-encoding issue, I support the multiple rel

I know this will not work in some libraries, though.  What some libraries do is create a map of tag/value pairs.  If "rel" is seen a second time, it is either ignored or the old value is replaced.

I honestly cannot recall ever having seen a web API that used the same URI parameter more than once.  We should be careful about this one.

On the other hand, a space-separated list is easy to manage.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 4 Nov 2012 12:27:03 -0500

William,

That was a question I asked in one of my email messages.  So, I understand the question, but don’t have an answer.

I think the answer might be “use host-meta”.  Another answer might be that we define a URI that is for that purpose. For example, “acct:[email-masked]” or “acct:[email-masked]”.

The risk of suggesting that we have a response about the site if no URI parameter is there is that we have a solution for that in the -02 draft :-)  But, there was push back in hacking up the host-meta resource to provide both resource-specific information and resource information.  If we use the new webfinger resource to serve both, we’re in the same boat.

Perhaps the answer is that you query webfinger if looking for resource-specific info and host-meta if looking for host information?

These all work:

$ curl 'https://packetizer.com/.well-known/host-meta'

-- returns host-meta information (and templates if one wants to follow RFC 6415 procedures)

$ curl 'https://packetizer.com/.well-known/webfinger?

-- returns resource-specific information

The host-meta file can be a text file that can definitely be static.

Paul

From: William Mills [mailto:[email-masked]] 
Sent: Sunday, November 04, 2012 11:47 AM
To: Paul E. Jones; [email-masked]; [email-masked]
Subject: Re: [apps-discuss] The /.well-known/webfinger resource

 

  _____  

William,

Paul

 

  _____  

Folks,

$ curl -v 'https://packetizer.com/.well-known/webfinger' <https://packetizer.com/.well-known/webfinger%27> 
-- returns 404, as there is no specified resource
-- Should there be a different response code? If so, what?

Paul

---

From: William Mills <[email-masked]>
Date: Sun, 4 Nov 2012 10:14:31 -0800 (PST)

AH!  OK, this is exactly the answer, host-meta is for generally advertised information, webfinger requires a resource.  Worth a mention in the spec?

>Sent: Sunday, November 4, 2012 9:27 AM

---

From: Christian Weiske <[email-masked]>
Date: Sun, 4 Nov 2012 19:08:26 +0100

Hello Paul,

> > > Why space-separated?  I can live with that, but it seems like the
> > > more natural thing to do would be to use multiple rel parameters:
> > 
> > spaces in them. You'd need to take care of double encoding the rel
> > URL, while single-encoding the " " that separate the rels.
> 
> In addition to HTML following this convention, it is specified this
> way in the Web Linking document (RFC 5988), too.  I think it is best
> that we follow the same format as existing specs.  Link relation
> types are always space-separated.  I'd suggest we just define link
> relation types such that they do not have spaces.

But URIs are allowed as link relation types. URIs may have spaces.

&rel=http://www.packetizer.com/rel/blog%20with%20space

You can't define them away.

> I know this will not work in some libraries, though.  What some
> libraries do is create a map of tag/value pairs.  If "rel" is seen a
> second time, it is either ignored or the old value is replaced.

PHP uses [] to "add" to the parameter, e.g.
> &f[]=a&f[]=b&f[]=c

so you get a GET array of
> f = array(a, b, c)

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 04 Nov 2012 21:47:02 -0500

On 11/4/2012 1:14 PM, William Mills wrote:
> AH! OK, this is exactly the answer, host-meta is for generally 
> advertised information, webfinger requires a resource.  Worth a 
> mention in the spec?

Possibly... so long as that mention does not cause a divide among the 
interested parties :-)

If we draft a new spec around those points I listed in the previous 
email (the option (2) list), then we could consider inserting that. This 
will be a clean break from RFC 6415, whereas the current WF spec is 
heavily dependent on RFC 6415.

We'll discuss this in the meeting tomorrow and see what the group thinks.

Paul

---

From: William Mills <[email-masked]>
Date: Sun, 4 Nov 2012 19:36:16 -0800 (PST)

I'd suggest where the resource parameter is defined as required that we add "Note that host-meta covers the generic case where a site wished to advertise a general profile of services when a specific resource is not requested."

Another question, are the resources listed in the resource parameter link relation names?  can we support, or do we want to support something like "oauth-*" so I don't have to list the 3 (or 2) specific OAuth related link names?

>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Sunday, November 4, 2012 6:47 PM
>Possibly... so long as that mention does not cause a divide among
    the interested parties :-)
>If we draft a new spec around those points I listed in the previous
    email (the option (2) list), then we could consider inserting that. 
    This will be a clean break from RFC 6415, whereas the current WF
    spec is heavily dependent on RFC 6415.

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 04 Nov 2012 23:42:39 -0500

Brad,

On 11/4/2012 5:06 PM, Brad Fitzpatrick wrote:
> On Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>         <mailto:[email-masked]>&
>                    rel=vcard'
>     PEJ: The reason for space-separating was to be consistent with
>     HTML.  That’s exactly how you’ll find multiple link relation
>     values appearing in an HTML document.  An issue with using the
>     same parameter multiple times in the URL is that I suspect many
>     (or most) protocol libraries would either take the first one or
>     the last one it sees and discard the others.
>
>
> But URLs aren't HTML (or JSON, or XML), and as Christian said: URLs 
> can contain %20.
>

That's true, but they are URLs are specifically selected to serve as 
"link relation" types.  The "Web Linking" spec, as I noted separately, 
also defined these as a space-separated list.  See the ABNF in RFC 
5988.  I'm just attempting to maintain consistency.  So, the Link header 
in HTTP and Link in HTML is a space separated list. Why not the URI 
parameter?

> Let's consider your real fear, that HTTP libraries suck at multiple 
> parameters, first for a server and then for a client:
>
> For a server:
> a) Servers are generally written by more competent people.  So they 
> probably know how to use their language's HTTP library properly.  All 
> languages and frameworks I've ever seen let you do it.
> b) Support for rel is only a SHOULD.  Even if a server ignores it, 
> they're still compliant.
> c) The common case will be clients requesting 0 (all) or 1 rel anyway.

My "fear" might be entirely unfounded, but...
a) Sometimes that's true ;-)  (I do agree libraries SHOULD support 
multiple parameters of the same name.)
b)  Definitely.
c) If the server only grabs the first or the last, then the results are 
totally wrong.  Thus, the server must either do it right or not do it at 
all.

>
> For a client:
> a) The common case will be clients requesting 0 (all) or 1 rel anyway.
> b) If they want to filter on 2 or more, they can read some docs. 
>  Alternatively, they can request no filter and get all the rel/value 
> pairs and do their own filtering, wasting a bit of bandwidth.
>
> I'm really not worried.
>
> Space separated seems like a hack.

I think I'm going to regret using that word ;-)  I guess I brought it on 
myself.

But, really, this one was not intended to be a hack, but just to follow 
existing style.  However, if folks prefer a list of rel parameters 
rather than a space-separated list of rels in a single rel parameter, I 
don't really care.

> But I have a good card to play now:  If we go with space-separated rel 
> parameters, I'll endeavor to introduce rel URLs containing spaces, 
> just to confuse clients.  I can see it now: "Appendix A: recommended 
> algorithm for string splitting on whitespace, re-joining fragments 
> which don't begin with 'http' with their preceeding fragment."

If there wasn't a lot of history with this space-separated list... ;-)

> Or maybe some spec already says rel URLs can't contain " ", %20, or +? 
>  If so, we'd want to reinforce that in the webfinger spec.  If not, 
> I'd especially want to avoid space separation.

I could not find anything in the Web Linking spec that forbid spaces, 
but I might have missed it.  It does speak about quote marks.  URIs 
would have to be escaped, just in case they contain certain characters.  
But, one escape is better than two, for sure. I would just like to think 
we would not select URIs that would contain spaces... but I'll never get 
that, I suppose.

> But I'm happy we're down to discussing something as boring as this.  I 
> absolutely love the recent change of direction to a radically 
> simplified spec.

:)

And just so you're happy:
$ curl 
'https://packetizer.com/.well-known/webfinger?resource=[email-masked]&rel=vcard&rel=http://microformats.org/profile/hcard&rel=vcard'

I changed my code to use multiple 'rel' parameters (and was to lazy to 
escape what I put on the command-line, but properly-escaped URLs should 
work).

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 05 Nov 2012 00:05:07 -0500

Remind me (or whomever the editor will be) once we have a new draft.

I don't recommend using wildcards (or more complex regular expressions) 
in the link relations.  This stars to get complicated for the client.

Paul

On 11/4/2012 10:36 PM, William Mills wrote:
> I'd suggest where the resource parameter is defined as required that 
> we add "Note that host-meta covers the generic case where a site 
> wished to advertise a general profile of services when a specific 
> resource is not requested."
>
> Another question, are the resources listed in the resource parameter 
> link relation names?  can we support, or do we want to support 
> something like "oauth-*" so I don't have to list the 3 (or 2) specific 
> OAuth related link names?
>
>     ------------------------------------------------------------------------
>     *To:* William Mills <[email-masked]>
>     *Cc:* "[email-masked]" <[email-masked]>;
>     "[email-masked]" <[email-masked]>
>     *Sent:* Sunday, November 4, 2012 6:47 PM
>     *Subject:* Re: [apps-discuss] The /.well-known/webfinger resource
>
>     If we draft a new spec around those points I listed in the
>     previous email (the option (2) list), then we could consider
>     inserting that.  This will be a clean break from RFC 6415, whereas
>     the current WF spec is heavily dependent on RFC 6415.
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 05 Nov 2012 00:25:23 -0500

Christian,

But, you can define them away.  These are link relation values we 
select.  They're not arbitrary URIs that users select or whatever.  I 
don't think I've ever seen a link relation URI defined to have a space 
in it.

Even so, I'll not argue the point.  But, it is important to understand 
that link relations are definitely selected names.

Paul

---

From: James M Snell <[email-masked]>
Date: Sun, 4 Nov 2012 21:37:09 -0800

Not to mention the fact that a space delimited list of uris containing
literal %20 sequences could be double escaped to bypass any ambiguity...
e.g. uri=http://.../foo%2520bar%20http://.../bar%2520foo

This would be the ideal encoding to avoid unintended decoding by overly
helpful HTTP stacks, anyway. Most ideal, however, is don't use silly uris
that contain spaces as rel values.

- James
On Nov 4, 2012 9:25 PM, "Paul E. Jones" <[email-masked]> wrote:

>
> Christian,
>
> But, you can define them away.  These are link relation values we select.
>  They're not arbitrary URIs that users select or whatever.  I don't think
> I've ever seen a link relation URI defined to have a space in it.
>
>> &rel=http://www.packetizer.**com/rel/blog%20with%20space<http://www.packetizer.com/rel/blog%20with%20space>
>>
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 5 Nov 2012 09:19:02 +0100

Indeed as rel values are well-known (even when Uris) and eventually aim at becoming simple registered tokens I wouldn't worry much about white spaces there. I'm also much more worried about interoperability with HTML forms, http stacks and server implementations (that's 3 variables already) in handling multiple fields (usually a pain), so +1 for a single space-separated list.

Le 5 nov. 2012 à 06:37, "James M Snell" <[email-masked]<mailto:[email-masked]>> a écrit :

Not to mention the fact that a space delimited list of uris containing literal %20 sequences could be double escaped to bypass any ambiguity... e.g. uri=http://.../foo%2520bar%20http://.../bar%2520foo

This would be the ideal encoding to avoid unintended decoding by overly helpful HTTP stacks, anyway. Most ideal, however, is don't use silly uris that contain spaces as rel values.

- James

On Nov 4, 2012 9:25 PM, "Paul E. Jones" <[email-masked]<mailto:[email-masked]>> wrote:

Christian,

But, you can define them away.  These are link relation values we select.  They're not arbitrary URIs that users select or whatever.  I don't think I've ever seen a link relation URI defined to have a space in it.

Even so, I'll not argue the point.  But, it is important to understand that link relations are definitely selected names.

Paul

_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/apps-discuss
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 4 Nov 2012 23:06:20 +0100

On Sun, Nov 4, 2012 at 5:57 PM, Paul E. Jones <[email-masked]> wrote:

>    the space-separated list of link relations in the "rel" parameter****
>
> ** **
>
> natural thing to do would be to use multiple rel parameters:****
>
> ** **
>
> webfinger?resource=bob&rel=vcard&rel=blog&rel=openid.server****
>
> ** **
>
> PEJ: The reason for space-separating was to be consistent with HTML.
> That’s exactly how you’ll find multiple link relation values appearing in
> an HTML document.  An issue with using the same parameter multiple times in
> the URL is that I suspect many (or most) protocol libraries would either
> take the first one or the last one it sees and discard the others.
>

But URLs aren't HTML (or JSON, or XML), and as Christian said: URLs can
contain %20.

For a server:
b) Support for rel is only a SHOULD.  Even if a server ignores it, they're
still compliant.

For a client:
a) The common case will be clients requesting 0 (all) or 1 rel anyway.
b) If they want to filter on 2 or more, they can read some docs.
 Alternatively, they can request no filter and get all the rel/value pairs
and do their own filtering, wasting a bit of bandwidth.

I'm really not worried.

But I have a good card to play now:  If we go with space-separated rel
parameters, I'll endeavor to introduce rel URLs containing spaces, just to
confuse clients.  I can see it now: "Appendix A: recommended algorithm for
string splitting on whitespace, re-joining fragments which don't begin with
'http' with their preceeding fragment."

Or maybe some spec already says rel URLs can't contain " ", %20, or +?  If
so, we'd want to reinforce that in the webfinger spec.  If not, I'd
especially want to avoid space separation.

But I'm happy we're down to discussing something as boring as this.  I
absolutely love the recent change of direction to a radically simplified
spec.

---

From: Brad Fitzpatrick <[email-masked]>
Date: Sun, 4 Nov 2012 23:07:32 +0100

> so you get a GET array of

I hope you're not proposing either

a) using brackets in URL parameters, and/or
b) letting PHP influence anything

---

From: Dick Hardt <[email-masked]>
Date: Sun, 4 Nov 2012 14:43:42 -0800

> Space separated seems like a hack.

FWIW, space delimited values are used in OAuth 2.0 requests to separate multiple scopes. I don't recall why it ended up being spaces.

Personally I like multiple rel parameters as I think it will occur once or zero times as Brad suggests.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Sun, 4 Nov 2012 19:47:04 -0800

Not being in the meeting, wanted to give a +1 to this simplification.

On Nov 4, 2012, at 6:47 PM, "Paul E. Jones" <[email-masked]> wrote:

> Possibly... so long as that mention does not cause a divide among the interested parties :-)
> 
> If we draft a new spec around those points I listed in the previous email (the option (2) list), then we could consider inserting that.  This will be a clean break from RFC 6415, whereas the current WF spec is heavily dependent on RFC 6415.
>