Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and Simple Web Discovery

From: James M Snell <[email-masked]>
Date: Sat, 7 Jul 2012 22:55:45 -0700

Figured it would be easier to write this up as an I-D...

  http://www.ietf.org/id/draft-snell-web-index-00.txt

- James

---

From: Michiel de Jong <[email-masked]>
Date: Sun, 8 Jul 2012 10:47:17 +0300

Hi James,

Interesting read, especially the use case you describe. I think it can
be improved upon by already adding a user-entered password at the
first step. I think webfinger's original motivation was much more
related to fedsocweb than to configuring a freshly unpacked device,
but it would be nice if we can do both.

However, in the device-configuring use case i would assume the user
inputs both their user address and their password, so we get a sort of
resource owner password credentials flow, which IMHO changes the
requirements (and in an interesting way).

On Sun, Jul 8, 2012 at 8:55 AM, James M Snell <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 9 Jul 2012 23:32:25 -0400

James,

Allow me to comment on your draft w.r.t. the parts related to WebFinger.
WebFinger did built upon the host-meta spec, which is that we see the "two
step" process.  However, the "resource" parameter MUST be supported by
WebFinger servers.  As such, this eliminates most of the complexity issues
on the client side.

To your comments specifically,

1) XRD and JRD support: this is only required on the server. The client can
choose what it wants.  This is largely historical, but I'm not shy to say
that I favor XML.  I respect that some prefer JSON, though. 

2) Two-step HTTP request process: Requests could be a single step.  No
client is required to implement a two-step request, ever.  The two-step
option exists, since WebFinger is an extension of RFC 6415, but the
"resource" makes the query a one-step operation.

3) There are several sub-parts:

3a) The WebFinger protocol defines normative dependencies on no fewer than
ten separate specifications: that's being a bit unfair. We tried to be
thorough with documenting material.  We could perhaps make .well-known, web
linking, URI syntax, and mailto URI informative.  We could discuss where
those references should live, but HTTP and XRD/JRD are really the core part
of WebFinger.  It's not so complex as you suggest here.

3b) A WebFinger client needs to not only be capable of sending HTTP
requests; but capable of parsing XML or JSON: They must parse one of the
two. This is pretty basic.

3c) Capable of understanding the specific XRD and JRD vocabularies: there
are no "specific" vocabularies, just XRD and JRD syntax. Both are simple and
a client picks what it wants.

3d) Capable of processing URL Templates: since "resource" is mandatory, a
client does not need to deal with templates

3e) Capable of processing XML digital signatures included within an XRD
document: yeah, if HTTPS is not used. I doubt anybody will use signatures in
favor of HTTPS.  I suspect no client will process the signatures, either.
(There is "standards completeness" and reality.)

4) WebFinger uses email-like identifiers and this is a privacy concern:
email-like IDs are suggested to make WebFinger easy to use *by humans*, but
there is definitely no requirement that one MUST use
"acct:[email-masked]".  One can use any valid URI.  An enterprise
could use some cryptic URI.  The recommendation to use
[email-masked], for example, it to make your life easier if you want
to learn more about me.  What is actually exposed and what is accessible is
a matter of the publisher of that content and can be secured using standard
web security mechanisms.  Note that use of HTTPS also hides the email-like
ID, too, so it's not seen on the wire, so I'm really not sure why you're
concerned with this.  Those who want security will use TLS.

So just to reiterate, a WebFinger request for this URL:

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

Typically looks like this:

GET /.well-known/host-meta.json?resource=acct:[email-masked] HTTP/1.1
Host: packetizer.com

The reply might have this body:

{
  "subject" : "acct:[email-masked]",
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "href" : "http://www.packetizer.com/people/paulej/images/paulej.jpg"
    },
    {
      "rel" : "http://specs.openid.net/auth/2.0/provider",
      "href" : "https://openid.packetizer.com/paulej"
    },
    {
      "rel" : "http://webfinger.net/rel/profile-page",
      "href" : "http://www.packetizer.com/people/paulej/"
    },
    {
      "rel" : "vcard",
      "href" : "http://www.packetizer.com/people/paulej/paulej.vcf"
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "href" : "http://www.packetizer.com/people/paulej/blog/blog.xml"
    }
  ]
}

That's a fairly simple request / response, IMO.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of James M Snell
> Sent: Sunday, July 08, 2012 1:56 AM
> To: IETF Apps Discuss
> Subject: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger and
> Simple Web Discovery
>

---

From: James M Snell <[email-masked]>
Date: Mon, 9 Jul 2012 22:16:54 -0700

Hey Paul,

I definitely appreciate the detailed response. Perhaps I was a bit
harsh in my criticisms but the overall points still remain... A few
comments inline...

> that I favor XML.  I respect that some prefer JSON, though.

Why should there be a choice at all? Just choose one and be done with
it... preferably the least complicated of the two
(http://www.xprogramming.com/Practices/PracSimplest.html)

> "resource" makes the query a one-step operation.

Yup... I made sure to point this out clearly in my note. If, as you
say, clients are not ever required to implement the two-step flow,
then why is it defined at all? Why add the additional complexity? This
was one of the main points of my document and my counter proposal for
/.well-known/index ... the RFC6415 requirement seems entirely
superfluous to achieving the goal.

> client does not need to deal with templates

I think you may have missed the key point I was making: XML, JSON,
XRD, JRD, URL templates, Digital Signatures, host-meta.. these are all
things that WebFinger says are required without providing any
reasonable justification as to WHY they are required. Both the Simple
Web Discovery draft and my /.well-known/index examples illustrate that
we can easily solve the fundamental problem with a whole lot less than
what WebFinger defines... even if those things are -- by your own
statement -- only there for "spec completeness".

> concerned with this.  Those who want security will use TLS.

Several things with this one...

1. All of the examples that deal with people show the use of acct
identifiers. From experience, I know that developers will generally
look at the examples in the spec before they look at the spec text
itself and they will generally follow whatever pattern is
illustrated... Simply saying that "some cryptic URI" could be used
does not sufficiently deal with the issue. Support for hashed or
otherwise obfuscated identifiers within the request URI should be made
explicit .. either via clear example or by normative requirement.

2. The use of SSL/TLS does not prevent request URIs from being
recorded in log files, exposed in browsers, or compromised in a
variety of unforeseen ways. Yes, it protects the data in transit but
protects nothing when the data is at rest.

> That's a fairly simple request / response, IMO.

And an alternative approach would look like.. (the numbers are the
sha-256 digest of the acct id)

GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8
HTTP/1.1
Host: packetizer.com

HTTP/1.1 300 Multiple Choices
Link: </people/paulej/images/paulej.jpg>; rel="http://webfinger.net/rel/avatar",
  <https://openid.packetizer.com/paulej>;
rel="http://specs.openid.net/auth/2.0/provider",
  </people/paulej/>; rel="http://webfinger.net/rel/profile.page",
  </people/paulej/paulej.vcf>; rel="vcard",
  </people/paulej/blog/blog.xml>;
rel="http://schemas.google.com/g/2010#updates-from"

And if all I want is the location of the avatar, for instance, it
could be even easier...

GET /.well-known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7f8/avatar
HTTP/1.1
Host: packetizer.com

HTTP/1.1 302 Found
Location: /people/paulej/images/paulej.jpg

Why should I, as the client, ever have to worry about XRD/JRD at all?
This is an important question that I have not yet seen an adequate
answer for. Anyone who has worked with me before on things knows that
with solid examples and a reasonable explanation I can be swayed to
see the light and the error of my ways. So far, however, I am just not
seeing it here.

- James

---

From: James M Snell <[email-masked]>
Date: Mon, 9 Jul 2012 22:18:29 -0700

Hey Paul,

2. The use of SSL/TLS does not prevent request URIs from being
recorded in log files, exposed in browsers, or compromised in a
variety of unforeseen ways. Yes, it protects the data in transit but
does nothing when the data is at rest. For example, an unrelated but
similar problem to this is the use of API Ke

---

From: James M Snell <[email-masked]>
Date: Mon, 9 Jul 2012 22:27:39 -0700

I apologize for the duplicate post... looks like gmail and my internet
connection weren't getting along there for a second... not sure how it
ended up sending out a partial version of my response...

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 10 Jul 2012 19:23:38 -0400

James,

> > WebFinger did built upon the host-meta spec, which is that we see the
> > "two step" process.  However, the "resource" parameter MUST be
> > supported by WebFinger servers.  As such, this eliminates most of the
> > complexity issues on the client side.
> >
> > 1) XRD and JRD support: this is only required on the server. The
> > client can choose what it wants.  This is largely historical, but I'm
> > not shy to say that I favor XML.  I respect that some prefer JSON,
> though.
> >
> 

This is due to the relatively recent shift in the "preferred syntax de jour".  When the work on WebFinger and host-meta started, XML was considered the lingua franca of the Internet.  Interest in JSON was growing, but still had not reached critical mass.  By the time RFC 6415 was nearing publication, interest in JSON had grown to a point where the authors felt it needed inclusion, so a JSON version of XRD (called JRD) was defined in RFC 6415. 

They're both trivial syntaxes.  Since JSON lacks a formal syntax specification, JRD is defined with respect to XRD, which is in turn defined using XML Schema.  JRD is definitely most interesting to people right now, but XRD is already implemented in the wild.  Personally, I prefer XRD and see no particular advantage in using JRD.  (JSON works well in JavaScript applications, so I appreciate why people would like to use it.  In C++, though, present roughly the same work to utilize.)

XRD and JRD are defined in RFC 6415.  They exist and so I do not see any reason to exclude one in favor of the other.  Writing the server code to support both is a trivial exercise, so why remove one arguing that it's complex?  It's not.
 
> > client is required to implement a two-step request, ever.  The
> > two-step option exists, since WebFinger is an extension of RFC 6415,
> > but the "resource" makes the query a one-step operation.
> >
> 
> Yup... I made sure to point this out clearly in my note. If, as you say,
> clients are not ever required to implement the two-step flow, then why is
> it defined at all? Why add the additional complexity? This was one of the
> main points of my document and my counter proposal for /.well-known/index
> ... the RFC6415 requirement seems entirely superfluous to achieving the
> goal.

Host-Meta / WebFinger allows for one to query information related to a host and to specific resources controlled by that host.  So, a client can make a query and learn something about the host.  One can then make a second query and learn about a particular resource at that host.  Alternatively, if information about the host is not of interest, one can make a single query and ask for information about the resource directly.

We could re-write RFC 6415 and say that if the "resource" parameter is not there, only return host-specific link relations (versus URI templates).  However, there is no point in re-writing writing what is defined and implemented.  That's especially true given how simple and consistent the logic is when implementing the host-meta / WebFinger server code.

> > 3a) The WebFinger protocol defines normative dependencies on no fewer
> > than ten separate specifications: that's being a bit unfair. We tried
> > to be thorough with documenting material.  We could perhaps make
> > .well-known, web linking, URI syntax, and mailto URI informative.  We
> > could discuss where those references should live, but HTTP and XRD/JRD
> > are really the core part of WebFinger.  It's not so complex as you
> suggest here.
> >
> > requests; but capable of parsing XML or JSON: They must parse one of
> > the two. This is pretty basic.
> >
> > 3c) Capable of understanding the specific XRD and JRD vocabularies:
> > there are no "specific" vocabularies, just XRD and JRD syntax. Both
> > are simple and a client picks what it wants.
> >
> > 3d) Capable of processing URL Templates: since "resource" is
> > mandatory, a client does not need to deal with templates
> 
> I think you may have missed the key point I was making: XML, JSON, XRD,
> JRD, URL templates, Digital Signatures, host-meta.. these are all things
> that WebFinger says are required without providing any reasonable
> justification as to WHY they are required. Both the Simple Web Discovery
> draft and my /.well-known/index examples illustrate that we can easily
> solve the fundamental problem with a whole lot less than what WebFinger
> defines... even if those things are -- by your own statement -- only there
> for "spec completeness".

Your draft and SWD just use a different syntax.  They do not eliminate syntax.  One way or the other, we must have syntax.

XRD and JRD are required, because RFC 6415 (which is the basis for WebFinger) defined XRD and JRD.  RFC 6415 is something this group just completed in October 2011, I'll note.

Signatures on XRD are optional and I doubt anybody will do it, anyway.  I suspect the folks in OASIS did that just for completeness.  I'm certainly not going to ever bother with them.  People should use HTTPS and be done with it.

URI templates are useful to RFC 6415 and those who elect to not use the "resource" parameter.  Using the "resource" parameter, one never sees URI templates.  However, they exist because they are defined in RFC 6415 to allow for querying resource-specific link relations.

So what does it take to create a WebFinger server?  It's so trivial, I can do it with static files.  When one can do that, that means it's not that complex.  See here for an example:
http://www.packetizer.com/webfinger/server.html

> > document: yeah, if HTTPS is not used. I doubt anybody will use
> > signatures in favor of HTTPS.  I suspect no client will process the
> signatures, either.
> > email-like IDs are suggested to make WebFinger easy to use *by
> > humans*, but there is definitely no requirement that one MUST use
> > "acct:[email-masked]".  One can use any valid URI.  An
> > enterprise could use some cryptic URI.  The recommendation to use
> > [email-masked], for example, it to make your life easier if you
> > want to learn more about me.  What is actually exposed and what is
> > accessible is a matter of the publisher of that content and can be
> > secured using standard web security mechanisms.  Note that use of
> > HTTPS also hides the email-like ID, too, so it's not seen on the wire,
> > so I'm really not sure why you're concerned with this.  Those who want
> security will use TLS.
> 
> identifiers. From experience, I know that developers will generally look
> at the examples in the spec before they look at the spec text itself and
> they will generally follow whatever pattern is illustrated... Simply
> saying that "some cryptic URI" could be used does not sufficiently deal
> with the issue. Support for hashed or otherwise obfuscated identifiers
> within the request URI should be made explicit .. either via clear example
> or by normative requirement.

Not all examples use "acct", though most certainly do.  There are three examples using "http" and one using a fictitious "device".

If one uses TLS, this is a non-issue, anyway.  When TLS is used, identifiers are never seen outside the application.  Even if TLS was not used, I'm still not sure why hiding one's identifier is a concern when we're also perfectly OK with returning information about people in the clear or making it public in the first place :-)

> 2. The use of SSL/TLS does not prevent request URIs from being recorded in
> log files, exposed in browsers, or compromised in a variety of unforeseen
> ways. Yes, it protects the data in transit but protects nothing when the
> data is at rest.

The server that would be responding to requests would be the one that would be recording stuff in log files when using TLS.  It already knows about these IDs and could certainly translate an obfuscated value into a real value and log requests that way.  Exposed in browsers?  Users will type in "[email-masked]", so it's already in a browser.  If one wants to use something with WF that does not look like an email address, they can.
 
> >       "href" :
> "http://www.packetizer.com/people/paulej/images/paulej.jpg"
> >     },
> >     {
> GET /.well-
> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7
> f8
> HTTP/1.1
> Host: packetizer.com
> 

This is just another syntax, as I said.  Also, I personally find this more challenging to deal with since it's in the headers, not the payload.

Might the web server itself want to introduce a Link header or perhaps a web proxy?  One might get back information that was not strictly about the resource being queried.  (For example, a link to a copyright statement or "authorized users" statement or other.)
 
> And if all I want is the location of the avatar, for instance, it could be
> even easier...
> 
> GET /.well-
> known/index/4564b4ecfc394d6eda9884c0cd7d2d99279b72b9c96618115e8767aa97b1d7
> f8/avatar
> HTTP/1.1
> Host: packetizer.com
> 
> HTTP/1.1 302 Found

So, I get a 302 and don't know why.  Am I being redirected because the user's information moved or because the information I seek is located there?  Web browsers will not even tell me about 302s when writing JavaScript code, AFAIK.  So, I might issue a query to get several things (e.g., calendar and avatar), but only an avatar exists.  The server returns a 302 and I get a payload with a picture and have no idea what it is for.  Or would you return a 200 in that case with a single "Link:" href/rel pair?
 
> This is an important question that I have not yet seen an adequate answer
> for. Anyone who has worked with me before on things knows that with solid
> examples and a reasonable explanation I can be swayed to see the light and
> the error of my ways. So far, however, I am just not seeing it here.

Because this is a very simple and consistent syntax that nicely packages up a set of link relations and properties.  I might also provided with a list of aliases for the user/target.

We had a separate dialog about how we could use the JRD syntax to convey provisioning information related to mail servers.  I'm not sure if anyone would do that, but having the ability to include additional properties is nice, since it allows for a richer set of information to be conveyed.

Lastly, having an XRD or JRD in hand allows that document to be passed "down the line" for processing.  Headers in HTTP could, too, but as I said, it's an alternate syntax that is less complete and I personally find dealing with a returned payload simpler than putting valuable response information in headers.

Paul

---

From: James M Snell <[email-masked]>
Date: Wed, 11 Jul 2012 16:03:05 -0700

Paul, for most of this we'll apparently have to simply disagree and
leave it at that as I've got no intention or desire to try to convince
you to change your opinion. The intent of my memo was to solely to
document that I feel there's an even easier way of accomplishing the
same task with fewer moving parts. I believe I provided an adequate
example that proves that point.

I still do not see why parsing *any* XML or JSON should be a
requirement, however, as I do not see what particular benefit they
provide. I've asked several times but have not yet seen a clear answer
to this very basic question: *Why* are they *required*? What benefits
do those dependencies provide that are critical to solving the basic
problem? Are they simply something that would be nice to have?

I don't need yet another explanation as to why you think it's just
trivial so why am I bothering to ask... I want to know why those
dependencies are *required*.

Note, fwiw, that the /.well-known/index proposal is not contrary to
the possible use of XRD/LRDD... for instance, one could easily do
something like...

  GET /.well-known/index/{some-opaque-id}/lrdd HTTP/1.1
  Host: example.org

And get back a...

  HTTP/1.1 302 Found
  Location: /lrdd/?uri=acct:[email-masked]

- James

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 12 Jul 2012 10:30:04 +0200

On 11 July 2012 01:23, Paul E. Jones <[email-masked]> wrote:

> This is due to the relatively recent shift in the "preferred syntax de
> jour".  When the work on WebFinger and host-meta started, XML was
> considered the lingua franca of the Internet.  Interest in JSON was
> growing, but still had not reached critical mass.  By the time RFC 6415 was
> nearing publication, interest in JSON had grown to a point where the
> authors felt it needed inclusion, so a JSON version of XRD (called JRD) was
> defined in RFC 6415.
>
> They're both trivial syntaxes.  Since JSON lacks a formal syntax
> specification

I think JSON does have a formal syntax specification:

http://json.org/

Or did you mean that JRD?

> , JRD is defined with respect to XRD, which is in turn defined using XML
> Schema.  JRD is definitely most interesting to people right now, but XRD is
> already implemented in the wild.  Personally, I prefer XRD and see no
> particular advantage in using JRD.  (JSON works well in JavaScript
> applications, so I appreciate why people would like to use it.  In C++,
> though, present roughly the same work to utilize.)
>
> XRD and JRD are defined in RFC 6415.  They exist and so I do not see any
> reason to exclude one in favor of the other.  Writing the server code to
> support both is a trivial exercise, so why remove one arguing that it's
> complex?  It's not.
>
> Host-Meta / WebFinger allows for one to query information related to a
> host and to specific resources controlled by that host.  So, a client can
> make a query and learn something about the host.  One can then make a
> second query and learn about a particular resource at that host.
>  Alternatively, if information about the host is not of interest, one can
> make a single query and ask for information about the resource directly.
>
> We could re-write RFC 6415 and say that if the "resource" parameter is not
> there, only return host-specific link relations (versus URI templates).
>  However, there is no point in re-writing writing what is defined and
> implemented.  That's especially true given how simple and consistent the
> logic is when implementing the host-meta / WebFinger server code.
>
> Your draft and SWD just use a different syntax.  They do not eliminate
> syntax.  One way or the other, we must have syntax.
>
> XRD and JRD are required, because RFC 6415 (which is the basis for
> WebFinger) defined XRD and JRD.  RFC 6415 is something this group just
> completed in October 2011, I'll note.
>
> Signatures on XRD are optional and I doubt anybody will do it, anyway.  I
> suspect the folks in OASIS did that just for completeness.  I'm certainly
> not going to ever bother with them.  People should use HTTPS and be done
> with it.
>
> URI templates are useful to RFC 6415 and those who elect to not use the
> "resource" parameter.  Using the "resource" parameter, one never sees URI
> templates.  However, they exist because they are defined in RFC 6415 to
> allow for querying resource-specific link relations.
>
> So what does it take to create a WebFinger server?  It's so trivial, I can
> do it with static files.  When one can do that, that means it's not that
> complex.  See here for an example:
> Not all examples use "acct", though most certainly do.  There are three
> examples using "http" and one using a fictitious "device".
>
> If one uses TLS, this is a non-issue, anyway.  When TLS is used,
> identifiers are never seen outside the application.  Even if TLS was not
> used, I'm still not sure why hiding one's identifier is a concern when
> we're also perfectly OK with returning information about people in the
> clear or making it public in the first place :-)
>
> The server that would be responding to requests would be the one that
> would be recording stuff in log files when using TLS.  It already knows
> about these IDs and could certainly translate an obfuscated value into a
> real value and log requests that way.  Exposed in browsers?  Users will
> type in "[email-masked]", so it's already in a browser.  If one
> wants to use something with WF that does not look like an email address,
> they can.
>
> This is just another syntax, as I said.  Also, I personally find this more
> challenging to deal with since it's in the headers, not the payload.
>
> Might the web server itself want to introduce a Link header or perhaps a
> web proxy?  One might get back information that was not strictly about the
> resource being queried.  (For example, a link to a copyright statement or
> "authorized users" statement or other.)
>
> So, I get a 302 and don't know why.  Am I being redirected because the
> user's information moved or because the information I seek is located
> there?  Web browsers will not even tell me about 302s when writing
> JavaScript code, AFAIK.  So, I might issue a query to get several things
> (e.g., calendar and avatar), but only an avatar exists.  The server returns
> a 302 and I get a payload with a picture and have no idea what it is for.
>  Or would you return a 200 in that case with a single "Link:" href/rel pair?
>
> Because this is a very simple and consistent syntax that nicely packages
> up a set of link relations and properties.  I might also provided with a
> list of aliases for the user/target.
>
> We had a separate dialog about how we could use the JRD syntax to convey
> provisioning information related to mail servers.  I'm not sure if anyone
> would do that, but having the ability to include additional properties is
> nice, since it allows for a richer set of information to be conveyed.
>
> Lastly, having an XRD or JRD in hand allows that document to be passed
> "down the line" for processing.  Headers in HTTP could, too, but as I said,
> it's an alternate syntax that is less complete and I personally find
> dealing with a returned payload simpler than putting valuable response
> information in headers.
>
> Paul
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 23 Jul 2012 21:43:31 -0400

James,

Sorry for the belated reply.  I was out of the office the week your message came in and I'm still catching up.

One has to have some kind of syntax.  It might be in the form of a Link header (as you've proposed in the "index" draft) or a payload (as proposed in the "WebFinger" and "SWD" drafts).  Regardless of the approach, there is syntax.

What we've proposed in WebFinger and SWD is to return the information we're seeking in the payload of the HTTP request.  For clients, this is the more appropriate place to put it, since this is how HTTP is intended to use.  Using Link headers as a form of metadata is perhaps useful when returning various web content, but I don't think it should be the syntax for the primary content being returned.  In fact, one might even use a Link header in a WF response of there was appropriate metadata to convey.

The approach we've proposed in WF provides for a simple client-side implementation that is consistent, and it also allows one to separate the HTTP request/response logic from the software layer that requests and acts upon the discoverable information.  A WF application could request information and it would get a payload of information back or it will not. Messages like 3xx can be handled "under the hood", as could authentication request, 5xx, etc. 

Another benefit to using JSON or XML, either one, is that one could convey more information than just a link relation and value.  There are also properties that could be defined.  We discussed on this list how we could use those properties to indicate what port numbers or other information to use by an auto-provisioning email client, as an example.  For clients not interested in those properties, they would simply be ignored.

So regardless of approach, there is syntax.  It's a matter of where that syntax is placed, how useful the syntax is, and how easily it can be consumed.  All of the approaches presented are fairly simple, but I think building on host-meta (which was the plan for the past several years) offers the most consistent approach, while also being simple and rich at the same time.  I can issue a single query and get a payload with lots of information back, all neatly wrapped in a simple syntax carried in the response payload.

Let me also say that I tell you all of this without bias.  I did not create the XRD syntax, RFC 6415, or define any of the mechanisms myself.  I came to the party a bit late after much of this was already defined (XRD was just being approved).  I liked what I saw and I am interested to see it through, as it has value to social networking applications and enterprise applications.

Paul

> From: James M Snell [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 7:03 PM
> To: Paul E. Jones
> Cc: IETF Apps Discuss
> Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger
> and Simple Web Discovery
> 
> Paul, for most of this we'll apparently have to simply disagree and leave
> it at that as I've got no intention or desire to try to convince you to
> change your opinion. The intent of my memo was to solely to document that
> I feel there's an even easier way of accomplishing the same task with
> fewer moving parts. I believe I provided an adequate example that proves
> that point.
> 
> I still do not see why parsing *any* XML or JSON should be a requirement,
> however, as I do not see what particular benefit they provide. I've asked
> several times but have not yet seen a clear answer to this very basic
> question: *Why* are they *required*? What benefits do those dependencies
> provide that are critical to solving the basic problem? Are they simply
> something that would be nice to have?
> 
> I don't need yet another explanation as to why you think it's just trivial
> so why am I bothering to ask... I want to know why those dependencies are
> *required*.
> 
> Note, fwiw, that the /.well-known/index proposal is not contrary to the
> possible use of XRD/LRDD... for instance, one could easily do something
> like...
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 23 Jul 2012 22:54:03 -0400

Melvin,

When I said JSON did not have a formal syntax specification, I intended to
say a schema definition.  I know there was work on a JSON schema, but not
sure where that went.  JSON is certainly well-defined, but a complete schema
language is missing.  Therefore, it's hard to define things in terms of JSON
without doing so using examples.  RFC 6415 did it by considering XRD syntax
and specifying how that maps.

Paul

From: Melvin Carvalho [mailto:[email-masked]] 
Sent: Thursday, July 12, 2012 4:30 AM
To: Paul E. Jones
Cc: James M Snell; IETF Apps Discuss
Subject: Re: [apps-discuss] FYI: draft-snell-web-index-00 .. re: WebFinger
and Simple Web Discovery

James,

This is due to the relatively recent shift in the "preferred syntax de
jour".  When the work on WebFinger and host-meta started, XML was considered
the lingua franca of the Internet.  Interest in JSON was growing, but still
had not reached critical mass.  By the time RFC 6415 was nearing
publication, interest in JSON had grown to a point where the authors felt it
needed inclusion, so a JSON version of XRD (called JRD) was defined in RFC
6415.

http://json.org/

> ... the RFC6415 requirement seems entirely superfluous to achieving the

Host-Meta / WebFinger allows for one to query information related to a host
and to specific resources controlled by that host.  So, a client can make a
query and learn something about the host.  One can then make a second query
and learn about a particular resource at that host.  Alternatively, if
information about the host is not of interest, one can make a single query
and ask for information about the resource directly.

> > "acct:[email-masked] <mailto:[email-masked]> ".
One can use any valid URI.  An

If one uses TLS, this is a non-issue, anyway.  When TLS is used, identifiers
are never seen outside the application.  Even if TLS was not used, I'm still
not sure why hiding one's identifier is a concern when we're also perfectly
OK with returning information about people in the clear or making it public
in the first place :-)

> ways. Yes, it protects the data in transit but protects nothing when the

The server that would be responding to requests would be the one that would
be recording stuff in log files when using TLS.  It already knows about
these IDs and could certainly translate an obfuscated value into a real
value and log requests that way.  Exposed in browsers?  Users will type in
"[email-masked]", so it's already in a browser.  If one wants to use
something with WF that does not look like an email address, they can.

> > GET /.well-known/host-meta.json?resource=acct:[email-masked]
<mailto:[email-masked]> 
> >   "subject" : "acct:[email-masked]
<mailto:[email-masked]> ",

Might the web server itself want to introduce a Link header or perhaps a web
proxy?  One might get back information that was not strictly about the
resource being queried.  (For example, a link to a copyright statement or
"authorized users" statement or other.)

So, I get a 302 and don't know why.  Am I being redirected because the
user's information moved or because the information I seek is located there?
Web browsers will not even tell me about 302s when writing JavaScript code,
AFAIK.  So, I might issue a query to get several things (e.g., calendar and
avatar), but only an avatar exists.  The server returns a 302 and I get a
payload with a picture and have no idea what it is for.  Or would you return
a 200 in that case with a single "Link:" href/rel pair?

> the error of my ways. So far, however, I am just not seeing it here.

Because this is a very simple and consistent syntax that nicely packages up
a set of link relations and properties.  I might also provided with a list
of aliases for the user/target.

Lastly, having an XRD or JRD in hand allows that document to be passed "down
the line" for processing.  Headers in HTTP could, too, but as I said, it's
an alternate syntax that is less complete and I personally find dealing with
a returned payload simpler than putting valuable response information in
headers.

Paul