Subject: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 19 Oct 2012 21:22:18 -0400

Folks,

I just posted a revised version of the WebFinger specification, taking into
consideration all of the discussion on the lists since the last document was
posted.

Here is a summary of the changes:

.         Editorial improvements, including non-technical changes

.         Made all examples in the main body of the document JSON only

.         JSON Resource Descriptor (JRD) documents are the only mandatory
format required to be implemented by a WebFinger server

.         Extensible Resource Descriptor (XRD) documents are now optional to
implement on the server

.         The default format for /.well-known/host-meta is XRD if the server
implements XRD; clients must be prepared to receive a JRD; the "Accept"
header is still used to negotiate the preferred type

.         The default format for /.well-known/host-meta.json is JRD

.         New text to consider hosting the WebFinger service elsewhere,
including outsourcing the service for the entire domain or only part of the
domain (the latter is more complex for the WebFinger server to implement,
but the former is straight-forward using HTTP redirection)

.         New text to address a few interoperability considerations with RFC
6415

.         Removal of the "Implementation Note" relating to the "acct" URI
since "acct" URI material is no longer a part of the document

.         Introduced a new Appendix that shows one of the examples from the
main body in XML format, along with procedures for using XML, and security
consideration related to this XRD signatures

I tried very hard to strike the right balance between what people want in
terms of having a very simple client implementation and the fact that there
are existing clients and servers.  Of course, new JSON-only clients will not
be able to get useful information from XML-only servers.  Likewise, XML-only
clients will not get useful information from JSON-only servers.  However, a
complete server implementation (XML and JSON) would work with either new or
old clients.

That said, this draft does represent what I believe is the consensus for
going forward.  The minimum requirements would be JSON on the client and
server side, and support for the "resource" parameter.  This allows a client
to get everything it's seeking with a request like this:

     GET /.well-known/host-meta.json?resource=acct%3Acarol%40example.com
HTTP/1.1

Comments are certainly welcome!  I hope we're getting close with this
version :-)

Paul

Filename:   draft-ietf-appsawg-webfinger

Revision:   01

Title:            WebFinger

Creation date:    2012-10-19

WG ID:            appsawg

Number of pages: 26

URL:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-webfinger-01.txt

Status:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger

Htmlized:        http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-01

Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-webfinger-01

---

From: Evan Prodromou <[email-masked]>
Date: Sat, 20 Oct 2012 11:37:10 -0400

Paul,

Thanks for the update! I really like what I see; take the following 
notes as suggestions and not absolute rules.

  * It's long. With RFC 6415 as a basis, the requirements of this
    specification are actually quite small (add CORS, resource, and rel;
    JRD required, XRD optional). It would be nice if the document length
    and complexity reflected that.
  * The introduction in section 1 would be better if it ignored "finger"
    entirely. Just say what Webfinger does: lets a host define links and
    properties for an URI.
  * The first three paragraphs of section 3 are unnecessary and
    confusing. This is what references are for. Starting at "Thus the
    framework..." (without the "thus") is a lot clearer.
  * Section 4 is unnecessary and confusing. Also, as applications are
    built using Webfinger, it will probably become obsolete and
    incorrect. I think it should be struck entirely out.
  * Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
    behalf of clients. The client should determine the level of
    authenticity they need from the server. I suggest a SHOULD here,
    with similar language as RFC 6415 for
  * Section 5.2 says that servers MUST support "resource" "as a means of
    improving performance and reducing client complexity". I think the
    performance improvement is debatable, and maybe even the reduction
    in client complexity. So, maybe just strike this language? By which
    I mean: leave the requirement, but don't try to justify it.
  * Section 5.2 suggests that the server should literally make an HTTP
    request to fetch the LRDD link. That is the hard way to do it. Can
    we just assume that the server can figure out its own implementation
    details?
  * Section 5.2 recommends using host-meta.json, which I think is excellent.
  * Section 5.3 uses space-separated "rel" parameters. There is some
    precedent for using space separation for a single rel in HTML
    ("alternate feed"), which makes this a little tricky. How about
    comma (",") instead?
  * Section 5.4 should probably also call out the "tag" URI scheme.
  * Section 5.4 should make special mention of "http" and "https" URIs.
    There are other discovery methods that can be used with this kind of
    URI; is there a recommended order for using Webfinger versus, say,
    doing a HEAD request and looking at the Link: headers? Doing a GET
    request with Accept set to "text/html" and parsing for <meta> and
    <link> elements?
  * I'm not convinced we need "acct" rels (section 6). At the very
    least, the name is confusing w/r/t the acct: URI scheme.
  * Section 7 makes support for CORS a MUST and then turns around and
    said if you have a good reason not to support it, you SHOULD NOT. I
    suggest that support for CORS should just be a SHOULD. I can figure
    out myself whether I want to be the exception.
  * Section 8 should recommend a base representation for host and
    resource descriptors be available with no authentication, and
    enhanced representations available with authentication. Host meta is
    the initial introduction for clients and servers that don't
    otherwise know each other; there should always be some information
    available - even if it's just the information on how to authenticate
    to get more information.
  * Section 9 is implementation detail that should probably be out of
    scope. I realize that these configurations are why we support 3xx
    redirects, but maybe figuring out the topology of those redirects is
    best left as an exercise for implementers.
  * Section A seems unnecessary, since it's already covered in RFC 6415.
    Am I missing something?

Overall I think the protocol itself is great, with some minor tweaks 
between MUSTs and SHOULDs. Shortening the document will make it clearer 
and easier to implement.

-Evan

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 20 Oct 2012 18:34:33 -0400

Evan,

Please see my comments inline in green:

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Evan Prodromou
Sent: Saturday, October 20, 2012 11:37 AM
To: [email-masked]
Subject: Re: [apps-discuss] WebFinger Draft Updated -
draft-ietf-appsawg-webfinger-01

Paul,

Thanks for the update! I really like what I see; take the following notes as
suggestions and not absolute rules.

*	It's long. With RFC 6415 as a basis, the requirements of this
specification are actually quite small (add CORS, resource, and rel; JRD
required, XRD optional). It would be nice if the document length and
complexity reflected that.

PEJ: You're correct that it is a bit lengthy and you're right that the
length does not represent the complexity.  It is a simply protocol.  Much of
the length comes from examples and a desire to make each step unambiguous.
If there is material we should remove, we can do that, but I don't want to
reduce the length only for the sake of length and risk introducing
ambiguity.

PEJ: We could do that, but it only occupies a bit of space and helps explain
the history of the name.

PEJ: I agree that "thus" should go.  I've removed it from my copy.  But, I
do think the previous paragraphs are useful.

*	Section 4 is unnecessary and confusing. Also, as applications are
built using Webfinger, it will probably become obsolete and incorrect. I
think it should be struck entirely out.

PEJ: Section 4 is only examples.  There is nothing to make obsolete.  I
think it's always good to provide examples, as this helps people understand
better than just the normative wording.  I would really prefer to keep all
examples.

*	Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
behalf of clients. The client should determine the level of authenticity
they need from the server. I suggest a SHOULD here, with similar language as
RFC 6415 for 

PEJ: A server is not required to run using HTTPS, but I do think we should
require consistent behavior.  So, I picked "try HTTPS first and fall back to
HTTP".  We could change the wording to say that clients SHOULD try "HTTPS"
first, but I would prefer consistency in implementations.  What would be a
reason for not doing that?  What do others think on this one?

*	Section 5.2 says that servers MUST support "resource" "as a means of
improving performance and reducing client complexity". I think the
performance improvement is debatable, and maybe even the reduction in client
complexity. So, maybe just strike this language? By which I mean: leave the
requirement, but don't try to justify it.

PEJ: While I do agree that both objectives are reached, I will remove "as a
means of improving performance and reducing client complexity" as you
suggest because we do not need to give justification.  It's just required.
:-)

*	Section 5.2 suggests that the server should literally make an HTTP
request to fetch the LRDD link. That is the hard way to do it. Can we just
assume that the server can figure out its own implementation details?

PEJ: On my server, I don't make an HTTP query.  I just pull the data from
the database and return it.  I fully agree that how the server returns the
information is an implementation matter.  That said, we do not want a server
returning an LRDD link relation that forces the client to resolve it.  How
about this modified paragraph:

"It is not the responsibility of the WebFinger server to verify, for
example, that a URI pointing to a person's avatar is a valid URI.  If the
WebFinger server needs to query an LRDD resource to collect additional
resource-specific information, any errors (e.g., 500 or 404) MUST be ignored
by the server.  When a request for an LRDD fails, the server MUST NOT
attempt to augment missing resource information or return a "template" type
link relation to a client that utilizes the "resource" parameter.  Note that
a WebFinger server might be implemented such that all LRDD resource-specific
information can be resolved without issuing HTTP requests.  How a WebFinger
collects and expands such resource-specific link relations is an
implementation matter."

*	Section 5.2 recommends using host-meta.json, which I think is
excellent.
*	Section 5.3 uses space-separated "rel" parameters. There is some
precedent for using space separation for a single rel in HTML ("alternate
feed"), which makes this a little tricky. How about comma (",") instead?

PEJ: It was the fact that HTML uses a space-separated list that I specified
it this way.  I like consistency.  Is there a technical reason for not
trying to have a consistent syntax with HTML's <Link> syntax?

PEJ: My only concern is that it is an informational RFC, is it not?  I'd
prefer to avoid having normative text referring to informational material.

*	Section 5.4 should make special mention of "http" and "https" URIs.
There are other discovery methods that can be used with this kind of URI; is
there a recommended order for using Webfinger versus, say, doing a HEAD
request and looking at the Link: headers? Doing a GET request with Accept
set to "text/html" and parsing for <meta> and <link> elements?

PEJ: Trying to discuss how WebFinger might be used in relation to any other
discovery protocol will start getting messy and we will never get consensus
:-)

PEJ: The name should not be confusing, since the "acct" link relation is
intended to be used only with the "acct" URI. However, since we moved out
the "acct" URI, we could also move out the "acct" link relation text to a
different Internet Draft.  Do others have a preference? Any volunteers to
take that action?

*	Section 7 makes support for CORS a MUST and then turns around and
said if you have a good reason not to support it, you SHOULD NOT. I suggest
that support for CORS should just be a SHOULD. I can figure out myself
whether I want to be the exception.

PEJ: You're entirely right about that and that text bugged me, too.  There
was a strong desire for CORS to the point I was asked to make it a MUST, yet
there was the desire to allow an enterprise do something more restrictive.
I have no strong preference, myself, but I do think that if we make it a
SHOULD, though, that it will make it impossible to build a client in a
browser.  What does the group want here?

*	Section 8 should recommend a base representation for host and
resource descriptors be available with no authentication, and enhanced
representations available with authentication. Host meta is the initial
introduction for clients and servers that don't otherwise know each other;
there should always be some information available - even if it's just the
information on how to authenticate to get more information.

PEJ: This one is hard.  We might debate a year on what a baseline document
should contain :-)  Is a server name?  Is it a copyright date?  I think an
empty document should be OK. :-)  We'll know if WF is working simply based
on a valid response. I'd prefer to not make requirements on baseline
documents. 

*	Section 9 is implementation detail that should probably be out of
scope. I realize that these configurations are why we support 3xx redirects,
but maybe figuring out the topology of those redirects is best left as an
exercise for implementers.

PEJ: This is all new text because there were folks who said we need to have
a means of allowing the WF services to be hosted.  We talked about using 3xx
and we talked about introducing a URI DNS record.  The latter is a cool
idea, but the spec is not finalized.  It also introduces one more code path
in the client.  The 3xx must already be handled.  We could make this section
non-normative if folks prefer, but I think having this content will help
people understand how they can re-locate and outsource WF services.

PEJ: That's part of why it is in an appendix.  I wanted to have this here
since it provides an XRD example of the exact same example in Section 4.1.
I thought this might be useful for people.  Even if they do not implement
XRD in a client or server, it helps to illustrate in this document what an
RFC 6415-compliant server would do.  I could remove it, but I think it's
educational and it's already marked as non-normative.

Overall I think the protocol itself is great, with some minor tweaks between
MUSTs and SHOULDs. Shortening the document will make it clearer and easier
to implement.

PEJ: I do hope we're getting closer.  I'm challenged to see how we can make
it much shorter and also keep it in a form that makes it perfectly clear to
implemeners.  (Of course, somebody will still misinterpret something, but I
do aim to avoid misinterpretation.)  Consider my comments above.  I've made
a few changes and I could try to get a -02 published before the deadline
Monday.

PEJ: Thanks for the thorough review!

Paul

-Evan

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 21 Oct 2012 01:05:53 +0200

On 20 October 2012 17:37, Evan Prodromou <[email-masked]> wrote:

>  Paul,
>
> Thanks for the update! I really like what I see; take the following notes
> as suggestions and not absolute rules.
>
>    - It's long. With RFC 6415 as a basis, the requirements of this
>    - The introduction in section 1 would be better if it ignored "finger"
>     - The first three paragraphs of section 3 are unnecessary and
>     - Section 4 is unnecessary and confusing. Also, as applications are
>    - Section 5.1 makes the order of queries (HTTPS, HTTP) a MUST on
>    they need from the server. I suggest a SHOULD here, with similar language
>    as RFC 6415 for
>     - Section 5.2 says that servers MUST support "resource" "as a means
>    of improving performance and reducing client complexity". I think the
>    performance improvement is debatable, and maybe even the reduction in
>    client complexity. So, maybe just strike this language? By which I mean:
>    leave the requirement, but don't try to justify it.
>     - Section 5.2 suggests that the server should literally make an HTTP
>    - Section 5.2 recommends using host-meta.json, which I think is
>    excellent.
>    - Section 5.3 uses space-separated "rel" parameters. There is some
>     - Section 5.4 should probably also call out the "tag" URI scheme.
>    - Section 5.4 should make special mention of "http" and "https" URIs.
>    There are other discovery methods that can be used with this kind of URI;
>    is there a recommended order for using Webfinger versus, say, doing a HEAD
HTTP GET is generally recommended to get more information from an HTTP
URI.  HEAD may not contain the information you need.  Of course, it may
become popular to deference an HTTP URI using webfinger.  Though there may
be issues with the correct response codes, consistency of information etc.

>
>    - I'm not convinced we need "acct" rels (section 6). At the very
>     - Section 7 makes support for CORS a MUST and then turns around and
>     - Section 8 should recommend a base representation for host and
>     - Section 9 is implementation detail that should probably be out of
>    redirects, but maybe figuring out the topology of those redirects is best
>    left as an exercise for implementers.
>    - Section A seems unnecessary, since it's already covered in RFC 6415.
>    Am I missing something?
>
> between MUSTs and SHOULDs. Shortening the document will make it clearer and
> easier to implement.
>
> -Evan
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 21 Oct 2012 11:13:53 +0200

On 21 October 2012 09:37, Christian Weiske <[email-masked]> wrote:

> Hello Paul,
>
>
> >> *    Section 7 makes support for CORS a MUST and then turns
> >> around and said if you have a good reason not to support it, you
> >> SHOULD NOT. I suggest that support for CORS should just be a SHOULD.
> >> I can figure out myself whether I want to be the exception.
> > PEJ: You're entirely right about that and that text bugged me, too.
> > There was a strong desire for CORS to the point I was asked to make
> > it a MUST, yet there was the desire to allow an enterprise do
> > something more restrictive. I have no strong preference, myself, but
> > I do think that if we make it a SHOULD, though, that it will make it
> > impossible to build a client in a browser.  What does the group want
> > here?
>
> Not supporting CORS does not make the data any more secure. If someone
> wants security for their intranet, they have to implement real security
> measurements, e.g. based on IP whitelists.
>
> Please leave CORS support a MUST.
>

+1

>
> --
> Regards/Mit freundlichen Grüßen
> Christian Weiske
>
> -=≡ Geeking around in the name of science since 1982 ≡=-
>

---

From: Christian Weiske <[email-masked]>
Date: Sun, 21 Oct 2012 09:37:28 +0200

Hello Paul,

---

From: Blaine Cook <[email-masked]>
Date: Mon, 22 Oct 2012 04:49:28 -0400

Preamble: This spec looks absolutely nothing like I imagined
Webfinger, which was, and was meant to be, a light-weight and simple
method to look up resource data for an email address. I'm not happy
with this *at all*, and probably won't implement it, either client or
server. I've achieved the login handling using a much simpler (but
less powerful and intentful) heuristic that I'll talk about soon.

1. +1 on CORS support.

2. Since I appear to have fully and completely lost the argument on
structuring Webfinger like DNS (despite the many positive reactions
outside this list I've received regarding the alternate proposal), two
proposals:

2a. Drop the template URI stuff.
2b. Have only one method for following redirects. If the participants
in this process think that it's OK to require static hosts to use HTTP
semantics (30x) to redirect /.well-known/host-meta, then use that
everywhere, since the hard place to do that is for static hosts –
anyone responding dynamically requests can trivially issue HTTP
redirects, rather than generating JSON.

Some notes on redirects:

– The redirect code MUST NOT be 301. This would make it impossible
under some circumstances for the host to regain control over lookups,
and is *never* the correct behaviour from a normative standpoint
(where the behaviour being enabled is like DNS – you can *never*
permanently redirect a DNS lookup).
– Clients MUST treat 301 response codes as 307.
– The redirect code SHOULD be 307, and the server SHOULD use
appropriate HTTP caching semantics.

Note that we are actually getting *worse* performance characteristics
out of this scheme for hosts using 3rd party webfinger providers,
since each request to a different user results in two requests; one to
the base domain, and one to the 3rd party server.

Drop all the redirect JRD stuff.

Hope that's helpful.

b.

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 22 Oct 2012 14:18:27 -0400

Blaine,

> Preamble: This spec looks absolutely nothing like I imagined Webfinger,
> which was, and was meant to be, a light-weight and simple method to look
> up resource data for an email address. I'm not happy with this *at all*,
> and probably won't implement it, either client or server. I've achieved
> the login handling using a much simpler (but less powerful and intentful)
> heuristic that I'll talk about soon.

How can you say that when the current WebFinger draft actually makes RFC 6415 even simpler than it was before.  Now, JSON is the only MTI format and a client can get everything it's looking for with a simple query like

 GET /.well-known/host-meta.json?resource=acct%3Abob%40example.com HTTP/1.1

That returns the complete resource descriptor.  The server-side code is also simple.  My code just outputs data from a database that matches the URI "acct:[email-masked]".

It seems pretty light-weight to me, yet flexible enough to allow one to convey a list of link relations.
 
> 1. +1 on CORS support.

There seems to be a lot of support to keep that.
 
> outside this list I've received regarding the alternate proposal), two

WebFinger is structured the way it was described in Eran's posts, the WebFinger list, and RFC 6415.  I don't recall exactly what your proposal was now, but there were proposals to use DNS records like "URI" type records.  I like that idea, but it's a chicken and egg problem.  Many solutions require more complexity on the client, and we tried to make the client simpler.
 
> 2a. Drop the template URI stuff.

That comes from RFC 6415 and a server would likely expose at least one link of type "template" if the client queries the host-meta resource without using the "resource" parameter.  Name, it would likely send the "lrdd" template type.  However, a client will NEVER see the templates if it uses the "resource" parameter.  I think that is important, because that makes the client code simpler.

> 2b. Have only one method for following redirects. If the participants in
> this process think that it's OK to require static hosts to use HTTP
> everywhere, since the hard place to do that is for static hosts – anyone
> responding dynamically requests can trivially issue HTTP redirects,
> rather than generating JSON.

Can you clarify the point of concern?  The only redirection mechanism proposed in the spec is 3xx.  What text is troubling you?

> Some notes on redirects:
> 
> – The redirect code MUST NOT be 301. This would make it impossible under
> some circumstances for the host to regain control over lookups, and is
> *never* the correct behaviour from a normative standpoint (where the
> behaviour being enabled is like DNS – you can *never* permanently
> redirect a DNS lookup).

I would argue that this should be a deployment matter. The only thing we say in the spec is that clients need to follow redirection on 301, 302, or 307.  (That's what RFC 6415 says, and it's reasonable.  Browsers do that.)

> – Clients MUST treat 301 response codes as 307.

We cannot require this.  Browsers, for example, are in control of that behavior, not the WF client running in the browser.  Also, 301 and 307 have different semantics.

> – The redirect code SHOULD be 307, and the server SHOULD use appropriate
> HTTP caching semantics.

While using 307 might be the right way to deploy, that is (again) a deployment matter.  I'll note that many web sites still use 302, not 307.  WF clients should accept any of the listed 3xx codes.
 
> out of this scheme for hosts using 3rd party webfinger providers, since
> each request to a different user results in two requests; one to the
> base domain, and one to the 3rd party server.

For those hosting their own WebFinger server (and it really is trivial code), performance is not an issue.  There would be a single request/response.

Large companies will likely run their own servers and could respond directly to requests.  For large companies that want to redirect queries away from example.com/.well-known/host-meta.json to webfinger.example.com/wherever/ (for example) could (and probably should) use 301 replies to encourage clients to redirect more optimally.  This would be a deployment option we should allow.

Where a domain owner has requests coming in from many distinct clients and they use 3xx to redirect to a WebFinger provider, we end up with two request/response exchanges: one for the original request and one to the new location.  But, this would only be necessary if the domain owner does not want to point the A record for their domain to the WebFinger provider.  For those who more-or-less host the whole host (or domain) where the WF service exists, it's not an issue.  The extra exchange will come in only where only the WF service is hosted elsewheer.

In any case, there are many possible deployment models, each with pros and cons.
 
> Drop all the redirect JRD stuff.

Are you referring to Section 9 or somewhere else?  I think there is value in having Section 9 since it describes some hosting options.  It could perhaps be made non-normative, but we do make the normative requirement for clients to handle 3xx responses.  RFC 6415 made that optional for clients.

> Hope that's helpful.

Any input is helpful.  We need to get on the same page and agree on how this should work.  The current draft is not a significant departure from what was defined already, and it wasn't intended to be.  I'd summarize it as RFC 6415 - XML + JRD + "resource" parameter.  I'm actually surprised you had such a negative reaction to the text. :-)

Paul
 
> >> > something more restrictive. I have no strong preference, myself,
> >> > but I do think that if we make it a SHOULD, though, that it will
> >> > make it impossible to build a client in a browser.  What does the
> >> > group want here?
> >>
> >> Not supporting CORS does not make the data any more secure. If
> >> someone wants security for their intranet, they have to implement
> >> real security measurements, e.g. based on IP whitelists.
> >>

---

From: Melvin Carvalho <[email-masked]>
Date: Sat, 27 Oct 2012 18:31:18 +0200

> Drop all the redirect JRD stuff.

I've been thinking about this a fair bit.

Webfinger is now in its fourth year and one thing that has remained
constant is that it would be valuable on the internet to perform discovery
on an email address to get more information such as blog address, homepage
etc.

I thought we had a consensus to use JRD and drop everything else.  I
strongly think this should be the stance of the spec.  There is one
interesting aspect to this.  JRD has an advantage over XRD in that you can
have more than one subject per document, whereas in XRD you would be in
(willful) violation of the XML Schema.  It turns out that this pretty much
makes both XRD and RDF equivalents modulo a regular expression.  That is
quite exciting and brings two worlds and big ecosystems together.

Regarding XRD and content negotiation.  If you want XRD you should request
it in the header.

Regarding the default serialization.  There's one important aspect here.
That is that browsers have no way of setting a content type.  So the any
default should be browser friendly if specified.  As far as I can see that
leaves RDFa or schema.org etc. as the stand out choices.  I dont think it's
necessary to specify a default in this version of the spec.

It's worth noting that the problem to be solved, ie to query a data
document to some results is solved both in the specific and general case,
using a query language such as SPARQL.  I suspect the argument for not
using SPARQL here is that it may be overkill for the use case required.
Therefore you build a query structure into the spec as a kind of
simplification.  But if you want to simplify the general case, perhaps SWD
is the best candidate we've seen, or some tweak of that.

Regarding having any URI as the input, this is an example of good
engineering.  However, is it really practical?  Does the spec show how to
find a well known location for *any* URI, or just a subset?  What about
sip: xmpp: tel: etc.  In particular I think tel: would break the spec, as
would many other URIs (essentially the non DNS based ones).

That also leads to the thorny issue of http: ... do we really want yet
another way to dereference an HTTP URI other than GET?   What about
response codes, sync of data, attack surfaces?

On the whole I think paul has done a great job in difficult circumstances,
with lots of requests, from all angles.  I hope we can come to a consensus
soon and solve the core use case of discovering information on an email
address at web scale.

---

From: William Mills <[email-masked]>
Date: Sat, 27 Oct 2012 18:11:14 -0700 (PDT)

Various people have said "just go with JRD, it's so much better than XRD", but this spec is still trying to stirke a balance here since there is already and installed base under the current WF XRD as MTI spec.  There has been understandable reticence to declaring existing implementations to be no longer compliant with the spec.  I am strongly opposed to morphing WF into something that does that.

I am *highly* in favor of simplicity, and I think we're moving to a more complex thing that will make the trivial case more work to support.

-bill

>________________________________
> From: Melvin Carvalho <[email-masked]>
>To: [email-masked] 
>Cc: [email-masked] 
>Sent: Saturday, October 27, 2012 9:31 AM
>Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01
> 
>
>
>
>
>Webfinger is now in its fourth year and one thing that has remained constant is that it would be valuable on the internet to perform discovery on an email address to get more information such as blog address, homepage etc.
>
>I thought we had a consensus to use JRD and drop everything else.  I strongly think this should be the stance of the spec.  There is one interesting aspect to this.  JRD has an advantage over XRD in that you can have more than one subject per document, whereas in XRD you would be in (willful) violation of the XML Schema.  It turns out that this pretty much makes both XRD and RDF equivalents modulo a regular expression.  That is quite exciting and brings two worlds and big ecosystems together.
>
>Regarding XRD and content negotiation.  If you want XRD you should request it in the header.  
>
>Regarding the default serialization.  There's one important aspect here.  That is that browsers have no way of setting a content type.  So the any default should be browser friendly if specified.  As far as I can see that leaves RDFa or schema.org etc. as the stand out choices.  I dont think it's necessary to specify a default in this version of the spec.
>
>It's worth noting that the problem to be solved, ie to query a data document to some results is solved both in the specific and general case, using a query language such as SPARQL.  I suspect the argument for not using SPARQL here is that it may be overkill for the use case required.  Therefore you build a query structure into the spec as a kind of simplification.  But if you want to simplify the general case, perhaps SWD is the best candidate we've seen, or some tweak of that.
>
>Regarding having any URI as the input, this is an example of good engineering.  However, is it really practical?  Does the spec show how to find a well known location for *any* URI, or just a subset?  What about sip: xmpp: tel: etc.  In particular I think tel: would break the spec, as would many other URIs (essentially the non DNS based ones).  
>
>That also leads to the thorny issue of http: ... do we really want yet another way to dereference an HTTP URI other than GET?   What about response codes, sync of data, attack surfaces?  
>
>On the whole I think paul has done a great job in difficult circumstances, with lots of requests, from all angles.  I hope we can come to a consensus soon and solve the core use case of discovering information on an email address at web scale.
> 
>
>>Hope that's helpful.
>>
>>b.
>>
>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 22:25:01 -0400

Melvin,

> Webfinger is now in its fourth year and one thing that has
> remained constant is that it would be valuable on the internet to
> perform discovery on an email address to get more information
> such as blog address, homepage etc.

Fully agree there!
 
> I thought we had a consensus to use JRD and drop everything else.
> I strongly think this should be the stance of the spec.

The only mandatory format is JRD now.  XRD still exists in RFC 6415 and there are servers that use it.  We should not ignore it entirely, so we speak about the fact that it already exists today.  Going forward, though, no new implementation would be required to support XRD.

> There is
> one interesting aspect to this.  JRD has an advantage over XRD in
> that you can have more than one subject per document, whereas in
> XRD you would be in (willful) violation of the XML Schema.  It
> turns out that this pretty much makes both XRD and RDF
> equivalents modulo a regular expression.  That is quite exciting
> and brings two worlds and big ecosystems together.

The JRD syntax does NOT allow more than one Subject or Expires.  If a JavaScript processor saw this:
   { "Subject" : "s1", "Subject" : "s2" }

Then it would likely replace the value of "Subject" it saw previously with "s2". I don't know what the standard says in this case, but you will not have access to two "Subject" values.  So, it is entirely consistent with XML.

> should request it in the header.  

You can always request a format using standard content negotiation.  However, we need a default value when anything is accepted or something unknown is requested.  So, we have these as default values:
   /.well-known/host-meta - defaults to XRD (iff XRD is supported, else JRD)
   /.well-known/host-meta.json - defaults to JRD

We are recommending use of host-meta.json, though a client capable of accepting either and/or preferring XRD could use host-meta.  Trying not to break what's there any more than necessary.  Be mindful, too, that WebFinger does not replace RFC 6415.

> Regarding the default serialization.  There's one important
> aspect here.  That is that browsers have no way of setting a
> content type.

That's not true.  This will do it:
  request.setRequestHeader("Accept", "application/xml");

(Where "request" is an XML HTTP Request object.)

And, one can check the return type like this:
  Request.getResponseHeader("Content-Type");

That said, there might be some who find the work to set the "Accept" header just one too many lines of code ;-) I don't know.  I always use the Accept header when I write web interface code.

Nonetheless, we do have defaults specified "just in case" (or to help the lazy programmer).

> So the any default should be browser friendly if
> specified.  As far as I can see that leaves RDFa or schema.org
> etc. as the stand out choices.  I dont think it's necessary to
> specify a default in this version of the spec.

I'm confused. You are suggesting that RDFa should be a default?  One could certainly build a server to return RDFa or anything else, but we'd have to specify exactly what the response should look like.  Given folks wanted one format we go forward with, I do not dare want to suggest opening that can of worms again :-)

> It's worth noting that the problem to be solved, ie to query a
> data document to some results is solved both in the specific and
> general case, using a query language such as SPARQL.  I suspect
> the argument for not using SPARQL here is that it may be overkill
> for the use case required.  Therefore you build a query structure
> into the spec as a kind of simplification.  But if you want to
> simplify the general case, perhaps SWD is the best candidate
> we've seen, or some tweak of that.

WebFinger is really simple. It would allow one to take an identifier like "acct:[email-masked]" and transform that into a set of link relations with a single request to the server.  I think that simplicity, plus the JSON format, is what people want/need/desire/prefer with a simple web discovery mechanism.

> engineering.  However, is it really practical?  Does the spec
> show how to find a well known location for *any* URI, or just a
> subset?  What about sip: xmpp: tel: etc.  In particular I think
> tel: would break the spec, as would many other URIs (essentially
> the non DNS based ones).  

Tel URIs are not useful for WebFinger since, as you note, there is no associated host information.  However, we should allow any URI that does have a domain part.  After all, the purpose is to go to the server and say "tell me about this URI".  If the server knows, it will provide an answer.  If the server has no information on the URI, it will return a 404.

We should allow "sip:" as that might be used to tell my SIP client how to configure itself (e.g., the address of the outbound proxy).  Same argument goes for mailto:, xmpp:, h323:, etc.

> That also leads to the thorny issue of http: ... do we really
> want yet another way to dereference an HTTP URI other than GET?
> What about response codes, sync of data, attack surfaces?  

What's wrong with using "http" ones?  This might be used to provide author, copyright, and contact information for the author of a blog article specified article at the HTTP address.  It might also be used as a means of converting identifiers into other identifiers.  For example, if OpenID did not already have a discovery mechanism, then you can imagine how an OpenID identifier could be queried using WebFinger to find the OpenID Provider URL.

This is not dereferencing an HTTP URI, but discovering information *about* the URI.  This is quite different.

> On the whole I think paul has done a great job in difficult
> circumstances, with lots of requests, from all angles.  I hope we
> can come to a consensus soon and solve the core use case of
> discovering information on an email address at web scale.

Thanks for the kind words.  It has been an interesting ride, starting way back when I asked on the OpenID lists whether folks had considered using an email ID rather than an HTTP URL.  I got blasted for suggesting that! :-)  But, I was persistent (foolish?) and asked some time later and people pointed me to the WebFinger work.  When I first saw the concept, I fell in love with it.  So, credit for the work goes out to a lot of people other than me.  It's not my concept at all, but I've been trying my best to reach agreement so that we can have spec we can all implement. I think this will be a very useful service on the Internet and inside corporate networks.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 27 Oct 2012 22:37:48 -0400

Bill,

Since JRD is the only MTI format, how is this morphing into something complex?  In this most recent draft (-02), we’ve moved away from requiring both to requiring only JRD.  That’s true of both clients and servers.

Paul

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Saturday, October 27, 2012 9:11 PM
To: Melvin Carvalho; [email-masked]
Cc: [email-masked]
Subject: Re: [apps-discuss] WebFinger Draft Updated - draft-ietf-appsawg-webfinger-01

-bill

  _____  

 

1. +1 on CORS support.

Some notes on redirects:

Regarding the default serialization.  There's one important aspect here.  That is that browsers have no way of setting a content type.  So the any default should be browser friendly if specified.  As far as I can see that leaves RDFa or schema.org <http://schema.org/>  etc. as the stand out choices.  I dont think it's necessary to specify a default in this version of the spec.

Hope that's helpful.

b.

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 28 Oct 2012 12:42:10 +0100

On 28 October 2012 03:25, Paul E. Jones <[email-masked]> wrote:

> The only mandatory format is JRD now.  XRD still exists in RFC 6415 and
> there are servers that use it.  We should not ignore it entirely, so we
> speak about the fact that it already exists today.  Going forward, though,
> no new implementation would be required to support XRD.
>
> > There is
> Then it would likely replace the value of "Subject" it saw previously with
> "s2". I don't know what the standard says in this case, but you will not
> have access to two "Subject" values.  So, it is entirely consistent with
> XML.
>

I think what you would do in the json is have several objects each with a
single subject, it's essentially entity attribute value which is the
generalization of but rdf and xrd.

The only real difference between XRD and RDF is that (according to XML
schema) recommends one object per document, but RDF is open ended.  JSON
can easily handle mulbiple objects per document which means that one model
can be translated to another and vice versa.

>
> > Regarding XRD and content negotiation.  If you want XRD you
> > should request it in the heade
>
> You can always request a format using standard content negotiation.
>  However, we need a default value when anything is accepted or something
> unknown is requested.  So, we have these as default values:
> We are recommending use of host-meta.json, though a client capable of
> accepting either and/or preferring XRD could use host-meta.  Trying not to
> break what's there any more than necessary.  Be mindful, too, that
> WebFinger does not replace RFC 6415.
>

When dealing with a relatively bespoke format like xrd, the client should
always set the content type, imho.

> That said, there might be some who find the work to set the "Accept"
> header just one too many lines of code ;-) I don't know.  I always use the
> Accept header when I write web interface code.
>

Ah yes, what I meant to say was that the browser doesnt normally send a
content type when clicking on a hyperlink.

Accept header is too many lines of code, it should only be 1?  Hopefully
something even 'lazy' programmers can handle :)

> I'm confused. You are suggesting that RDFa should be a default?  One could
> certainly build a server to return RDFa or anything else, but we'd have to
> specify exactly what the response should look like.  Given folks wanted one
> format we go forward with, I do not dare want to suggest opening that can
> of worms again :-)
>

No, I think that there should be no default set at all.  The point I was
making above is that the main benefit from a default content type is for
the case where the client is *unable* to easily set it and that is the case
of the browser hyperlink.  So since that's not part of the use cases, it
need not be covered now.  But say in future, there may be a use case
oriented around clicking from a hyperlink to a webfinger record, you never
know ..

> WebFinger is really simple. It would allow one to take an identifier like "
> acct:[email-masked]" and transform that into a set of link
> relations with a single request to the server.  I think that simplicity,
> plus the JSON format, is what people want/need/desire/prefer with a simple
> web discovery mechanism.
>

Largely agree, tho I'm just pointing out the general case has a query
language, therefore the high level goals of webfinger can be oriented to
the practical cases (eg email discovery) rather than the general.  Was
really just a side comment :)

> Tel URIs are not useful for WebFinger since, as you note, there is no
> associated host information.  However, we should allow any URI that does
> have a domain part.  After all, the purpose is to go to the server and say
> "tell me about this URI".  If the server knows, it will provide an answer.
>  If the server has no information on the URI, it will return a 404.
>

Sure, tho im not sure the language in the spec, but I guess it should point
out the WF is only oriented at those that have a domain part, or list the
ones that are valid?

>
> We should allow "sip:" as that might be used to tell my SIP client how to
> configure itself (e.g., the address of the outbound proxy).  Same argument
> goes for mailto:, xmpp:, h323:, etc.
>
> What's wrong with using "http" ones?  This might be used to provide
> author, copyright, and contact information for the author of a blog article
> specified article at the HTTP address.  It might also be used as a means of
> converting identifiers into other identifiers.  For example, if OpenID did
> not already have a discovery mechanism, then you can imagine how an OpenID
> identifier could be queried using WebFinger to find the OpenID Provider URL.
>

This is possible but there are well established methods for getting
information about a URI.  Essentially that's what the last 10 years of work
by the w3c has focused on.

> Thanks for the kind words.  It has been an interesting ride, starting way
> back when I asked on the OpenID lists whether folks had considered using an
> email ID rather than an HTTP URL.  I got blasted for suggesting that! :-)
>  But, I was persistent (foolish?) and asked some time later and people
> pointed me to the WebFinger work.  When I first saw the concept, I fell in
> love with it.  So, credit for the work goes out to a lot of people other
> than me.  It's not my concept at all, but I've been trying my best to reach
> agreement so that we can have spec we can all implement. I think this will
> be a very useful service on the Internet and inside corporate networks.
>

+1

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Oct 2012 15:39:23 -0400

Melvin

On Sun, 28 Oct 2012 12:42:10 +0100, Melvin Carvalho wrote:
> On 28 October 2012 03:25, Paul E. Jones  wrote:
>
>> Melvin,
>>
>> The only mandatory format is JRD now.  XRD still exists in RFC
>> 6415 and there are servers that use it.  We should not ignore it
>> entirely, so we speak about the fact that it already exists today.
>>  Going forward, though, no new implementation would be required to
>> support XRD.
>>
>> > There is
>> Then it would likely replace the value of "Subject" it saw
>> previously with "s2". I dont know what the standard says in this
>> case, but you will not have access to two "Subject" values.  So, it
>> is entirely consistent with XML.
>
> I think what you would do in the json is have several objects each
> with a single subject, its essentially entity attribute value which 
> is
> the generalization of but rdf and xrd. 

I do not think we should be redefining JRD at this point.  More 
importantly, I do not believe we need to. There are "aliases" and I 
think that is sufficient to serve the purpose.  The subject line should 
be the entity queried.

> schema) recommends one object per document, but RDF is open ended. 
> JSON can easily handle mulbiple objects per document which means that
> one model can be translated to another and vice versa. 
>   
>
>>  However, we need a default value when anything is accepted or
>> something unknown is requested.  So, we have these as default
>> values:
>> We are recommending use of host-meta.json, though a client capable
>> of accepting either and/or preferring XRD could use host-meta.
>>  Trying not to break whats there any more than necessary.  Be
>> mindful, too, that WebFinger does not replace RFC 6415.
>
> When dealing with a relatively bespoke format like xrd, the client
> should always set the content type, imho. 

You mean clients should always set the Accept header?  I would agree, 
but people rarely do.  Usually, it's set to */* or some such.  In any 
case, the header is there and we do mention that it can be set.
   
>> .  That is that browsers have no way of setting a
>> > content type.
>>
>> Thats not true.  This will do it:
>> That said, there might be some who find the work to set the
>> "Accept" header just one too many lines of code ;-) I dont know.  I
>> always use the Accept header when I write web interface code.
>>
>> Ah yes, what I meant to say was that the browser doesnt normally
>> send a content type when click
> rlink.
>
> Accept header is too many lines of code, it should only be 1? 
> Hopefully something even lazy programmers can handle :)

It is one line of code.  I'm confused :-)

This is the one line that would be set in JavaScript:
   request.setRequestHeader("Accept", "application/json");

>  > specified.  As far as I
>> as the stand out choices.  I dont think its necessary to
>> Im confused. You are suggesting that RDFa should be a default?
>>  One could certainly build a server to return RDFa or anything
>> else, but wed have to specify exactly what the response should look
>> like.  Given folks wanted one format we go forward with, I do not
>> dare want to suggest opening that can of worms again :-)
>>
>> No, I think that there should be no default set at all.  The point
>> I was making above is that the main benefit from a default content
>> type is for the case where the client is *unable* to easily
> at is the case of the browser hyperlink.  So since thats not part of
> the use cases, it need not be covered now.  in futuBut say re, there
> may be a use case oriented around clicking from a hyperlink to a
> webfinger record, you never know ..

You really think the resources should have no default format?

We really must specify what the default value should be.  I think the 
specified defaults in the document are reasonable and will lead to 
consistent implementations.  If the "Accept" header has "*/*" (which is 
fairly common practice), then at least we can predict the results.

>> Tel URIs are not useful for WebFinger since, as you note, there is
>> no associated host information.  However, we should allow any URI
>> that does have a domain part.  After all, the purpose is to go to
>> the server and say "tell me about this URI".  If the server knows,
>> it will provide an answer.  If the server has no information on the
>> URI, it will return a 404.
>>
> Sure, tho im not sure the language in the spec, but I guess it
> should point out the WF is only oriented at those that have a domain
> part, or list the ones that are valid?

I think this is pretty clear in the spec already, if not obvious on the 
face of it.  For example, bullet point 3 in Section 3 speaks of "URI at 
the host" and gives examples.  However, if we add text, I think the 
right place would be Section 5.4 where we talk about WebFinger and URIs. 
Perhaps we could add a sentence to the end of the first paragraph where 
we talk about WebFinger being URI scheme agnostic?  I'm not sure what to 
add, though.  Suggestions?
   
>> This is not dereferencing an HTTP URI, but discovering information
>> *about* the URI.  This is quite different.
>>
> information about a URI.  Essentially thats what the last 10 years
> of work by the w3c has focused on.

This could become a politically charged issue, but what comes to mind 
is "the wonderful thing about standards is that there are so many from 
which to choose" :-)

Perhaps another thing that comes to mind is "pick the right tool for 
the job".  If I want to know how about acct:[email-masked], I'm 
going to use WF. If I want to know how to configure my email client, I 
might use WF with mailto:[email-masked], but there might be a 
better set of tools.  We have a spec that defines this via DNS.  WF 
might prove to be the better tool, but there might be something else 
more preferred.

Note: if I missed anything, feel free to repeat it.  I can see your 
email in my client OK, but when I reply, it's challenging unless I use 
color-coding in Outlook.  So, I switched to a different email client and 
then it did not always show your responses clearly to me.  I like HTML 
for email, but it does make it hard for inline commenting, at least with 
Outlook.  Wish Microsoft would improve that. :-/

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Sun, 28 Oct 2012 20:49:49 +0100

On 28 October 2012 20:39, Paul E. Jones <[email-masked]> wrote:

>> with a single subject, its essentially entity attribute value which is
>>
> importantly, I do not believe we need to. There are "aliases" and I think
> that is sufficient to serve the purpose.  The subject line should be the
> entity queried.
>

Sure

> You mean clients should always set the Accept header?  I would agree, but
> people rarely do.  Usually, it's set to */* or some such.  In any case, the
> header is there and we do mention that it can be set.
>

I mean the spec should say that the client should set accept the accept
header.  If they dont follow that advice behaviour will be unspecified.

>>>   request.setRequestHeader("**Accept", "application/xml");
>>>
>>>   Request.getResponseHeader("**Content-Type");
>>>
>   request.setRequestHeader("**Accept", "application/json");
>

Yes similar in PHP etc.

> fairly common practice), then at least we can predict the results.

No problem with JRD being the default in practice.  Relying on defaults
such as */* can simply be out of scope of the spec.

> face of it.  For example, bullet point 3 in Section 3 speaks of "URI at the
> host" and gives examples.  However, if we add text, I think the right place
> would be Section 5.4 where we talk about WebFinger and URIs. Perhaps we
> could add a sentence to the end of the first paragraph where we talk about
> WebFinger being URI scheme agnostic?  I'm not sure what to add, though.
>  Suggestions?
>

Unsure on this one.  I guess if the reviewers at the IETF think it's self
evident, that should be fine.  There's so many URI schemes today that it's
hard to even know if there are grey areas on this one.

> This could become a politically charged issue, but what comes to mind is
> "the wonderful thing about standards is that there are so many from which
> to choose" :-)
>

lol ... well there's always a degree of politics in standards and discovery
has been one of the more contentious ones ... the point i make above is
that the different serializations are very close to each other, so
hopefully we can all get along! :)

it really just related to dereferencing an HTTP URI ... if webfinger is one
more way to do that, then so much the better, I guess more choice doesnt
hurt, but the W3C has innovated extensively in this space, as it's a core
focus of that standards body

>
> Perhaps another thing that comes to mind is "pick the right tool for the
> job".  If I want to know how about acct:[email-masked], I'm going
> to use WF. If I want to know how to configure my email client, I might use
> WF with mailto:[email-masked], but there might be a better set of
> tools.  We have a spec that defines this via DNS.  WF might prove to be the
> better tool, but there might be something else more preferred.
>

sure

>
> Note: if I missed anything, feel free to repeat it.  I can see your email
> in my client OK, but when I reply, it's challenging unless I use
> then it did not always show your responses clearly to me.  I like HTML for
> email, but it does make it hard for inline commenting, at least with

oops apologies, thanks for pointing this out, I was not aware of that ... I
tend to use the gmail web client for most mail ... I'll try to ensure my
text is more readable going forward!

---

From: Goix Laurent Walter <[email-masked]>
Date: Mon, 29 Oct 2012 16:04:00 +0100

[snip]

I think this is pretty clear in the spec already, if not obvious on the face of it.  For example, bullet point 3 in Section 3 speaks of "URI at the host" and gives examples.  However, if we add text, I think the right place would be Section 5.4 where we talk about WebFinger and URIs. Perhaps we could add a sentence to the end of the first paragraph where we talk about WebFinger being URI scheme agnostic?  I'm not sure what to add, though.  Suggestions?

Unsure on this one.  I guess if the reviewers at the IETF think it's self evident, that should be fine.  There's so many URI schemes today that it's hard to even know if there are grey areas on this one.

[walter] I guess the current "uri scheme-agnostic" text in 5.4 is fine. in general i would avoid formally restricting URI types through white- or blacklisting. This would allow a richer usage of this spec imo although it may not always be "meaningful". Specifically on tel URIs I'd like to recall the enum draft [1] that aims at converting phone numbers into accounts to further perform webfinger requests. Yet in an alternative approach a "default" server (eg whose name is built based on mobile network information) could probably handle wf requests to tel: URIs, whatever process rules are applied at the server to answer or not that query and how (eg to "proxy" the request to the authoritative server/operator for that number)

[1] http://tools.ietf.org/html/draft-goix-appsawg-enum-acct-uri-00
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

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

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Oct 2012 12:22:10 -0400

Walter,

What you say is certainly true.  I believe that most service providers
operate their own ENUM services (if they use ENUM at all), so there is, in
effect, a default service.  The same could be extended to WF.  So, you make
a valid point.

And, of course, I do like the mapping to acct URIs :-)

Paul

From: Goix Laurent Walter [mailto:[email-masked]] 
Sent: Monday, October 29, 2012 11:04 AM
To: Melvin Carvalho; Paul E. Jones
Cc: [email-masked]; [email-masked]
Subject: R: [apps-discuss] WebFinger Draft Updated -
draft-ietf-appsawg-webfinger-01

[snip] 

I think this is pretty clear in the spec already, if not obvious on the face
of it.  For example, bullet point 3 in Section 3 speaks of "URI at the host"
and gives examples.  However, if we add text, I think the right place would
be Section 5.4 where we talk about WebFinger and URIs. Perhaps we could add
a sentence to the end of the first paragraph where we talk about WebFinger
being URI scheme agnostic?  I'm not sure what to add, though.  Suggestions?

[walter] I guess the current “uri scheme-agnostic” text in 5.4 is fine. in
general i would avoid formally restricting URI types through white- or
blacklisting. This would allow a richer usage of this spec imo although it
may not always be “meaningful”. Specifically on tel URIs I’d like to recall
the enum draft [1] that aims at converting phone numbers into accounts to
further perform webfinger requests. Yet in an alternative approach a
“default” server (eg whose name is built based on mobile network
information) could probably handle wf requests to tel: URIs, whatever
process rules are applied at the server to answer or not that query and how
(eg to “proxy” the request to the authoritative server/operator for that
number)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie. 

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

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

---

From: Blaine Cook <[email-masked]>
Date: Mon, 29 Oct 2012 18:29:54 -0700

Hi Paul,

Sorry for the delay, the past week has been extraordinarily busy for
me. I want to separate my concerns about the draft, and my value of
your work on the draft – I've really appreciated that you and others
have kept working on it, and kept the work alive. Thank you. I don't
mean to rain on the parade, but I do want to make sure that webfinger
ends up being the best it can be.

> It seems pretty light-weight to me, yet flexible enough to allow one to convey a list of link relations.

I have reiterated my vehement opposition to the parameterised approach
both in person and on the list enough times that I won't again here. I
strongly believe that all the arguments that have been raised for the
parameter-based approach are specious, and do not reflect the needs of
genuine implementors.

The incorporation of *both* the template URIs and the parameter-based
approaches to dereferencing is deeply problematic for the developer
experience when implementing webfinger. I think the spec should be
simplified and include only one.

I was never happy about the XRD format, but went along with it because
I didn't think it was a *huge* issue. The JSON approach is better, but
honestly, it should just neatly break compatibility with previous
specs (everything else is, after all...)

> WebFinger is structured the way it was described in Eran's posts, the WebFinger list, and RFC 6415.  I don't recall exactly what your proposal was now, but there were proposals to use DNS records l…

Since this appears to be a question, by a "DNS-like approach" I simply
mean that the server that hosts webfinger requests is found by looking
up the lrdd link in the host-meta document (the equivalent of an "NS"
record), and then the URI ("name server") reflected there provides
results ("A", "MX", etc; on webfinger, these would be "photo-feed",
"likes", "links", or whatever -- the rel-values of the links).

> That comes from RFC 6415 and a server would likely expose at least one link of type "template" if the client queries the host-meta resource without using the "resource" parameter.  Name, it would l…

It complicates generic implementations, and makes a casual read of the
documentation much more complicated. If the resource parameter is
required, then the template lookup is totally redundant.

> Can you clarify the point of concern?  The only redirection mechanism proposed in the spec is 3xx.  What text is troubling you?

I think I'd misread the spec / intent around on of the sections. Retracted.

> While using 307 might be the right way to deploy, that is (again) a deployment matter.  I'll note that many web sites still use 302, not 307.  WF clients should accept any of the listed 3xx codes.

301 is not a deployment matter.

It's the equivalent of having a non-expiring, infinitely cached DNS
record. Deploying a wefinger server that returned 301 response codes
would be broken since those webfinger lookups would never be
changeable.

If we're going to force sites to host /.well-known/host-meta serve
dynamic responses, or responses with custom HTTP headers (which,
frankly is probably a pain for people hosting on Dreamhost or other
restricted systems, but whatever, I've given up on that since no-one
else here seems to care), then using the "correct" HTTP code seems
prudent, at least in the spec.

> Large companies will likely run their own servers and could respond directly to requests.  For large companies that want to redirect queries away from example.com/.well-known/host-meta.json to webf…

They *MUST NOT* use 301 responses, or else properly written clients
will NEVER respect changes to the webfinger server.

Small hosts are going to have to send a full response header and serve
a request for ever user lookup at /.well-known/host-meat. For an
organisation with 1000 users, this could be man requests per second.

For large hosts, they'll need to do the same. It won't be possible to
offload the full brunt of the traffic to a secondary host without
implementing relatively complex proxy rules.

I agree it's not a huge difference these days, but it is a difference
that should be acknowledged.

> Where a domain owner has requests coming in from many distinct clients and they use 3xx to redirect to a WebFinger provider, we end up with two request/response exchanges: one for the original requ…

That's crazy – *most* if not *all* servers WILL NOT want to point the
A record for their domain at a webfinger server, and most servers
*will* want to host their webfinger server elsewhere.

Hands up, who hosts their email locally versus on GMail or another
pay-for-service SMTP host? What about global statistics for that? My
claim: *most* people *do not* run their own local inbound mail server.

> In any case, there are many possible deployment models, each with pros and cons.

*nod*

> Are you referring to Section 9 or somewhere else?  I think there is value in having Section 9 since it describes some hosting options.  It could perhaps be made non-normative, but we do make the no…

Simplicity is achieved not when there's nothing left to add, but when
there's nothing left to take away. This is supposed to be a simple
protocol, and will be most successful if it's truly a simple protocol.

> Any input is helpful.  We need to get on the same page and agree on how this should work.  The current draft is not a significant departure from what was defined already, and it wasn't intended to…

My reaction is very much out of concern that the new draft encodes too
many possibilities – at its core, it is in fact very similar to the
original conception and early drafts, but it just has so many options
for implementations (and openings to get things wrong).

b.