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

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 21 Dec 2012 12:38:24 -0500

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: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Friday, December 21, 2012 12:21 PM
> To: [email-masked]
> Cc: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Kingsley Idehen <[email-masked]>
Date: Fri, 21 Dec 2012 16:09:03 -0500

On 12/21/12 12:38 PM, Paul E. Jones wrote:
> webfinger mailing list
> [email-masked]
> 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

---

From: Tim Bray <[email-masked]>
Date: Fri, 21 Dec 2012 13:38:03 -0800

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 <[email-masked]>wrote:

> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>
>
>
>
>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 21 Dec 2012 19:06:14 -0300

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.
On 2012-12-21, at 6:38 PM, Tim Bray <[email-masked]> wrote:

> 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 <[email-masked]> wrote:
> 
> Could this:
> 
>    entities on the Internet that are *denoted* by a URI [6] or IRI [7]. Actual information retrieval uses

---

From: Kingsley Idehen <[email-masked]>
Date: Fri, 21 Dec 2012 17:22:42 -0500

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
>
> On Fri, Dec 21, 2012 at 1:09 PM, Kingsley Idehen 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Could this:
>
>     <http://www.openlinksw.com/blog/%7Ekidehen>
>     [email-masked] <mailto:[email-masked]>

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: Kingsley Idehen <[email-masked]>
Date: Fri, 21 Dec 2012 17:30:36 -0500

On 12/21/12 5:06 PM, John Bradley wrote:
> 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.
>

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)

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Dec 2012 15:18:59 -0800

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:[email-masked] is used in 3.1, 3.2 
2) mailto:[email-masked] 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

---

From: Tim Bray <[email-masked]>
Date: Fri, 21 Dec 2012 15:32:03 -0800

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.
On Dec 21, 2012 2:22 PM, "Kingsley Idehen" <[email-masked]> wrote:

> realm (note latest RDF specs [1]) as a mechanism for adding clarity to the
> function or URIs.
>
> Links:
>
> webfinger mailing [email-masked]://www.ietf.org/mailman/listinfo/webfinger
>
>
>
> --
>
> Regards,
>
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software

---

From: Melvin Carvalho <[email-masked]>
Date: Sat, 22 Dec 2012 04:22:34 +0100

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 21 Dec 2012 22:30:07 -0500

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 "[email-masked]".
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.

> 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:[email-masked]
    http://packetizer.com
    http://www.packetizer.com
    mailto:[email-masked]
    xmpp:[email-masked]

The records in the resource table have a 1-to-n relationship with another
table called "aliases".  The "acct:[email-masked]" record, for
example, has an alias called "h323:[email-masked]".  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:[email-masked].
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

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Dec 2012 19:39:40 -0800

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 21 Dec 2012 22:43:06 -0500

Any suggested wording?

My hands have been smacked so many times...
 
Paul

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Friday, December 21, 2012 10:40 PM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]
> Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-
> webfinger-08.txt
> 
> >> First off, thanks for all the effort in pulling this together -- it
> >> is much simpler and tighter than it was in the past.
> >
> >> not sure what URI am supposed to query when I have an email address
> >> for a user.
> >
> > 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.
> > 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.
> > The records in the resource table have a 1-to-n relationship with
> > another table called "aliases".  The "acct:[email-masked]"
> > record, for example, has an alias called "h323:[email-masked]".
> > 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.)
> >
> > 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.
> >
> > 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:[email-masked].
> > 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.
> >
> > 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.
> >
> > 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.
> >

---

From: Dick Hardt <[email-masked]>
Date: Fri, 21 Dec 2012 19:48:02 -0800

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.

---

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

OK.  And I'll split the balance the paragraph at that point so that the
"alias" text starts as a new paragraph.

Paul

From: Dick Hardt [mailto:[email-masked]] 
Sent: Friday, December 21, 2012 10:48 PM
To: Paul E. Jones
Cc: 'Dick Hardt'; [email-masked]; [email-masked]
Subject: Re: [webfinger] [apps-discuss] I-D Action:
draft-ietf-appsawg-webfinger-08.txt

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
<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#ref-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
<http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-08#ref-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. 

Any suggested wording?

Paul

-----Original Message-----
From: Dick Hardt [mailto:[email-masked]]
Sent: Friday, December 21, 2012 10:40 PM
To: Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: Re: [webfinger] [apps-discuss] I-D Action: draft-ietf-appsawg-
webfinger-08.txt

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

-- Dick

On Dec 21, 2012, at 7:30 PM, "Paul E. Jones" <[email-masked]>
wrote:

Dick,

creativity.

In 3.1 acct: is used, but then later there are mailto: and http: URIs
that seem equivalent. i.e.:

should be done.

output.

Bottom line is that the server should not really care about what is

queried.

one large JRD.

information.

mailto.

possibilities.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Sat, 22 Dec 2012 16:10:26 +0100

> 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?

---

From: Melvin Carvalho <[email-masked]>
Date: Sat, 22 Dec 2012 16:17:03 +0100

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

---

From: Tim Bray <[email-masked]>
Date: Sat, 22 Dec 2012 08:52:56 -0800

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

---

From: Kingsley Idehen <[email-masked]>
Date: Sat, 22 Dec 2012 13:46:30 -0500

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.

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: Kingsley Idehen <[email-masked]>
Date: Sat, 22 Dec 2012 18:17:46 -0500

On 12/21/12 10:22 PM, Melvin Carvalho wrote:
>
>
> On 22 December 2012 00:32, Tim Bray <[email-masked] 
> <mailto:[email-masked]>> 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.
>
> 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.
>
> 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
>
>     On Dec 21, 2012 2:22 PM, "Kingsley Idehen" <[email-masked]
>     <mailto:[email-masked]>> 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
>>
>>                entities on the Internet that are *denoted* by a URI
>>             [6] or IRI [7]. Actual information retrieval uses
>>             Google+ Profile:
>>             https://plus.google.com/112399767740508618350/about
>         Company Web:http://www.openlinksw.com
>         Personal Weblog:http://www.openlinksw.com/blog/~kidehen  <http://www.openlinksw.com/blog/%7Ekidehen>
>         Google+ Profile:https://plus.google.com/112399767740508618350/about
>         LinkedIn Profile:http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
>

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 22 Dec 2012 19:01:16 -0500

Melvin,

PEJ: Great!

Re:

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

See Eran's comment:

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

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

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

---

From: [email-masked]
Date: Sun, 23 Dec 2012 15:54:09 +0000 (GMT)

> me that having your own media-type is a strong Web best practice.  Has this

Can you point me to references to _why_ that is "best practice"?

It's something I find quite annoying. It's application/json, being
used in a webfinger context. In some other context it could be used
for something else.

In both contexts it is a JSON representation, you use JSON tools to
process it.

Having another media-type seems to just make things more noisy. Is the
point to have some little agent sitting around being all smart because
it can trigger imporant decision based merely on the media-type of its
input? If that's so, I'm not sure I buy it: We wouldn't have gone to
this resource in the first place if we weren't hoping to get webfinger
info back.

Help me understand.

Thanks.

-- 
Chris Dent                                   http://burningchrome.com/
                                 [...]

---

From: James M Snell <[email-masked]>
Date: Sun, 23 Dec 2012 08:42:40 -0800

When it comes to JSON, because we don't have anything similar to a
namespace to key off of when parsing, a specific media type really does
help to determine if the server returned the right kind of JSON-based thing
in response to the query. I don't see a specific media type as being
critical in any way for WebFinger but it can be helpful if provided.

On Sun, Dec 23, 2012 at 7:54 AM, <[email-masked]> wrote:

> ______________________________**_________________
> webfinger mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/webfinger<https://www.ietf.org/mailman/listinfo/webfinger>
>