- From: Henry Story <henry.story@bblfish.net>
- Date: Wed, 23 May 2012 17:35:35 +0200
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>, paulej@packetizer.com
On 23 May 2012, at 17:19, Noah Mendelsohn wrote: > 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". There cannot be only one scheme to identify individuals. You can do it with http, https, ftp, ftps, and many other ways. The folks should stick to stating their claims in general terms: "a URI that identifies an agent of some kind", without tying themselves to one in particular. So for example you can do this <http://bblfish.net/#hjs> a foaf:Person; foaf:openid <http://bblfish.net/>; foaf:mbox <mailto:henry.story@bblfish.net>; foaf:account <accnt:henry.story@gmail.com> . Since foaf:openid, foaf:mbox and foaf:account are inverse functional that is they indirectly all identity the same individual identified by <http://bblfish.net/#hjs> (namely the person writing this e-mail), then you can see that all of these are in some ways identifying. Those all identify me in some way, though in the case above only <http://bblfish.net/#hjs> refers to me directly. the openid refers to my openid page (which is the same as my home page) the mbox refers to one of my mailboxes the account refers to an online account at google. Henry > > 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 > > <Attached Message Part.txt> Social Web Architect http://bblfish.net/
Received on Wednesday, 23 May 2012 15:36:16 UTC