- From: Paul E. Jones <paulej@packetizer.com>
- Date: Sun, 27 May 2012 16:32:46 -0400
- To: "'Graham Klyne'" <GK@ninebynine.org>, "'Henry Story'" <henry.story@bblfish.net>
- Cc: "'Noah Mendelsohn'" <nrm@arcanedomain.com>, <www-tag@w3.org>
Graham, > The uncompelling aspect of their proposal, as I see it, is that it's hard > to see what distinct purpose is served by the proposed acct: scheme that > can't easily be handled by another scheme. But it seems there are strong > "social" pressures (and maybe operational - I can't tell based on my > limited knowledge of the > context) to have something that is distinct from specific > applications/protocols to have a way of finding information accounts > without their "own" URI shceme. There's no social pressures at all. It's merely a matter of trying to find the right technical solution. WebFinger allows one to pass any URI to the server. It might be HTTP or mailto or sip or h323 or xmpp or anything else. For any given URI, the server will respond with information about that URI. This is perfectly valid: GET /.well-known/host-meta?resource=http://www.packetizer.com/ipmc/ The server would then return whatever information it might wish to share related to that web page. We could use mailto: GET /.well-known/host-meta?resource=mailto:paulej@packetizer.ocm Likewise, the server might respond with information related to that email ID. The reason for "acct" is that none of the existing URI schemes are appropriate. We could use "http:", but that presents a conflict. Is one querying about the resource at that URI (which might include server copyright information) or is one querying about a user? We could use "mailto:", which does relate more closely with users, but not all users have email IDs and certainly not all user accounts have email IDs (e.g., a photo or file sharing account). Thus, nothing is a perfect match. The "acct" URI scheme would refer to a user at some domain and, more specifically, refer to a user's account that is querying via WebFinger. > From a pure technical perspective, I think it's fairly clear that another > scheme *could* be used, say http:, but I can't quite quite figure why > that's considered unacceptable. Likewise, I cannot understand why one would want to re-use an HTTP URI for something totally unrelated to HTTP. We use HTTP to query a WebFinger server, but the "thing" about which we are requesting information is not an HTTP resource. Arguing to use HTTP is like arguing to do away with mailto and use this to refer to one's email ID: http://example.com/mailto/paulej@packetizer.com Perhaps the SIP protocol could be equally altered and we deliver all SIP messages using this syntax: INVITE http://example.com/sip/bob@biloxi.com SIP/2.0 Given those options, I'd much prefer to use a URN like: urn:acct:paulej@packetizer.com That's not right either, though, since URNs are not supposed to have location information associated with them. A URI like this is equally confusing: http://example.com/acct/paulej@packetizer.com For that, one has to recognize that "http://example.com/acct/" is a prefix to the identifier that identifies a user via WebFinger. One then must take the value following and locate the domain and issue the query. It's workable, but it's a hack, IMO. We also talked about having URLs like this: http://packetizer.com/acct/paulej However, I think it's bad practice to start standardizing pathnames in everyone's domains. It would not surprise if a few hundred or thousand web sites use /acct/ today for some purpose, so to re-define it is dangerous. This is clean: acct:paulej@packetizer.com One would know what to do with that immediately. It is used only to identify user accounts that can be queried via WebFinger to return an XRD or JRD document related to the user. Paul
Received on Sunday, 27 May 2012 20:33:19 UTC