Fwd: Re: [apps-discuss] The acct: scheme question

Of possible interest to the TAG: this is being discussed on the 
apps-discuss mailing list, where there is a long thread. Note specifically 
the discussion of a proposed "acct" URI scheme "to identify individuals".

I don't feel sufficiently informed on the details to respond formally on 
apps-discuss, but I strongly suspect that an architecturally preferable 
solution would be to use an http scheme URI, and introducing new media 
types as necessary, with appropriate http status codes, redirections, etc., 
to indicate that the data returned is about an individual.

Noah

-------- Original Message --------
Subject: 	Re: [apps-discuss] The acct: scheme question
Date: 	Tue, 22 May 2012 09:57:15 -0400
From: 	Paul E. Jones <paulej@packetizer.com>
To: 	'Murray S. Kucherawy' <msk@cloudmark.com>, <apps-discuss@ietf.org>



Murray, et al,

I invite others to weigh in on this discussion, but I do want to restate my
thoughts on this issue.

The WebFinger draft introduces only minor enhancements over the current RFC
6415. Specifically, it:

·Mandates server support for JSON

·Introduces the “resource” parameter

·Introduces the “rel” parameter

·Requires support for CORS (at least in most situations; this has been
softened a bit to consider enterprise security requirements in the -05 draft)

·Introduces the “acct” URI scheme for identifying individuals

·Introduces the “acct” link relation to refer to user accounts

I believe the group is largely in agreement on everything, except the
introduction of the “acct” URI. There was some debate over server-side
requirement for both XML and JSON, need for “rel”, etc. I view all of these
as binary decisions and the group could easily cast a vote.

The question of whether to include the “acct” URI or not I believe largely
depends on whether this URI scheme would have utility outside of WebFinger.
If it does have other uses then it might make sense to have it stand on its
own. At present, the only use I can see for it is for discovery of
information about people via WebFinger.

Further on that point, the “acct” URI scheme was, in fact, one of the more
significant reasons we introduced this new Internet Draft. After all, RFC
6415 defines the framework for discovery. The “acct” URI scheme, which was
heavily discussed previously among interested parties, was not a part of
that RFC. Even so, it was implemented and cited in various documents,
blogs, etc. Thus, we wanted to formalize it and also introduce addition
minor restrictions and enhancements that make WebFinger more useful for
discovering information about people. Those additions are enumerated above
(e.g., the “resource” parameter, requirement for JSON, etc.).

The debate over the “acct” URI scheme still seems to be centered on the
argument that we either do not need a URI scheme at all or we can re-use an
existing scheme. I am very much opposed to a scheme-less solution, since
RFC 6415, link relations, and Web-Linking, HTML, and all related work upon
which WebFinger depends relies on URIs. The URI is what is used to
differentiate one type of entity from another. A query for “mailto:”, for
example, might return information about one’s mail servers, mail accounts
(e.g., POP or IMAP configuration information), etc. A query for “xmpp:”
might return information about one’s XMPP server, buddy list, etc. A query
for “sip:” might return information about a user’s SIP registrar, outbound
SIP proxy, or other configuration information.

Of course, one could build a WebFinger server to return everything about a
user regardless of the URI scheme. I just think that is an inappropriate
way to respond to a WebFinger query. The “acct” URI was intended to be the
single URI scheme that would return information /about/ a person (or
possibly a thing) that holds an account at a given domain. It would be the
one URI scheme that would return information like vcards, OpenID
identifiers, references to social networking pages, photo sharing
resources, etc. It might also return other URIs like
“sip:paulej@packetizer.com” or “mailto:paulej@packetizer.com”, which is
information /about/ me and ways to contact me.

There are perhaps many agreements to be reached through accepted practice,
further extensions to WebFinger (and I would love one that defines how to
have my email client auto-provision itself), etc. However, I view the
“acct” URI scheme and link relation as integral to WebFinger. Without it,
discovery would have to be performed using some other less neutral URI
scheme that isn’t quite right. Another scheme would work, but it would not
be the cleanest approach, IMO.

Normally, I like taking a pragmatic approach to solving problems and will
not argue for architectural purity. However, we have an opportunity to make
the right selection right out of the gate with WebFinger. It would be
trivial for us to implement /any/ choice at this point. We could build
everything around “mailto:”, but not all service providers offer email
accounts (e.g., Twitter) and it’s entirely nonsensical for other accounts
(e.g., PhotoBucket). As such, I’d like to argue for using “acct” to refer
to information related to an individual’s account at a domain and to retain
that URI scheme within the WebFinger document.

Paul

*From:*apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
*On Behalf Of *Murray S. Kucherawy
*Sent:* Tuesday, May 22, 2012 3:23 AM
*To:* apps-discuss@ietf.org
*Subject:* [apps-discuss] The acct: scheme question

As we prepare to bring webfinger into appsawg, it looks a lot like there’s
substantial discussion just on the point of the proposed “acct:” scheme.

So, a question for those tracking the discussion: Is this a big enough
topic that it should be split into its own document? This would be a useful
thing to decide as we figure out how to handle the work once it enters
working group mode.

(This by itself has me wondering if we should revisit the conversation
about whether webfinger needs its own working group, but I’ll leave it to
Barry and Pete to make that call.)

-MSK