FW: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt

[Paul E. Jones]

Folks,

I just posted a revised version of the WebFinger text. Highlights include:
* Change all queries to require HTTPS only
* Forbid server redirection to HTTP URIs
* Merged the "Introduction" and "Overview" sections
* Moved some references to the informative references section
* Removed instructions for the server to return specific
status codes (Tim successfully argued it was not needed)
* Retained one statement, though, in section 4.2 that
requires a server to return a 400. However, the
text was changed to refer to behavior in RFC 2616.
Same end result, though.
* Moved section the "rel" parameter section before the
JRD section.
* Made edits to the JRD section as discussed on the list
* Various editorial changes

Please have a look at this text and suggest any changes we should make.

Paul

> -----Original Message-----
> From: apps-discu...@ietf.org [mailto:apps-discuss-
> bou...@ietf.org] On Behalf Of interne...@ietf.org
> Sent: Friday, December 21, 2012 12:21 PM
> To: i-d-an...@ietf.org
> Cc: apps-d...@ietf.org
> Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-webfinger-08.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Applications Area Working Group
> Working Group of the IETF.
>
> Title : WebFinger
> Author(s) : Paul E. Jones
> Gonzalo Salgueiro
> Joseph Smarr
> Filename : draft-ietf-appsawg-webfinger-08.txt
> Pages : 20
> Date : 2012-12-21
>
> Abstract:
> This specification defines the WebFinger protocol, which can be used
> to discover information about people or other entities on the
> Internet using standard HTTP methods.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-08
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-d...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

[Kingsley Idehen]

> _______________________________________________
> webfinger mailing list
> webf...@ietf.org
> https://www.ietf.org/mailman/listinfo/webfinger
>
Paul,

Could this:

WebFinger is used to discover information about people or other
entities on the Internet that are identified by a URI [6] or IRI [7]
using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
secure transport [14].

become:

WebFinger is used to discover information about people or other
entities on the Internet that are *denoted* by a URI [6] or IRI [7].
Actual information retrieval uses
standard Hypertext Transfer Protocol (HTTP) [2] methods over a
secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Tim Bray]

No. The I in URI stands for Identifier. URIs identify resources, that’s what they’re for. -T

On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen <kid...@openlinksw.com> wrote:

Could this:

 WebFinger is used to discover information about people or other
   entities on the Internet that are identified by a URI [6] or IRI [7]
   using standard Hypertext Transfer Protocol (HTTP) [2] methods over a
   secure transport [14].

become:

 WebFinger is used to discover information about people or other
   entities on the Internet that are *denoted* by a URI [6] or IRI [7]. Actual information retrieval uses
   standard Hypertext Transfer Protocol (HTTP) [2] methods over a
   secure transport [14].

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[John Bradley]

Tim is correct.

The URI or IRI is an identifier for a resource.  

Where it gets slightly grey is with the acct: scheme.  However I think that the scheme is still identifying an account as the resource, even if there is no default derefrencing.

I think I understand Kingsley wanting to make the transitive link form a identifier for a resource to having that resource denote a abstract object. 

However I think that is best left to philosophers and the W3C.

I think the current text is fine.

John B.

[Kingsley Idehen]

On 12/21/12 4:38 PM, Tim Bray wrote:

No. The I in URI stands for Identifier. URIs identify resources, that’s what they’re for. -T

I know the "I" stands for "Identifier" but these "Identifiers" are being used to "denote" entities (things), in this context.

This subtle tweak has also been adopted in the Semantic Web discourse realm (note latest RDF specs [1]) as a mechanism for adding clarity to the function or URIs.

Links:

1. http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-concepts/index.html -- see how denotation with regards to the function of URIs .

Kingsley

[Kingsley Idehen]

On 12/21/12 5:06 PM, John Bradley wrote:

Tim is correct.

The URI or IRI is an identifier for a resource.  

Where it gets slightly grey is with the acct: scheme.  However I think that the scheme is still identifying an account as the resource, even if there is no default derefrencing.

I think I understand Kingsley wanting to make the transitive link form a identifier for a resource to having that resource denote a abstract object. 

However I think that is best left to philosophers and the W3C.

I think the current text is fine.

John B.

acct: and http: scheme URIs are both being used to denote something (an entity in a discourse realm). These identifiers are also associated with resources that bear information about their referents. Using "denote" helps clarify what's going on.

You have a Name that resolves to Data. Thereby have two identifiers that resolve to the same Data. One route by Name and the other by Location (Address). Thus, a URI can dually identify a real world entity while also doing the same for a resource that bears data describing said entity.

My suggestion is motivated by a desire to reuse breakthroughs that have solved similar problems elsewhere.

Links:

1. http://bit.ly/UXZEYV -- a live demonstration of Web-Scale verifiable identity and protected resource access controls (puts these matters into practical context) .

Kingsley

[Dick Hardt]

Paul

First off, thanks for all the effort in pulling this together -- it is much simpler and tighter than it was in the past.

One aspect that jumped out at me as a client implementor is that I am not sure what URI am supposed to query when I have an email address for a user.
In 3.1 acct: is used, but then later there are mailto: and http: URIs that seem equivalent. i.e.:

1) acct:b...@example.com is used in 3.1, 3.2
2) mailto:b...@example.com is used in 3.3
3) http://www.example.com/~bob/ in 3.1

As a mail client I can see that (3) may be a separate URI that has slightly different meaning that (1) or (2)

As a server implementor, would I need to support both (1) and (2)?

As a client, can I query either (1) or (2)?

Is (2) only for email configuration per 3.3?

Did I miss a reference somewhere that would clarify?

-- Dick

[Tim Bray]

Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.

[Melvin Carvalho]

On 22 December 2012 00:32, Tim Bray <tb...@textuality.com> wrote:

Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.

Totally agree, but perhaps for a moment forget AWWW, which, in imho. is an incredible piece of work.

A URI is simply a global variable.  The benefit of a URI is that is it is constant between heterogeneous systems.  Hence the Web.  As Tim once said, "When you add global variables to some languages, they fall apart, when you add them to hypertext, you get The Web"

There was one deep question discussed it the last decade, and that was:  is it reasonably to divide a web page into a number of sections.  And the decision (perhaps arbitrary) in AWWW, was, that yes it that would be reasonable.   After much thought on the subject, I am also of the opinion that, that is a reasonably approach. 

 Im not really sure it's about castles in the sky, but rather, that if different systems take an entitty/attribute/value approach with a global naming scheme (ie the URI) we can strongly foster interop, and grow the network effect for mutual benefit.

 

[Paul E. Jones]

Dick,

> First off, thanks for all the effort in pulling this together -- it is
> much simpler and tighter than it was in the past.

I just hope we're almost done... this is exhausting ;-)

> One aspect that jumped out at me as a client implementor is that I am
> not sure what URI am supposed to query when I have an email address for
> a user.

This is the topic I tried to cover in section 4.5:
http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#section-4.5

I don't want to go so far as to dictate what URI schemes must be used for
what purpose in this draft. I don't want to limit people's creativity.
That said, we do need a means of identifying "pau...@packetizer.com".
Several years ago, people argued over this and decided "acct:" was a
reasonable solution for identifying user accounts. This is what is
recommended in WebFinger.

> In 3.1 acct: is used, but then later there are mailto: and http: URIs
> that seem equivalent. i.e.:
>
> 1) acct:b...@example.com is used in 3.1, 3.2
> 2) mailto:b...@example.com is used in 3.3
> 3) http://www.example.com/~bob/ in 3.1
>
> As a mail client I can see that (3) may be a separate URI that has
> slightly different meaning that (1) or (2)

I would expect email clients to always use "acct" if the purpose is to look
up information about a user's account at some domain. It does not matter if
it's an email client, web browser, FTP client, or whatever. The "acct" URI
has a specific purpose.

I would expect the mail client to query the server if it is looking for
configuration information. So, when I enter my email address into my
client, it goes out and discovered my SMTP and IMAP server and whatever
server settings to use. (Now, what is documented presently is just an
example. I'd like to see a more complete spec for how that should be done.
Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.)

> As a server implementor, would I need to support both (1) and (2)?

Servers should just serve whatever is populated in the database. My
database has a "resource" table populated with:
acct:pau...@packetizer.com
http://packetizer.com
http://www.packetizer.com
mailto:pau...@packetizer.com
xmpp:pau...@packetizer.com

The records in the resource table have a 1-to-n relationship with another
table called "aliases". The "acct:pau...@packetizer.com" record, for
example, has an alias called "h323:pau...@packetizer.com". If you query my
server using either of those values, you will get more-or-less the same
reply. What changes is the aliases array in the output.

In my server, mailto: is its own "resource". I did this, because the usage
I expect is entirely different from "acct". I expect mailto to be used by
email clients for configuration, as I mentioned.

So, why the "h323" URI in aliases? Well, that's there only because I needed
something to test with. Like mailto and xmpp, an H.323 client would query
the server and get data to help auto-provision. If H.323 did not already
have the ability (which is does using SRV records), I could imagine that an
H.323 URI might be used by an H.323 client (or Gatekeeper) to determine how
to route a call. Same thing for email. If MX records did not exist, I
could imagine using this to advertise the location of the mail server for
the queried URI. (Note that I'm not at all suggesting we switch to WF rather
than use established call routing or mail routing mechanisms.)

Bottom line is that the server should not really care about what is queried.
However, the server admin who populates the database will care what is going
to be queried. Since all of the important stuff have unique "rel" values, I
could merge acct:, xmpp:, mailto:, etc. and serve up one large JRD.

I think the right answer as to what gets placed where should come with WF
procedure specs. For example, if we define a mail client auto-provisioning
spec, let's define the mailto usage there.

For the moment, I'm strongly suggesting we converge on using "acct" for most
things, especially if looking for "social" kinds of information.

> As a client, can I query either (1) or (2)?

The client should issue a query knowing what it's looking for. If it's
looking for my avatar for me, it should query acct:pau...@packetizer.com.
If it's looking for an avatar that represents my blog, it would query using
http://www.packetizer.com/people/paulej/blog/. If the email client is
looking for provisioning info for my email address, it uses mailto.

Anyway, that's my opinion. Nothing in the foregoing is law. ;-)

> Is (2) only for email configuration per 3.3?

I would say "it is for nothing" until the mail configuration spec or other
spec is defined that says use mailto for this. This and other specs need to
be written.

> Did I miss a reference somewhere that would clarify?

Perhaps only section 4.5. There is more work to be done, but I don't want
to clutter the core WF spec with specific things like mail configuration. I
presented that as an example to show the possibilities.

BTW, I do want to work on that mail config doc if Cyrus does not :-)

Paul

[Dick Hardt]

Thanks for the explanation Paul.

I see that section 4.5 answers my question.

Perhaps a pointer to section 4.5 in section 3 would help when an implementor is reading the spec?

I agree that we don't want to dictate more than that.

-- Dick

[Paul E. Jones]

Any suggested wording?

My hands have been smacked so many times...

Paul

[Dick Hardt]

Certainly, text changes were what you requested. I must learn to read directions. I must learn to read directions. I must learn to read directions.

Change the following in 3.1

   In the above example, an "acct" URI [8] is used in the query, though
   any valid alias for the user might also be used.

to be:

   In the above example, an "acct" URI [8] is used in the query, though
   any valid alias for the user might also be used. See section 4.5 for

   more information on WebFinger and URIs. 

1) acct:bob@example.com is used in 3.1, 3.2

2) mailto:b...@example.com is used in 3.3
3) http://www.example.com/~bob/ in 3.1

As a mail client I can see that (3) may be a separate URI that has
slightly different meaning that (1) or (2)

I would expect email clients to always use "acct" if the purpose is to
look up information about a user's account at some domain.  It does
not matter if it's an email client, web browser, FTP client, or
whatever.  The "acct" URI has a specific purpose.

I would expect the mail client to query the server if it is looking
for configuration information.  So, when I enter my email address into
my client, it goes out and discovered my SMTP and IMAP server and
whatever server settings to use.  (Now, what is documented presently
is just an example.  I'd like to see a more complete spec for how that

should be done.

Ditto for other kinds of clients, including SIP, XMPP, H.323, etc.)

As a server implementor, would I need to support both (1) and (2)?

Servers should just serve whatever is populated in the database.  My
database has a "resource" table populated with:

  acct:paulej@packetizer.com

  http://packetizer.com
  http://www.packetizer.com
  mailto:pau...@packetizer.com
  xmpp:pau...@packetizer.com

The records in the resource table have a 1-to-n relationship with

another table called "aliases".  The "acct:paulej@packetizer.com"

acct:paulej@packetizer.com.

[Paul E. Jones]

OK.  And I’ll split the balance the paragraph at that point so that the “alias” text starts as a new paragraph.

 

Paul

[Melvin Carvalho]

On 21 December 2012 18:38, Paul E. Jones <pau...@packetizer.com> wrote:

Folks,

I just posted a revised version of the WebFinger text.  Highlights include:
 * Change all queries to require HTTPS only
 * Forbid server redirection to HTTP URIs
 * Merged the "Introduction" and "Overview" sections
 * Moved some references to the informative references section
 * Removed instructions for the server to return specific
   status codes (Tim successfully argued it was not needed)
    * Retained one statement, though, in section 4.2 that
      requires a server to return a 400.  However, the
      text was changed to refer to behavior in RFC 2616.
      Same end result, though.
 * Moved section the "rel" parameter section before the
   JRD section.
 * Made edits to the JRD section as discussed on the list
 * Various editorial changes

Please have a look at this text and suggest any changes we should make.

This actually looks pretty good!

Re:

The media type used for the JSON Resource Descriptor (JRD) is "application/json"

Doesnt JRD have it's own content type?

See Eran's comment:

http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8122

"For now I’m using application/json, but application/xrd+json is also possible."

Maybe something like application/jrd+json would be best?
 

[Melvin Carvalho]

On 21 December 2012 18:38, Paul E. Jones <pau...@packetizer.com> wrote:

Folks,

I just posted a revised version of the WebFinger text.  Highlights include:
 * Change all queries to require HTTPS only
 * Forbid server redirection to HTTP URIs
 * Merged the "Introduction" and "Overview" sections
 * Moved some references to the informative references section
 * Removed instructions for the server to return specific
   status codes (Tim successfully argued it was not needed)
    * Retained one statement, though, in section 4.2 that
      requires a server to return a 400.  However, the
      text was changed to refer to behavior in RFC 2616.
      Same end result, though.
 * Moved section the "rel" parameter section before the
   JRD section.
 * Made edits to the JRD section as discussed on the list
 * Various editorial changes

Please have a look at this text and suggest any changes we should make.

I've also just realized that webfinger can also have 100s or even 1000s of extra deployments via SPARQL endpoints using mod_rewrite.

For those that done know, SPARQL is a general purpose query language for the Web currently at REC status.

Webfinger amounts to a named SPARQL query with a shorthand syntax.  As such you can translate between the two using a simple mod rewrite rule in your .htaccess.

The query would amount to something like:

SELECT * FROM { <resource> $attribute $value }

Which actually can be URI encoded.  Ive proposed /.well-known/sparql as of today which could facilitate 100s of extra webfinger deployments with a few lines of code.
 

[Tim Bray]

I've also wondered why we don't have application/webfinger+json; seems to me that having your own media-type is a strong Web best practice.  Has this been discussed?  -T

[Kingsley Idehen]

On 12/21/12 6:32 PM, Tim Bray wrote:
>
> Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/)
> has been repealed, these are instances of URIs, whose function per
> rfc3986 is to Identify resources. I don't see how it could be any clearer.
>
> A good thing about WF is that it's just good basic Web stuff. No
> semantic castles in the sky required.
>

Look, we've long implemented Webfinger, Linked Data (see: DBpedia and
the LOD cloud), and very sophisticated stuff via those "semantic
castles". And guess what, it's all driven by a clear understanding that
URIs denote things.

Anyway, I thought to share some guidance from our real world experience
re. service development and deployment, that's it. Other than that, we
already have Webfinger working in ways that simply amplify the
virtuosity of AWWW.

[Kingsley Idehen]

On 12/21/12 10:22 PM, Melvin Carvalho wrote:

On 22 December 2012 00:32, Tim Bray <tb...@textuality.com> wrote:

Unless the Architecture of the WWW ( http://www.w3.org/TR/webarch/) has been repealed, these are instances of URIs, whose function per rfc3986 is to Identify resources. I don't see how it could be any clearer.

A good thing about WF is that it's just good basic Web stuff. No semantic castles in the sky required.

Totally agree, but perhaps for a moment forget AWWW, which, in imho. is an incredible piece of work.

A URI is simply a global variable.  The benefit of a URI is that is it is constant between heterogeneous systems.  Hence the Web.  As Tim once said, "When you add global variables to some languages, they fall apart, when you add them to hypertext, you get The Web"

There was one deep question discussed it the last decade, and that was:  is it reasonably to divide a web page into a number of sections.  And the decision (perhaps arbitrary) in AWWW, was, that yes it that would be reasonable.   After much thought on the subject, I am also of the opinion that, that is a reasonably approach. 

 Im not really sure it's about castles in the sky, but rather, that if different systems take an entitty/attribute/value approach with a global naming scheme (ie the URI) we can strongly foster interop, and grow the network effect for mutual benefit.

Exactly!

Thank You!

Kingsley

[Paul E. Jones]

Melvin,

 

 

This actually looks pretty good!

PEJ: Great!

Re:

The media type used for the JSON Resource Descriptor (JRD) is "application/json"

Doesnt JRD have it's own content type?

See Eran's comment:

http://hueniverse.com/2010/05/jrd-the-other-resource-descriptor/#comment-8122

"For now I’m using application/json, but application/xrd+json is also possible."

Maybe something like application/jrd+json would be best?

 

PEJ: Nothing has ever been defined and RFC 6415 says JRD is “application/json”.  Should somebody (note “somebody”) define something specific for JRD?  I didn’t see any other +json definitions and I know people expressed concern with that previously (not related to WF).  If we defined such a thing, it should either be application/jrd or application/jrd+json.

 

Paul