W3C home > Mailing lists > Public > www-tag@w3.org > May 2012

RE: [apps-discuss] The acct: scheme question

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>
Message-ID: <00e801cd3c47$e17f8df0$a47ea9d0$@packetizer.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 27 May 2012 20:33:20 GMT