Subject: Re: [webfinger] Possibly speeding up the RFC process

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 15:23:35 -0500

Melvin,

Going this route is not going to address the issues people have.  The draft
is oh-so-very-close to completion. I think that folks are largely OK with
the text, the procedures, and the data format.  There are still editorial
matters, but nothing controversial.

The only sticky issue is use of TLS or not.  But it's a big one and we ought
to get this right.

Without requiring use of TLS, there exists the possibility that a person
queries for "[email-masked]" and a thief intercepts that
request and provides bogus information.  The user might trust that
information, call a discovered phone number, and provide the thief with
information that the thief can use to empty the user's bank accounts.

Requiring TLS, though, is viewed as a roadblock to deployment.  For sites
where security simply is not that important, it is a valid question as to
why TLS must be mandated.

Some clients are in the unfortunate position of not knowing whether security
is or is not important for any given query.  Some clients know, though.  If
I had software on my server that facilitates an OpenID login, it would know
to use TLS only.  My email client, though, does not know how important
security is.

The current text that's proposed allows the client to select the transport.
I think that's OK, but we just need to provide some additional guidance to
client writers.  Perhaps we even suggest that an indicator should be
provided to  the user so they will know if HTTPS was used to retrieve the
data.  But it would have to be ONLY HTTPS was used, as a promotion from HTTP
to HTTPS cannot be trusted.  The "visible trust" element is presently
missing.

Anyway, I think working through that language might be a good compromise.
Clients that need security will get it.  Clients that do not care may or may
not.  Providing a visual indicator to the user, where appropriate, might
help address the MITM attack concerns.

We just need to decide:

.         HTTPS only

.         Either HTTPS or HTTP (or both)

There are those firmly sitting on both sides and that's the problem.  We
need to just pick a direction and go with it.  Ironing out  the wording is
far less difficult than reaching agreement on the two choices.

Now to your plea to just get it done.  Here's what I suggest: how about we
just say HTTPS only and publish it.  Then, we could later introduce an HTTP
fallback option via a separate or updated RFC.  The issue with introducing
HTTP as an option now is the security complexity.  That's really holding us
up.  So, if we table that issue and just go with HTTPS for the moment, we at
least have a working solution that starts out as a secure solution.  We
could form a WG to hammer out how to soften the security requirements once
we get the HTTPS-only version out the door.  (There are other things I
believe we probably need to tackle as a part of that WG, such as definition
of properties, new "rel" values, etc.)

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 10:08 AM
To: [email-masked]
Subject: Possibly speeding up the RFC process

Webfinger is now in it's 4th year and I think everyone would agree that we
are keen to see it shipped

It seems to me that there are two value added use cases that have remained
constant from the start.

1) Lookup of a string of type user@host to produce a HTTP URL
2) Lookup of a string of type mailto:user@host to produce a HTTP URL

These are two things that would really be very useful, irrespective of all
the other benefits that webfinger has to offer.

We're perhaps at a point where both of these two cases have a solution.

So maybe it may be an idea to tidy up the current RFC in the WG and mark it
as informational in line with the following:

http://www.ietf.org/iesg/informational-vs-experimental.html

[[
An "Informational" specification is published for the general information of
the Internet community, and does not represent an Internet community
consensus or recommendation. The Informational designation is intended to
provide for the timely publication of a very broad range of responsible
informational documents from many sources, subject only to editorial
considerations and to verification that there has been adequate coordination
with the standards process
]]

I'm speculating here that this would get webfinger shipped more quickly.
Getting webfinger to IETF to recommendation level would appear to be a
greater task.  Perhaps adding months to the time line, and if i have
understood correctly there's no guarantee that an RFC will make it to
recommendation status.

Part of me wants webfinger to be the best spec it can be, and for quality to
be really high, yet another part would like to see webfinger actually
shipped asap, and to start using a stable form to complete the loop in
discovering more information from email via HTTP.  So, just putting the idea
out there.

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 16 Dec 2012 22:00:50 +0100

On 16 December 2012 21:23, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Going this route is not going to address the issues people have.  The
> draft is oh-so-very-close to completion. I think that folks are largely OK
> with the text, the procedures, and the data format.  There are still
> editorial matters, but nothing controversial.****
>
> ** **
>
> The only sticky issue is use of TLS or not.  But it’s a big one and we
> ought to get this right.****
>
> ** **
>
> queries for “[email-masked]” and a thief intercepts that
> information that the thief can use to empty the user’s bank accounts.****
>
> ** **
>
> why TLS must be mandated.****
>
> ** **
>
> Some clients are in the unfortunate position of not knowing whether
> security is or is not important for any given query.  Some clients know,
> though.  If I had software on my server that facilitates an OpenID login,
> it would know to use TLS only.  My email client, though, does not know how
> important security is.****
>
> ** **
>
> The current text that’s proposed allows the client to select the
> transport.   I think that’s OK, but we just need to provide some additional
> guidance to client writers.  Perhaps we even suggest that an indicator
> should be provided to  the user so they will know if HTTPS was used to
> retrieve the data.  But it would have to be ONLY HTTPS was used, as a
> promotion from HTTP to HTTPS cannot be trusted.  The “visible trust”
> element is presently missing.****
>
> ** **
>
> Clients that need security will get it.  Clients that do not care may or
> may not.  Providing a visual indicator to the user, where appropriate,
> might help address the MITM attack concerns.****
>
> ** **
>
> We just need to decide:****
>
> **·         **HTTPS only****
>
> **·         **Either HTTPS or HTTP (or both)****
>
> ** **
>
> There are those firmly sitting on both sides and that’s the problem.  We
> far less difficult than reaching agreement on the two choices.****
>
> ** **
>
> Now to your plea to just get it done.  *Here’s what I suggest*: how about
> we just say HTTPS only and publish it.  Then, we could later introduce an
> HTTP fallback option via a separate or updated RFC.  The issue with
> introducing HTTP as an option now is the security complexity.  That’s
> really holding us up.  So, if we table that issue and just go with HTTPS
> for the moment, we at least have a working solution that starts out as a
> secure solution.  We could form a WG to hammer out how to soften the
> security requirements once we get the HTTPS-only version out the door.
> (There are other things I believe we probably need to tackle as a part of
> that WG, such as definition of properties, new “rel” values, etc.)
>

Paul, thanks for the detailed response.

Re: the HTTP/HTTPS debate, I'm really supportive of whatever will allow
consensus to be reached fastest.  Today I ordered my StartSSL certificate,
so hopefully I can do my little bit too :)

However, that is not the greatest of the concerns that I have seen.  The
most serious critique I've seen to date is the thread form Mark Nottingham,
"Looking at Webfinger"

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06487.html

In particular:

[[

Astute observers will notice that this approach removes the need for an
ACCT URI scheme (at least here).

* What's the fascination with XRD and JRD? These specifications seem to be
creeping into IETF architecture; first it was in a pure security context,
but now folks are talking about using them in a much more generic way, as a
cornerstone of what we do. As such, I think they deserve a MUCH closer
look, especially since we're defining things with "Web" in their name when
the W3C has already defined solutions in this space.

]]

Mark Nottingham has a stellar reputation at the IETF, and these are some of
the more serious concerns raised to date, imho, and have yet to be fully
addressed.  And that may take some time to work through.

If perhaps going the "informational" route could save a significant amount
of time, say, 6 months or a year, do you think would it be worth
considering?

> ****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Melvin Carvalho
> *Sent:* Sunday, December 16, 2012 10:08 AM
> *To:* [email-masked]
> *Subject:* Possibly speeding up the RFC process****
>
> ** **
>
> So maybe it may be an idea to tidy up the current RFC in the WG and mark
> it as informational in line with the following:
>
> An "Informational" specification is published for the general information
> of the Internet community, and does not represent an Internet community
> considerations and to verification that there has been adequate
> coordination with the standards process
> ]]
>
> Part of me wants webfinger to be the best spec it can be, and for quality
> to be really high, yet another part would like to see webfinger actually
> discovering more information from email via HTTP.  So, just putting the
> idea out there.****
>

---

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

Melvin,

Most of those issues have been addressed.  We've divorced WF from Hostmeta.
XRD is no longer used.  We are using JRD, but I see no good reason to
exchange it.  It's six of one, half a dozen of anther when it comes to a
format like that.  JRD is clean and it has some nice properties about it
that allow us to do things like are shown in the examples.  I think the
biggest concern people had was the need to go read RFC 6415 or the XRD spec.
We've addressed that by documenting JRD entirely within the WF spec itself.

Paul

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Melvin Carvalho
Sent: Sunday, December 16, 2012 4:01 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

[snip]

In particular:

[[

Astute observers will notice that this approach removes the need for an ACCT
URI scheme (at least here). 

* What's the fascination with XRD and JRD? These specifications seem to be
creeping into IETF architecture; first it was in a pure security context,
but now folks are talking about using them in a much more generic way, as a
cornerstone of what we do. As such, I think they deserve a MUCH closer look,
especially since we're defining things with "Web" in their name when the W3C
has already defined solutions in this space.

]]

 

Paul

[[

[snip]

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 16 Dec 2012 22:37:44 +0100

On 16 December 2012 22:27, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Most of those issues have been addressed.  We’ve divorced WF from
> Hostmeta.  XRD is no longer used.  We are using JRD, but I see no good
> reason to exchange it.  It’s six of one, half a dozen of anther when it
> comes to a format like that.  JRD is clean and it has some nice properties
> about it that allow us to do things like are shown in the examples.  I
> think the biggest concern people had was the need to go read RFC 6415 or
> the XRD spec.  We’ve addressed that by documenting JRD entirely within the
> WF spec itself.
>

Yes, I did note that those changes were made, and I particularly like the
move from XML to JSON.

I could be mistaken, but I am unsure that that all of the concerns will
have been addressed to the satisfaction of the IESG.

The ones I noted:

- Should webfinger use the acct: scheme rather than simply a query
parameter.  This strikes me as a 'vanity' URI scheme.  Aesthetics are
important, but I'm unsure how popular a choice that will be with the IETF.

- JRD does not allow an array of items/subjects to be rendered in response
to an HTTP request, whereas other serializations do allow that.  This leads
to an interoperability issue.

- Concerns were raised over the IPR of XRD/JRD.  IANAL, but to the best of
my knowledge they are not creative commons, or royalty free under, say,
IETF / W3C / ISO.  This topic would be well outside my area of expertize,
but something the IETF may look at.

- Could webfinger be recommended as a best practice if the scope is
sufficiently wide, to overlap in areas where the W3C has already
standardized.  Namely those of discovery via http (aka linked data) etc.

I accept that some or all of these concerns may be invalid, but as
webfinger draws nearer to the standards track, perhaps it is possible that
more people upstream could weigh in.

> ****
>
> ** **
>
> Paul****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> *Sent:* Sunday, December 16, 2012 4:01 PM
> *Cc:* [email-masked]
> *Subject:* Re: [webfinger] Possibly speeding up the RFC process****
>
> ** **
>
> [snip]****
>
> Mark Nottingham has a stellar reputation at the IETF, and these are some
> of the more serious concerns raised to date, imho, and have yet to be fully
> idea out there. ****
> [snip]****

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 17:12:33 -0500

Melvin,

Comments are in inline:

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Sunday, December 16, 2012 4:38 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

Melvin,

I could be mistaken, but I am unsure that that all of the concerns will have
been addressed to the satisfaction of the IESG.

The ones I noted:

PEJ: WebFinger uses any URI scheme.  The "acct" scheme is just one of them
and is not core to the spec now, though there is a statement recommending
its use to identify accounts.  That is its purpose and the "acct" URI, and
it's a valid purpose.  The one example I like to give is "How do we identify
an account at Twitter?"  There is no email, so "mailto" is not the right
URI.  A user has an account at any service provider and the "acct" URI would
identify the account, not the particular service at the service provider
(e.g., email, XMPP, or whatever).

PEJ: I don't understand your concern. If I query my server, I get an array
of link relations. I can step through those sequentially to find what I'm
looking for.  If I want to arrange the data different, I could.  There was a
proposal, for example, to allow the "rel" value be the key that refers to an
array of possible values.  That works, but the issue is that we lose useful
constructs like "properties", "titles", etc., unless we have keys that point
to arrays of objects.  This can get syntactically ugly.  I personally like
the way JRD is defined: it's simple and clean.  It definitely does not
present interoperability issues.  An interop problem exists when two devices
implanting the same thing do it differently.  If you implement JRD, there is
no interop issue.  JRD is JRD as defined entirely in the WF spec. People
have been able to use it just fine so far.

- Concerns were raised over the IPR of XRD/JRD.  IANAL, but to the best of
my knowledge they are not creative commons, or royalty free under, say, IETF
/ W3C / ISO.  This topic would be well outside my area of expertize, but
something the IETF may look at.

PEJ: It has been said before that there were IPR claims on XRI.  I've never
heard an IPR claim on XRD, though.  And JRD is an entirely different syntax
defined within the IETF (Eran, specifically).  If there are IPR claims on
JRD, then it must have something to do with very high-level concepts for
which there would be no way to escape, such as the notion of defining a
"document" that contains "links" and "metadata" or something - like HTML.
Until an IPR statement is filed, I think we can ignore this.  Anything we
would consider might fall into the realm of somebody's IPR, so there's no
point worrying about it without solid evidence.

PEJ: I'm not sure what you are asking here.

Paul

I accept that some or all of these concerns may be invalid, but as webfinger
draws nearer to the standards track, perhaps it is possible that more people
upstream could weigh in.

Paul

[snip]

In particular:

[[

]]

 

Paul

[[

[snip]

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 16 Dec 2012 23:32:48 +0100

On 16 December 2012 23:12, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Comments are in inline:****
>
> ** **
>
> ** **
>
> *From:* Melvin Carvalho [mailto:[email-masked]]
> *Sent:* Sunday, December 16, 2012 4:38 PM
> *To:* Paul E. Jones
> *Cc:* [email-masked]; [email-masked]
>
> On 16 December 2012 22:27, Paul E. Jones <[email-masked]> wrote:***
> *
>
> Melvin,****
>
>  ****
>
> WF spec itself.****
> PEJ: WebFinger uses *any* URI scheme.  The “acct” scheme is just one of
> them and is not core to the spec now, though there is a statement
> recommending its use to identify accounts.  That is its purpose and the
> “acct” URI, and it’s a valid purpose.  The one example I like to give is
> “How do we identify an account at Twitter?”  There is no email, so “mailto”
> is not the right URI.  A user has an account at any service provider and
> the “acct” URI would identify the account, not the particular service at
> the service provider (e.g., email, XMPP, or whatever).
>

It's great that acct: is almost completely decoupled from the spec.

Sure I do understand why acct: would be useful.

But Mark and others pointed out you could equally use

webfinger?acct=bob

or

/.well-known/user/bob

my own suggestion from February was

/@/bob

None of the above are as beautiful as acct: but the debate may arise this
is worth creating a new uri scheme.

> to an interoperability issue.****
>
> ** **
>
> PEJ: I don’t understand your concern. If I query my server, I get an array
> of link relations. I can step through those sequentially to find what I’m
> looking for.  If I want to arrange the data different, I could.  There was
> a proposal, for example, to allow the “rel” value be the key that refers to
> an array of possible values.  That works, but the issue is that we lose
> useful constructs like “properties”, “titles”, etc., unless we have keys
> that point to arrays of objects.  This can get syntactically ugly.  I
> personally like the way JRD is defined: it’s simple and clean.  It
> definitely does not present interoperability issues.  An interop problem
> exists when two devices implanting the same thing do it differently.  If
> you implement JRD, there is no interop issue.  JRD is JRD as defined
> entirely in the WF spec. People have been able to use it just fine so far.
>

The link relations contain 3 components.   The subject, the predicate and
the object.  In other language the entity the attribute and the value.  The
Entity in this case would be @subject, the attribute would be the rel of
the link, and the value would be the value of the link.

In almost every serialization I know, multiple subjects/entities are
permissible, in an array of (say JSON) objects.  In JRD there is a
constraint limiting the serialization to exactly one entity/subject.  This
imho could be seen as a slight weakness, especially it it makes the
serialization of choice not 100% interoperable with others more permissible
serializations.

> but something the IETF may look at.****
>
> ** **
>
> PEJ: It has been said before that there were IPR claims on XRI.  I’ve
> never heard an IPR claim on XRD, though.  And JRD is an entirely different
> syntax defined within the IETF (Eran, specifically).  If there are IPR
> claims on JRD, then it must have something to do with very high-level
> concepts for which there would be no way to escape, such as the notion of
> defining a “document” that contains “links” and “metadata” or something –
> like HTML.  Until an IPR statement is filed, I think we can ignore this.
> Anything we would consider might fall into the realm of somebody’s IPR, so
> there’s no point worrying about it without solid evidence.
>

If JRD is completely under the IETF IPR, that would be extremely cool.  I
was unaware of that, if you have a pointer that would be great.

> standardized.  Namely those of discovery via http (aka linked data) etc.**
> **
>
> ** **
>
> PEJ: I’m not sure what you are asking here.
>

I think the point Mark was suggesting is that both webfinger and the w3c
'web stack' offer options for discovery.  Namely the W3C has spent much of
the last 10 years working on discovery based on HTTP identifiers.  If
webfinger becomes a general purpose discovery method for any URI, then
there is a possible overlap, which may perhaps lead to further discussion.

As you point out, it's just speculation at this point.  Tho my
understanding of the IETF process is that they do tend to drill down into
the details, so sometimes it doesnt hurt to be prepared, or have a plan B :)

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 16 Dec 2012 18:21:20 -0500

Melvin,

Comments inline again:

webfinger?acct=bob

or

/.well-known/user/bob

/@/bob

None of the above are as beautiful as acct: but the debate may arise this is
worth creating a new uri scheme.  

PEJ: Yeah, all of these are possibilities. The one thing that I personally
think is important is that the "thing" we query is a URI.  So, forms that do
not utilize URIs I think we should not consider.  There are several ways to
utilize URIs and  I think it comes down to putting the URI as a part of the
path or using a URI parameter.  We're presently heading down the latter
path.  The disadvantage is that one cannot build a "truly" static site,
though one can come close using Apache re-writing rules.  That said, there
is utility in the approach, since once can query for a specific URI and
request the response to be filtered for a particular set of link relations
("rel" parameters).  Thus, it's making the web programmable.  I think we're
past that debate now.  I hope so.

The link relations contain 3 components.   The subject, the predicate and
the object.  In other language the entity the attribute and the value.  The
Entity in this case would be @subject, the attribute would be the rel of the
link, and the value would be the value of the link.

PEJ: My understanding of subject is the "thing" I'm querying (e.g.,
acct:[email-masked]).  Given that definition, JRD covers a single
subject since WF is looking for a single "thing".  Inside, there may be
multiple "properties" for the "thing" (e.g., "http://packetizer.com/ns/name"
is a property with a value "Paul E. Jones).  Then there is an array of "link
relations".  The definition follows that of RFC 5988.  Each link relation is
identified by a "rel" value.  There is also an optional "type".  And there
is an "href".  JRD also allows for self-describing link relations, where the
"href" is absent and "properties" are used to describe the value of the
relation to the "rel".  An example is this:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3.
Lastly, any link may have one or more human-readable names in a "titles"
array.  You can see an example here: 

http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.

PEJ: I didn't say that, only that JRD was entirely documented in an IETF
document (RFC 6415).  The syntax was derived from XRD, though.  I'm just not
aware of any IPR claims on XRD, and whatever is claimed may or may not apply
to JRD (since it is a different syntax).  As I said, it would have to be a
pretty broad, generic claim.

I think the point Mark was suggesting is that both webfinger and the w3c
'web stack' offer options for discovery.  Namely the W3C has spent much of
the last 10 years working on discovery based on HTTP identifiers.  If
webfinger becomes a general purpose discovery method for any URI, then there
is a possible overlap, which may perhaps lead to further discussion.

PEJ: WebFinger is narrowly defined.  If there is another standard doing
exactly the same thing with the same level of simplicity, I think it would
have been adopted already.  There are certainly other kinds of "discovery"
protocols, but each that I have seen has a different scope, complexity,
value, etc. The support for WF has been pretty strong thus far.  I cannot
say it will be the recommended best practice, though.  We'll have to see
what the adoption rate looks like.

As you point out, it's just speculation at this point.  Tho my understanding
of the IETF process is that they do tend to drill down into the details, so
sometimes it doesnt hurt to be prepared, or have a plan B :)

PEJ: I'm too tired for a Plan B.  WebFinger started as a spec with a lot of
stuff inside and we've thrown out lots of options.  We're now down to this,
a product of several years' worth of work by multiple people.  Once we
settle on the HTTP/HTTPS issue, I hope we can say we're finished (modulo
less controversial editorial things).  There will be a review process, but I
would not expect that to result is significant technical changes.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Dec 2012 00:45:07 +0100

On 17 December 2012 00:21, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Comments inline again:****
>
> ** **
>
> ** **
>
> the service provider (e.g., email, XMPP, or whatever).****
>
>
> is worth creating a new uri scheme.  ****
>
> ** **
>
> think is important is that the “thing” we query is a URI.  So, forms that
> do not utilize URIs I think we should not consider.  There are several ways
> to utilize URIs and  I think it comes down to putting the URI as a part of
> the path or using a URI parameter.  We’re presently heading down the latter
> path.  The disadvantage is that one cannot build a “truly” static site,
> (“rel” parameters).  Thus, it’s making the web programmable.  I think we’re

Sure, but query parameters can take URIs too, SWD did, for example.

> serializations.****
> PEJ: My understanding of subject is the “thing” I’m querying (e.g.,
> subject since WF is looking for a single “thing”.  Inside, there may be
> multiple “properties” for the “thing” (e.g., “
> http://packetizer.com/ns/name” is a property with a value “Paul E.
> Jones).  Then there is an array of “link relations”.  The definition
> follows that of RFC 5988.  Each link relation is identified by a “rel”
> value.  There is also an optional “type”.  And there is an “href”.  JRD
> also allows for self-describing link relations, where the “href” is absent
> and “properties” are used to describe the value of the relation to the
> “rel”.  An example is this:
> Lastly, any link may have one or more human-readable names in a “titles”
> array.  You can see an example here: ****
>
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.1.***
> *
>
> ** **
>
>  ****
>
>
>
> there’s no point worrying about it without solid evidence.****
>
>
> was unaware of that, if you have a pointer that would be great.****
>
> ** **
>
> PEJ: I didn’t say that, only that JRD was entirely documented in an IETF
> document (RFC 6415).  The syntax was derived from XRD, though.  I’m just
> not aware of any IPR claims on XRD, and whatever is claimed may or may not
> apply to JRD (since it is a different syntax).  As I said, it would have to
> be a pretty broad, generic claim.
>

This is outside of my scope of expertize.  I couldnt really comment
further, tho others may.

> PEJ: I’m not sure what you are asking here.****
>
>
> have been adopted already.  There are certainly other kinds of “discovery”
> say it will be the recommended best practice, though.  We’ll have to see

Well linked data is adopted by many of the G7 govts., the world bank,
cities, fire deparments, 1000s of businesses, academia, search engines and
grass roots.

> PEJ: I’m too tired for a Plan B.  WebFinger started as a spec with a lot
> of stuff inside and we’ve thrown out lots of options.  We’re now down to
> this, a product of several years’ worth of work by multiple people.  Once
> we settle on the HTTP/HTTPS issue, I hope we can say we’re finished (modulo
> less controversial editorial things).  There will be a review process, but
> I would not expect that to result is significant technical changes.
>

Sure I appreciate the effort you've put in here.  I'm just saying, as per
my original post, that if there is pushback, it may be expedient to switch
to "informational" status, as it would seemingly not have a big impact on
implementers.  As I said, just an idea, let's see how the spec is received
after the HTTPS issue is resolved.

> Paul ****

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Dec 2012 13:22:26 +0100

On 17 December 2012 00:45, Melvin Carvalho <[email-masked]> wrote:

>> PEJ: Yeah, all of these are possibilities. The one thing that I
>> personally think is important is that the “thing” we query is a URI.  So,
>> forms that do not utilize URIs I think we should not consider.  There are
>> several ways to utilize URIs and  I think it comes down to putting the URI
>> as a part of the path or using a URI parameter.  We’re presently heading
>> down the latter path.  The disadvantage is that one cannot build a “truly”
>> static site, though one can come close using Apache re-writing rules.  That
>> said, there is utility in the approach, since once can query for a specific
>> URI and request the response to be filtered for a particular set of link
>> relations (“rel” parameters).  Thus, it’s making the web programmable.  I
>> think we’re past that debate now.  I hope so.
>>
>
>> - JRD does not allow an array of items/subjects to be rendered in
>> response to an HTTP request, whereas other serializations do allow that.
>> This leads to an interoperability issue.****
>>
>>  ****
>>
>> PEJ: I don’t understand your concern. If I query my server, I get an
>> array of link relations. I can step through those sequentially to find what
>> I’m looking for.  If I want to arrange the data different, I could.  There
>> was a proposal, for example, to allow the “rel” value be the key that
>> refers to an array of possible values.  That works, but the issue is that
>> we lose useful constructs like “properties”, “titles”, etc., unless we have
>> keys that point to arrays of objects.  This can get syntactically ugly.  I
Sorry forgot to respond to this point.  (only did the red ones :))

Thanks, I think I understand the JRD format and it's great that A) it's
JSON based and B) it can be self describing and C) that it can include
references (links) to other URIs

The weakness in this serialization is that it becomes tightly coupled to
the query that generated it.  A data document should be an entity in it's
own right that is independent of how it is generated.  What we are getting
is data, that happened to be delivered via webfinger.  While it is often
the case on the web that a document will yield a single subject, and indeed
in many cases this is a best practice, it is not always the case.  There
are many cases where there are multiple items in a single page, a good
example is wikipedia which divides itself up into many sections; the page
may be about Germany, then the sections could be about Geography, History,
Economy etc.  This leads to interoperability issues with the rest of the
web.

My view is that webfinger should be serialization agnostic and operate
using content negotiation.  JRD is one of the weaker serializations, imho,
and as mark has suggested, if favoured especially it will need greater
review, which may take time.  Im not sure anyone has ever answered the
question as to why has it been consistently favoured?

> ****
>>
>> ** **
>>
>>  ****
>>
>>
>>
>> - Concerns were raised over the IPR of XRD/JRD.  IANAL, but to the best
>> of my knowledge they are not creative commons, or royalty free under, say,
>> standardized.  Namely those of discovery via http (aka linked data) etc.*
>> ***
>>
>>  ****
>>

---

From: Nick Jennings <[email-masked]>
Date: Mon, 17 Dec 2012 15:16:38 +0100

On Sun, Dec 16, 2012 at 11:12 PM, Paul E. Jones <[email-masked]> wrote:
> PEJ: WebFinger uses any URI scheme.  The “acct” scheme is just one of them
> its use to identify accounts.  That is its purpose and the “acct” URI, and
> it’s a valid purpose.  The one example I like to give is “How do we identify
> an account at Twitter?”  There is no email, so “mailto” is not the right
> URI.  A user has an account at any service provider and the “acct” URI would

Hi Paul, I just wanted to run a few thoughts by you to make sure I'm
not missing something.

Maybe I don't fully understand the various use-cases, but it seems
like you are saying that when querying a 'resource', the value does
NOT need to be prefixed with acct (or anything). I know there's the
idea that at some point another type of resource could be identified
as relevant and so that was the argument for having the 'acct' prefix.
However your wording suggests that even 'acct' is not needed. So
someone's WF service could accept 'resource=bob' and not
'resource=acct:[email-masked]' and it would still be a compliant WF
service? If true, it seems like there could be a lot of room for
uncertainty in query format and client libraries would have to try a
number of different value formats.

Another thing, in regards to the twitter example you gave. What's to
differentiate a user of twitter and an employee of twitter?

There could be a user '@janice' and an employee [email-masked]',
who may be different people. As I understand it, in your example,
these different accounts would be queried in the same way.

/.host-meta/webfinger?resource=acct:[email-masked]

Am I misunderstanding? Or does this create a problem.
-Nick

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 17 Dec 2012 14:19:39 -0500

Melvin,

Comments below:

PEJ: My understanding of subject is the "thing" I'm querying (e.g.,
acct:[email-masked] <mailto:[email-masked]> ).  Given
that definition, JRD covers a single subject since WF is looking for a
single "thing".  Inside, there may be multiple "properties" for the "thing"
(e.g., "http://packetizer.com/ns/name" is a property with a value "Paul E.
Jones).  Then there is an array of "link relations".  The definition follows
that of RFC 5988.  Each link relation is identified by a "rel" value.  There
is also an optional "type".  And there is an "href".  JRD also allows for
self-describing link relations, where the "href" is absent and "properties"
are used to describe the value of the relation to the "rel".  An example is
this:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-07#section-4.3.
Lastly, any link may have one or more human-readable names in a "titles"
array.  You can see an example here: 

Thanks, I think I understand the JRD format and it's great that A) it's JSON
based and B) it can be self describing and C) that it can include references
(links) to other URIs

The weakness in this serialization is that it becomes tightly coupled to the
query that generated it.  A data document should be an entity in it's own
right that is independent of how it is generated.  What we are getting is
data, that happened to be delivered via webfinger.  While it is often the
case on the web that a document will yield a single subject, and indeed in
many cases this is a best practice, it is not always the case.  There are
many cases where there are multiple items in a single page, a good example
is wikipedia which divides itself up into many sections; the page may be
about Germany, then the sections could be about Geography, History, Economy
etc.  This leads to interoperability issues with the rest of the web.

My view is that webfinger should be serialization agnostic and operate using
content negotiation.  JRD is one of the weaker serializations, imho, and as
mark has suggested, if favoured especially it will need greater review,
which may take time.  Im not sure anyone has ever answered the question as
to why has it been consistently favoured?

PEJ: It is tightly coupled with the query, but  view that as positive.  JRD
has a limited use.  It's not HTML where we're creating elaborate documents.
It's a simple data structure that conveys link relations and properties
about a "subject".  If one wanted to have a more complex document that
included multiple "subjects", one could create an array or hash table of
JRDs.  Such use, though, is entirely outside the scope of WebFinger.  I do
like use of content negotiation.  Nothing precludes that from happening in
WF, either, since it is built on top of HTTP.  We're just not specifying
what would be negotiated.  The current text says:

WebFinger servers MUST return a JRD as the representation for the resource
if the client requests no format explicitly via the HTTP "Accept" header.  A
client MAY include the "Accept" header to indicate a desired representation,
though no other representation is defined in this specification.

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Dec 2012 20:44:17 +0100

On 17 December 2012 20:19, Paul E. Jones <[email-masked]> wrote:

> Comments below:****
> PEJ: It is tightly coupled with the query, but  view that as positive.
> JRD has a limited use.  It’s not HTML where we’re creating elaborate
> documents.  It’s a simple data structure that conveys link relations and
> properties about a “subject”.  If one wanted to have a more complex
> document that included multiple “subjects”, one could create an array or
> hash table of JRDs.  Such use, though, is entirely outside the scope of
> WebFinger.  I do like use of content negotiation.  Nothing precludes that
> from happening in WF, either, since it is built on top of HTTP.  We’re just
> not specifying what would be negotiated.  The current text says:
>

I dont know that much about JRD, but I'd just like to double check this
point.  Are you sure it is possible to create an array of JRDs?

My understanding was that in XRD this was forbidden.  If it's possible in
JRD, that would be a *major* plus, imho, because it would mean that at
least *theoretically* the default webfinger serialization is interoperable
with the rest of the web.

> if the client requests no format explicitly via the HTTP “Accept” header.
> A client MAY include the “Accept” header to indicate a desired
> representation, though no other representation is defined in this
> specification.****
>
> ** **
>
> ** **
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 17 Dec 2012 15:30:54 -0500

Nick,

> > PEJ: WebFinger uses any URI scheme.  The “acct” scheme is just one of
> > recommending its use to identify accounts.  That is its purpose and
> > the “acct” URI, and it’s a valid purpose.  The one example I like to
> > give is “How do we identify an account at Twitter?”  There is no
> > email, so “mailto” is not the right URI.  A user has an account at any
> > service provider and the “acct” URI would identify the account, not
> > the particular service at the service provider (e.g., email, XMPP, or
> whatever).
> >
> 
> Hi Paul, I just wanted to run a few thoughts by you to make sure I'm not
> missing something.
> 
> Maybe I don't fully understand the various use-cases, but it seems like
> you are saying that when querying a 'resource', the value does NOT need
> to be prefixed with acct (or anything). I know there's the idea that at
> some point another type of resource could be identified as relevant and
> so that was the argument for having the 'acct' prefix.

What the spec says is that any URI may be queried.  That's what I meant.  The protocol is not designed to be used only with "acct:".  One may query WF using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" or "urn:".  Obviously, URI schemes that do not have domain names present issues, but that it's certainly possible and I suspect there would be an agreed client/server relationship.

My own server code actually will accept just "[email-masked]", for example.  If it sees that, it assumes the requestor wants "acct:[email-masked]" and returns the results from the database for the "acct:" URI.  However, the "subject" is just the bare "[email-masked]" and the "acct:" URI is inserted into the response as an alias.  However, none of that is in the spec.  I did that long ago, because Blaine preferred to not require a URI scheme for user@domain forms.

> who may be different people. As I understand it, in your example, these
> different accounts would be queried in the same way.
>

Users and employees must have different <user> values within the scope of the domain (or sub-domain).  Some time ago, somebody mentioned that they have a domain with user accounts and employees where the user account names did clash with employee names.  I don't have a solution for that.  Personally, I think that's an unfortunate situation to be in.

On my own web site, I run phpBB.  There are user accounts.  So, I can appreciate how people get into that situation.  However, I placed the discussion forms at forums.packetizer.com and so if the phpBB software ever supported WebFinger (hmmmm... more holiday coding opportunities) then I would expect it to respond only to acct:<user>@forums.packetizer.com.  That would be perfectly fine and would avoid the name clash.  WF does not require queries only to the domain.  Queries can be sent to any appropriate host within the domain.

> Am I misunderstanding? Or does this create a problem.

There are potential issues for domain owners who have allocated the same user identifier to more than one person on the same domain or sub-domain.  Domain owners will have to address that before deploying WF.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 17 Dec 2012 16:04:18 -0500

Melvin,

The JRD spec itself (and I've extracted it out and placed it here for
convenience: http://www.packetizer.com/json/jrd/) does not define creating
an array of itself.

However, programmatically it would be trivial to create an array of JRD
objects in virtually any language.  WebFinger only deals with a single
"subject" at a time.  So, the data returned from the server does not need to
have multiple sections with a "subject" per section.  However, since the
"subject" is an element within the JRD, then you can imagine a JSON object
like this:

{ "jrds" : [ { <jrd1> }, { <jrd2> }, { ... } ] }

or

{ "<jrd subject 1>" : { <jrd 1 }, "<jrd subject 2>", { <jrd 2> }, ... }

Neither are defined, but you can see how JRDs could be used within more
complex documents.

Paul

My understanding was that in XRD this was forbidden.  If it's possible in
JRD, that would be a *major* plus, imho, because it would mean that at least
*theoretically* the default webfinger serialization is interoperable with
the rest of the web.

---

From: Melvin Carvalho <[email-masked]>
Date: Mon, 17 Dec 2012 22:36:24 +0100

On 17 December 2012 22:04, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> The JRD spec itself (and I’ve extracted it out and placed it here for
> convenience: http://www.packetizer.com/json/jrd/) does not define
> creating an array of itself.****
>
> ** **
>
> “subject” at a time.  So, the data returned from the server does not need
> to have multiple sections with a “subject” per section.  However, since the
> “subject” is an element within the JRD, then you can imagine a JSON object
> like this:****
>
> ** **
>
> { “jrds” : [ { <jrd1> }, { <jrd2> }, { ... } ] }****
>
> ** **
>
> or****
>
> ** **
>
> { “<jrd subject 1>” : { <jrd 1 }, “<jrd subject 2>”, { <jrd 2> }, ... }***
> *
>
> ** **
>

Sounds great

I think all you would need to do is

[
  { JRD1 },
  { JRD2 },
  { JRD3 }
]

See Example 51 from :

http://json-ld.org/spec/latest/json-ld-syntax/

The reason that I asked is that the XML Schema or XRD strictly forbids more
than one object.  I do not know the rationale for this, because other
serializations definitely allow multiple.

If JRD can do this, that's a big plus.  Thanks for extracting the spec.  Do
you know who maintains JRD currently?

> not specifying what would be negotiated.  The current text says:****
>
>
> with the rest of the web. ****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 18 Dec 2012 02:01:21 -0500

Melvin,

Yep, that syntax will work just fine if you want an array.  I was thinking
only about object syntax.

In any case, the JRD syntax is documented in the current WF spec.  That's
where it will be cast into stone and I don't expect any need for making
changes to it once we're finished.  We ought not add more complexity to it
than is already defined.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Monday, December 17, 2012 4:36 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

Melvin,

or

Sounds great

[
  { JRD1 },
  { JRD2 },
  { JRD3 }
]

See Example 51 from :

 

Paul

---

From: Nick Jennings <[email-masked]>
Date: Tue, 18 Dec 2012 20:36:30 +0100

> There are potential issues for domain owners who have allocated the same user identifier to more than one person on the same domain or sub-domain.  Domain owners will have to address that before de…

Hi Paul,

I've been giving this some more thought, if the person running the WF
service can make up their own system of identifying users (whatever
works for them), then in order to write a robust WF client, you're
going to have to do a lot of second guessing. I don't understand why
we have 'acct:' if (a) it's not required at all, and (b) it's
suggested we use the full [email-masked]'  anyway, however (c) we
also don't have to do that...

In the case of that twitter example. If they wanted to solve this
issue, they might impose a system like:

/.host-meta/webfinger?resource=[email-masked]

...that gets the record for the employee Janice

/.host-meta/webfinger?resource=acct:janice

...that gets the record for the user-account 'janice'

In this case 'acct' prefix referring to just the 'webapp' accounts,
and not 'admin/employee' accounts.

I think a clarification of what to use as the resource value to
signify whether we are, querying an email address (used by, for
example, and email client, or blog comments). or a user account (used
by, for example, phpBB, wordpress, twitter, etc.) would be really
helpful.

Otherwise we're going to have similar client complexity to the issues
we've already discussed regarding using fallback methods. though maybe
more complicated because we could have false positives if, for
example, [email-masked] is queried for a user account but the
profile for the employee is returned.

Does anyone else see the ambiguity here as a potentially pretty bad problem?
-nick

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 18 Dec 2012 23:19:56 +0100

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per conto
> di Nick Jennings
> Inviato: martedì 18 dicembre 2012 20.37
> A: Paul E. Jones
> Cc: [email-masked]; [email-masked]; Melvin Carvalho
> Oggetto: Re: [webfinger] Possibly speeding up the RFC process
>
> > What the spec says is that any URI may be queried.  That's what I meant.
> The protocol is not designed to be used only with "acct:".  One may query WF
> using "http:" (e.g., "http://www.paulej.com/") or "mailto:" or "tel:" or
> "urn:".  Obviously, URI schemes that do not have domain names present issues,
> but that it's certainly possible and I suspect there would be an agreed
> client/server relationship.
> >
> > My own server code actually will accept just "[email-masked]", for
> example.  If it sees that, it assumes the requestor wants
> "acct:[email-masked]" and returns the results from the database for the
> "acct:" URI.  However, the "subject" is just the bare "[email-masked]"
> and the "acct:" URI is inserted into the response as an alias.  However, none
> of that is in the spec.  I did that long ago, because Blaine preferred to not
> require a URI scheme for user@domain forms.
> >
> > Users and employees must have different <user> values within the scope of
> the domain (or sub-domain).  Some time ago, somebody mentioned that they have
> a domain with user accounts and employees where the user account names did
> clash with employee names.  I don't have a solution for that.  Personally, I
> think that's an unfortunate situation to be in.
> >
> > On my own web site, I run phpBB.  There are user accounts.  So, I can
> appreciate how people get into that situation.  However, I placed the
> discussion forms at forums.packetizer.com and so if the phpBB software ever
> supported WebFinger (hmmmm... more holiday coding opportunities) then I would
> expect it to respond only to acct:<user>@forums.packetizer.com.  That would be
> perfectly fine and would avoid the name clash.  WF does not require queries
> only to the domain.  Queries can be sent to any appropriate host within the
> domain.
> >
> > There are potential issues for domain owners who have allocated the same
> user identifier to more than one person on the same domain or sub-domain.
> Domain owners will have to address that before deploying WF.
> >
>
> Hi Paul,
>

I personally don't see the issue here. Facebook uses different domains for their users vs their employess. It's unfortunate if titter do not does this but i twas said many times in the past on this list that acct: addresses with the same value than mailto: addresses may actually not be related to the same person. (although it would make sense, technically there is no binding for this).
I wouldn't enter the debate of who's represented behind a specific URI. It is up to the domain admin to manage the account namespace. Could you better clarify your issue here?

Re the acct: URI scheme I do support Paul's view that at this stage there is no URI-way of identifying *user accounts* globally. It is already widely used in federated social networks that will become a big consumer of webfinger eventually and could easily reuse these "acct:" URIs in activity streams in the actor/id field (normatively defined as anyURI).

Third, wf was designed for supporting any URI including for example http:, which are not in the form of user@domain. And in general I would recommend that an ietf spec formally define the "resource" parameter as anyURI instead of a free-form string.

walter

> -nick

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.

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 19 Dec 2012 03:10:12 +0100

On 18 December 2012 23:19, Goix Laurent Walter <
[email-masked]> wrote:

> not
> like
> these
> I personally don't see the issue here. Facebook uses different domains for
> their users vs their employess. It's unfortunate if titter do not does this
> but i twas said many times in the past on this list that acct: addresses
> with the same value than mailto: addresses may actually not be related to
> the same person. (although it would make sense, technically there is no
> binding for this).
> I wouldn't enter the debate of who's represented behind a specific URI. It
> is up to the domain admin to manage the account namespace. Could you better
> clarify your issue here?
>
> Re the acct: URI scheme I do support Paul's view that at this stage there
> is no URI-way of identifying *user accounts* globally. It is already widely
> used in federated social networks that will become a big consumer of
> webfinger eventually and could easily reuse these "acct:" URIs in activity
> streams in the actor/id field (normatively defined as anyURI).
>
> Third, wf was designed for supporting any URI including for example http:,
> which are not in the form of user@domain. And in general I would
> recommend that an ietf spec formally define the "resource" parameter as
> anyURI instead of a free-form string.
>

Taking your example of http:, how might this work?

>
> walter
>
> > -nick
>
> 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.
>
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 18 Dec 2012 23:39:50 -0500

Nick,

> works for them), then in order to write a robust WF client, you're going
> to have to do a lot of second guessing. I don't understand why we have
> 'acct:' if (a) it's not required at all, and (b) it's suggested we use
> the full [email-masked]'  anyway, however (c) we also don't have to
> do that...

(a) It's not required, but I think most people will use it.  This refers to a user's account, where other URIs refer to web pages, devices, phone numbers, other addressable things on the Internet
(b) The user@domain for will be present with acct:, but not with http:  The "resource" being queried is a URI, this we need URI syntax
(c) I don't understand (c)

> In the case of that twitter example. If they wanted to solve this issue,
> they might impose a system like:
> 
> In this case 'acct' prefix referring to just the 'webapp' accounts, and
> not 'admin/employee' accounts.

That does not make it any clearer to me and I would never encourage that kind of behavior.  I think it's OK to assume "user@domain" is "acct:user@domain", much like people typing www.example.com into their browsers, the browsers assume the users meant "http://" at the front.

But I would suggest that no URI prefix (which is not even valid, anyway) is somehow different than "acct:".  I would either treat them as equal on the server or reject the plain "user@domain" form that lacks the URI scheme.  The client is supposed to ensure requests have a URI scheme.

Now, before you say "I thought you said the 'acct:' scheme was not required."  It's not, but that's the recommended scheme for account identifiers.  WF provides a response to queries for URIs.  Any URI can be used.  We just recommend "acct:" for accounts, but "http:" is perfectly valid if requesting information about an HTTP URL.
 
> I think a clarification of what to use as the resource value to signify
> whether we are, querying an email address (used by, for example, and
> email client, or blog comments). or a user account (used by, for example,
> phpBB, wordpress, twitter, etc.) would be really helpful.

We have language in the draft now that makes a recommendation on what to use.  The "acct" scheme is recommended when querying for a user's account.
 
> more complicated because we could have false positives if, for example,
> [email-masked] is queried for a user account but the profile for the
> employee is returned.

I'd prefer to not document bare "user@domain" forms since the resource parameter is always supposed to refer to a URI.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 18 Dec 2012 23:58:44 -0500

Melvin,

Here’s an example:

  curl
'https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer
.com/'

This does not return much useful information, but I return a user-friendly
“Name” for the URI.  I could include a URL to a site policy document, have a
link relation to a copyright statement, etc.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Tuesday, December 18, 2012 9:10 PM
To: Goix Laurent Walter
Cc: [email-masked]; Paul E. Jones; [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

not
> >> 'resource=acct:[email-masked] <mailto:[email-masked]> ' and it
would still be a compliant WF
> "acct:[email-masked] <mailto:[email-masked]> " and
returns the results from the database for the
> >> /.host-meta/webfinger?resource=acct:[email-masked]
<mailto:[email-masked]> 

Re the acct: URI scheme I do support Paul's view that at this stage there is
no URI-way of identifying *user accounts* globally. It is already widely
used in federated social networks that will become a big consumer of
webfinger eventually and could easily reuse these "acct:" URIs in activity
streams in the actor/id field (normatively defined as anyURI).

Third, wf was designed for supporting any URI including for example http:,
which are not in the form of user@domain. And in general I would recommend
that an ietf spec formally define the "resource" parameter as anyURI instead
of a free-form string.

walter

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.

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 19 Dec 2012 14:43:29 +0100

On 19 December 2012 05:58, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Here’s an example:****
>
> ** **
>
>   curl '
> https://packetizer.com/.well-known/webfinger?resource=http://www.packetizer.com/
> '****
>
> ** **
>
> “Name” for the URI.  I could include a URL to a site policy document, have
> a link relation to a copyright statement, etc.
>

I see what you are doing here and it's a neat implementation.  I think that
if http discovery is in scope of webfinger, then data returned should be
consistent with HTTP GET, which is currently the best practice for http
discovery, imho.  Otherwise there is the potential danger, for things
getting out of sync, depending on which discovery method is used.

Does that make sense?

> *Sent:* Tuesday, December 18, 2012 9:10 PM
> *To:* Goix Laurent Walter
> *Cc:* [email-masked]; Paul E. Jones; [email-masked]
> [email-masked]> wrote:****
>
> > Oggetto: Re: [webfinger] Possibly speeding up the RFC process****
>
> >
> > Does anyone else see the ambiguity here as a potentially pretty bad
> problem?****
>
> anyURI instead of a free-form string.****
>
>
> advise the sender by return e-mail, Thanks.****
>
> ** **
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 19 Dec 2012 10:42:19 -0500

Melvin,

Honestly, I don't follow exactly what you're saying.  WF allows any URI,
this this form is allowed.  What the server chooses to include in the
response is not specified.  The concept here is not new.  This was also
possible in RFC 6415 (host-meta & LRDD).  But, how that relates to "HTTP
GET", I do not know.  Are you referring to mark-up in an HTML document?  If
so, it's impossible to ensure consistency in all cases, since many HTTP
resources return non-HTML content.  In any case, this is really a subject
that should be outside the scope of WF.  WF defines how to convey
information.  We should not get into comparison between "HTTP GET" discovery
mechanisms.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2012 8:43 AM
To: Paul E. Jones
Cc: Goix Laurent Walter; [email-masked]; [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

Melvin,

Here's an example:

  curl

This does not return much useful information, but I return a user-friendly
"Name" for the URI.  I could include a URL to a site policy document, have a
link relation to a copyright statement, etc.

Does that make sense?

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 19 Dec 2012 18:25:58 +0100

On 19 December 2012 16:42, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> Honestly, I don’t follow exactly what you’re saying.  WF allows *any*URI, this this form is allowed.  What the server chooses to include in the
> possible in RFC 6415 (host-meta & LRDD).  But, how that relates to “HTTP
> GET”, I do not know.  Are you referring to mark-up in an HTML document?  If
> information.  We should not get into comparison between “HTTP GET”
> discovery mechanisms.
>

HTTP is not strictly coupled to HTML, HTML is simply one MIME type.  GET
can return HTML, images, audio, XML, JSON etc.  Many of the serializations
contain data points either in the header, or in the payload.  This year,
embedding data in html documents (as well as headers) has achieved REC
status and has had significant deployment (25%-50% of the web).  As such
this is a form of 'follow your nose discovery'.  There is a large body of
work at the W3C and other places, that have covered HTTP based discovery in
great detail, with 100s if man years worth of standardization.

I could be mistaken, but if it is in scope that webfinger includes http,
the overlap with existing methods of discovery may be sensible as part of
standardization, to ensure compatibility across the whole internet.

> *Sent:* Wednesday, December 19, 2012 8:43 AM
> *To:* Paul E. Jones
> *Cc:* Goix Laurent Walter; [email-masked]; [email-masked]
>
> On 19 December 2012 05:58, Paul E. Jones <[email-masked]> wrote:***
> *
>
> Melvin,****
>
>  ****
>
> Here’s an example:****
>
>  ****
>
>   curl '
> a link relation to a copyright statement, etc.****
>
>
> I see what you are doing here and it's a neat implementation.  I think
> that if http discovery is in scope of webfinger, then data returned should
> be consistent with HTTP GET, which is currently the best practice for http

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 19 Dec 2012 15:22:11 -0500

Melvin,

OK, I do understand a little better.

WF does allow any URI, but does not go into detail about what information is
returned when a client queries using a particular URI scheme as the resource
parameter.  One could make the argument that "http" ought not be used.  One
could also make the argument that there should be consistency between what
WF returns for an "http" URI and what kind of metadata is returned when
simply querying the resource should be consistent.

However, I don't think that should be included in the WF spec itself.  Just
as we're going to be defining link relations, properties, perhaps methods
for auto-provisioning, etc., this is a good subject to take up as a
follow-on activity or even an activity in the W3C.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2012 12:26 PM
To: Paul E. Jones
Cc: Goix Laurent Walter; [email-masked]; [email-masked]
Subject: Re: [webfinger] Possibly speeding up the RFC process

Melvin,

HTTP is not strictly coupled to HTML, HTML is simply one MIME type.  GET can
return HTML, images, audio, XML, JSON etc.  Many of the serializations
contain data points either in the header, or in the payload.  This year,
embedding data in html documents (as well as headers) has achieved REC
status and has had significant deployment (25%-50% of the web).  As such
this is a form of 'follow your nose discovery'.  There is a large body of
work at the W3C and other places, that have covered HTTP based discovery in
great detail, with 100s if man years worth of standardization.

I could be mistaken, but if it is in scope that webfinger includes http, the
overlap with existing methods of discovery may be sensible as part of
standardization, to ensure compatibility across the whole internet.  

Paul

 

Melvin,

Here's an example:

  curl

Does that make sense?

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 19 Dec 2012 21:41:00 +0100

On 19 December 2012 21:22, Paul E. Jones <[email-masked]> wrote:

> Melvin,****
>
> ** **
>
> OK, I do understand a little better.****
>
> ** **
>
> WF does allow any URI, but does not go into detail about what information
> is returned when a client queries using a particular URI scheme as the
> resource parameter.  One could make the argument that “http” ought not be
> used.  One could also make the argument that there should be consistency
> between what WF returns for an “http” URI and what kind of metadata is
> returned when simply querying the resource should be consistent.****
>
> ** **
>
> However, I don’t think that should be included in the WF spec itself.
> Just as we’re going to be defining link relations, properties, perhaps
> methods for auto-provisioning, etc., this is a good subject to take up as a

+1

> *Sent:* Wednesday, December 19, 2012 12:26 PM
>
> *To:* Paul E. Jones
> On 19 December 2012 16:42, Paul E. Jones <[email-masked]> wrote:***
> *
>
> Melvin,****
>
>  ****
>
> discovery mechanisms.****
>
>
> *Cc:* Goix Laurent Walter; [email-masked]; [email-masked]*
> ***
>
>
> Does that make sense?****
>
> ** **
>

---

From: Nick Jennings <[email-masked]>
Date: Thu, 20 Dec 2012 17:25:04 +0100

> Third, wf was designed for supporting any URI including for example http:, which are not in the form of user@domain. And in general I would recommend that an ietf spec formally define the "resource…

Hi Walter and Paul,

I don't want to beat a dead horse, but so far I feel like either I'm
missing something pretty major, or I'm not making myself clear. So
I'll give it another shot:

My concern is that there seems to me to be a BIG ambiguity problem
which could create false positives during lookups, and different
conventions could be made up by sites with emails & web accounts on
the same server, that might require a WF client to use several
different URIs to find a record (and there's not 100% sure way of
knowing they got the right record).

If there is a WF client in a mail-app, it's going to want to query
against the email address. Not a website account. So, IMO there needs
to be a way to specify you are querying for an email address, what
that method is, I don't know, but the ambiguity of 'acct' is
problematic for a client library that knows exactly what it's talking
about (an email address).

/.host-meta/webfinger?resource=mailto:[email-masked]

This would make it clear to the server "I got an *email address* and
would like any record associated with it.

Whereas:

/.host-meta/webfinger?resource=acct:[email-masked]

OR

/.host-meta/webfinger?resource=http://example.com/users/user

Would make it clear that you are querying 'user' from the sites user
accounts. This could be the way of implying "whatever service you
host, I need a record for a user of this name". If the WF server was
an email server, then it could be one in the same as a
mailto:[email-masked] URI and the result would be the same no matter
what. However if it's twitter (for example) or some other web service
with accounts, it would know you mean the account 'user' of that web
service.

My point is that the context is only really going to be known by the
client, and it will have no way of knowing if the result it got was
for the right account because it has no way of being specific. IMO
this is trivial to implement on the server side (by default, mailto
and acct would be one in the same, but you could split the two if you
needed) and would make things easy to clarify by the client when
needed.

-Nick

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 20 Dec 2012 12:20:44 -0500

Nick,

> missing something pretty major, or I'm not making myself clear. So I'll
> give it another shot:
> 
> My concern is that there seems to me to be a BIG ambiguity problem which
> could create false positives during lookups, and different conventions
> could be made up by sites with emails & web accounts on the same server,
> that might require a WF client to use several different URIs to find a
> record (and there's not 100% sure way of knowing they got the right
> record).

That's what section 5.4 (next version will be 4.4) deal with.  It is recommended that we use the acct: URI when looking up information about users if we're trying to find out something about their account.

It goes on to say that mailto is not ideal for user accounts, but would be useful for mail server configuration.  If you want to see live examples of the difference, see:

curl https://packetizer.com/.well-known/webfinger?
                            resource=acct:[email-masked]

vs.

curl https://packetizer.com/.well-known/webfinger?
                            resource=mailto:[email-masked]

The latter provides information about how my email client should provision itself.
 
> against the email address. Not a website account. So, IMO there needs to
> be a way to specify you are querying for an email address, what that
> method is, I don't know, but the ambiguity of 'acct' is problematic for
> a client library that knows exactly what it's talking about (an email
> address).
> 

Yes, that's what is intended.
 
> accounts. This could be the way of implying "whatever service you host,
> I need a record for a user of this name". If the WF server was an email
> server, then it could be one in the same as a mailto:[email-masked]
> URI and the result would be the same no matter what. However if it's
> twitter (for example) or some other web service with accounts, it would
> know you mean the account 'user' of that web service.

If I were writing a client and saw an email address "[email-masked]", I would assume the associated account URI is acct:[email-masked].  Personally, I think that is a reasonable thing to do.

For a lot of reasons, I think having different user identifiers at the same domain level is a bad idea and I don't know how people will deal with that.  They should not do that, really.  People search for people using these identifiers.  It's an issue that extends beyond just WF.  Call it a part of "good domain hygiene".
 
> client, and it will have no way of knowing if the result it got was for
> the right account because it has no way of being specific. IMO this is
> trivial to implement on the server side (by default, mailto and acct
> would be one in the same, but you could split the two if you
> needed) and would make things easy to clarify by the client when needed.

It would certainly be legitimate to have acct: and mailto: return the same set of link relations.  A client would likely be looking for only certain "rel" values, anyway.  However, I personally like to split them, since they serve an entirely different purpose. If my XMPP client was looking for how to configure itself, for example, I would expect it to query like this:

curl https://packetizer.com/.well-known/webfinger?
                            resource=xmpp:[email-masked]

That will return a different set of results.  There is only minimal information there, since we have not actually defined the auto-provisioning stuff.  Again, this could all be returned as part of a query to acct:, but I personally like the split.  It could also be possible that each of these URIs (acct:, mailto:, or xmpp:) are just aliases of each other and, regardless of what the client queries, it gets the same JRD.

What I cannot fix are domains that have two people associated with a given user identifier.

Paul

---

From: Nick Jennings <[email-masked]>
Date: Thu, 20 Dec 2012 18:33:06 +0100

Thanks for your patience Paul :) that cleared things up!
 On Dec 20, 2012 6:20 PM, "Paul E. Jones" <[email-masked]> wrote:

> That's what section 5.4 (next version will be 4.4) deal with.  It is
> recommended that we use the acct: URI when looking up information about
> users if we're trying to find out something about their account.
>
> It goes on to say that mailto is not ideal for user accounts, but would be
> useful for mail server configuration.  If you want to see live examples of
> the difference, see:
>
> If I were writing a client and saw an email address "[email-masked]",
> I would assume the associated account URI is acct:[email-masked].
>  Personally, I think that is a reasonable thing to do.
>
> For a lot of reasons, I think having different user identifiers at the
> same domain level is a bad idea and I don't know how people will deal with
> that.  They should not do that, really.  People search for people using
> these identifiers.  It's an issue that extends beyond just WF.  Call it a
> part of "good domain hygiene".
>
> It would certainly be legitimate to have acct: and mailto: return the
> same set of link relations.  A client would likely be looking for only
> certain "rel" values, anyway.  However, I personally like to split them,
> since they serve an entirely different purpose. If my XMPP client was
> looking for how to configure itself, for example, I would expect it to
> query like this:
>
> That will return a different set of results.  There is only minimal
> information there, since we have not actually defined the auto-provisioning
> stuff.  Again, this could all be returned as part of a query to acct:, but
> I personally like the split.  It could also be possible that each of these
> URIs (acct:, mailto:, or xmpp:) are just aliases of each other and,
> regardless of what the client queries, it gets the same JRD.
>

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 20 Dec 2012 18:35:30 +0100

Hello nick,

Thank you indeed for rewording. My comments inline.
> would like any record associated with it.

Exactly. And this is a first very concrete and valid use case.
> host, I need a record for a user of this name".
Not really "whatever" but truly specific to the uri that was queried. The server will decide what to return based in the uri in input. The output could be the same for both or not. The acct: uri is just another scheme to fill a gap of representing those accounts that cannot be yet represented through a uri. It may be valid in some contexts (eg social networks) but not in others. As you said the client inserts the uri and de-facto solves the ambiguity. Now, *if* a client library is open itself to ambiguity in authorizing an app to insert a simple token say user@domain, then the client is buggy. it may decide the scheme to prepend before issuing the query and "Acct:" could probably make sense as a default, but it may not be always the case. An email app would probably always use mailto: when invoking a client library for example to avoid these ambiguities.

> If the WF server was
> for the right account because it has no way of being specific.
The app, when invoking the client library, should provide the target uri which scheme will tell the server the "context" i.e. what is truly requested. I don't see any ambiguity here.

> IMO
I'm not sure I understand what is trivial to implement. Or if it is how to handle different uri schemes for the same user@domain then I agree it is trivial...and unambiguous :)

Walter

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 20 Dec 2012 18:41:19 +0100

Paul,

> If I were writing a client and saw an email address "[email-masked]", I would assume the associated account URI is acct:[email-masked].  Personally, I think that is a reasonable thing to do.

I would rather expect that natively the email client queries for mailto: as this is the real identifier it knows of (the ones used in emails) and converting it into acct: is just a best guess. The target server should surely knows that mailto: identifier since an email was probably received from that id, whilst the corresponding acct: identifier may not exist. Does this make sense?

Walter

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 20 Dec 2012 12:56:39 -0500

Walter,

> > If I were writing a client and saw an email address
> "[email-masked]", I would assume the associated account URI is
> acct:[email-masked].  Personally, I think that is a reasonable
> thing to do.
> 
> I would rather expect that natively the email client queries for mailto:
> as this is the real identifier it knows of (the ones used in emails) and
> converting it into acct: is just a best guess. The target server should
> surely knows that mailto: identifier since an email was probably
> received from that id, whilst the corresponding acct: identifier may not
> exist. Does this make sense?

Yes, which is one of the reasons I had previously proposed introducing the "acct" link relation.  Given a known URI like "mailto:[email-masked]", the client could query the server like this:

I just added that to my database so you can see what it would look like:

That said, I think a "best guess" is actually pretty reasonable.  Consider that the email client actually NEVER gets a "mailto:[email-masked]" from the SMTP server.  Rather, it gets this:

  From: "Paul E. Jones" <[email-masked]>

This is an email address, but I would argue that it should be safe to assume that acct:[email-masked] will identify the user's account (vs. his email-related configuration information or whatever).

So, as a way forward, we have a couple of options:
    1) Allow the assumption to be made that the account for
       the above address is "acct:"
    2) Don't allow the assumption and require a query to
       "mailto" and discover the "acct" URI

Paul

---

From: Goix Laurent Walter <[email-masked]>
Date: Thu, 20 Dec 2012 19:04:43 +0100

>       "mailto" and discover the "acct" URI

I am not sure we have to standardize that specific behaviour. It would be impossible to do for all use cases with a normative language. That said it could be clearly mentioned in the examples to guide implementors.
My preferred option for the example would be with mailto: (optionally mentioning that the answer could provide a proof of existence of the equivalent acct: uri through an acct rel.

Walter

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 20 Dec 2012 13:10:53 -0500

Walter,

> I am not sure we have to standardize that specific behaviour. It would
> be impossible to do for all use cases with a normative language. That
> said it could be clearly mentioned in the examples to guide implementors.
> My preferred option for the example would be with mailto: (optionally
> mentioning that the answer could provide a proof of existence of the
> equivalent acct: uri through an acct rel.

My preference is that we leave the examples we have in the text as they are and encourage use of the "acct" URI if a query relates to a user's account.  Concrete recommendations might also come about through a little more real-world experience.  I suspect the first major service provider to support WF will dictate how it works.

Paul