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

["Paul E. Jones" <[e-mail]>]

Graham,

> It's a clever idea to use the URI scheme to get information about
> different kinds of account.  But I find myself deeply uneasy about it,
> though not yet entirely sure why...
> 
> Maybe it's because it seems to violate the Web architectural principle of
> URI
> Opacity: http://www.w3.org/TR/webarch/#uri-opacity

As the above referenced text says, the "acct" URI "is designed so that
agents communicate resource information state through representations, not
identifiers".  Having an acct URI in hand does not tell you the kind of
document you will get (e.g., XML or JSON).  It merely specifies the location
of the account information, much as "mailto:" specifies the location of an
email server (discovered through MX records) or "sip:" indicates the
location of one's SIP server (discovered through SRV records).

Like the other URI scheme, "acct:[e-mail]" tells the client
that there is account information located at packetizer.com.  The client
then follows the already-defined procedures of using HTTP(S) to query the
server "packetizer.com" at the location /.well-known/host-meta.  The URI is
then passed as a parameter or inserted into templates found in the XRD or
JRD document.

> OTOH, it seems quite reasonable to me that (say) one might use
>     http://webfinger.org/mail/...
>     http://webfinger.org/xmpp/...
>     http://webfinger.org/acct/...
> to reference information about different kinds of account.  They're just
> different URIs referencing different stuff.  So why not the same for
> different scheme names?

RFC 6415 is designed such that any kind of URI might be passed.  Those above
URIs would be just as valid as any other.  So, I could issue a query like
this:

  GET /.well-known/host-meta?resource=http://packetizer.com/xmpp/...

This tells the WebFinger server to return information about that URL.  What
is that URL?  Is this a web page or a special identifier to refer to a
user's XMPP server?  If it were constructed like this:
  http://packetizer.com/xmpp/[e-mail]

It might be clearer as to its meaning, but then that gets confused with
"xmpp:[e-mail]".  WebFinger allows that URI to be used today.
Any valid URI may be passed to the domain's WebFinger server and an XRD or
JRD representation returned.

Basically, we are at a point where almost everything related to discovery is
already defined.  The question is simply "if I want to discover information
about Paul Jones and I know his ID is '[e-mail]" then how do I
package it in such a way as to successfully query to get that information?"

Proposals have been no scheme at all (which stands at odds with RFC 6415),
using "mailto:", using any URI scheme (sip:, h323:, mailto:, xmpp:, etc).
They could all work, but we should have one identifier that refers to the
users account and not to his other services, IMO.
 
> Unlike a path component in an HTTP URI, a scheme name comes with some
> quite deep wired-in semantics: administrative, technical or both.  What
> assurances do we have that the webfinger use of the scheme name will not
> end up conflicting with the scheme's own semantics?

I don't understand your question.  Can you clarify?  (If I do understand the
question, I think the usage would be safe since there is a well-defined
usage for "acct" with a limited scope.)

> If the URI is a
> simply a name for routing a request for information, and nothing more,
> which is what seems to be the case when looking at
> http://webfinger.org/howto/[e-mail], then the case for having a
> special URI scheme acct: appears to be rather weak - it seems to me that a
> URN namespace, or any other form of URI created to refer to a users
> personal information would serve just as well.

Since WebFinger returns information about any URI, that would work.   We
could have this:

  http://packetizer.com/acct/[e-mail]

My concern with this is that WebFinger operates on URIs, not re-purposed
HTTP identifiers.  The "acct" URI scheme defines a specific kind of URI,
just like "sip:", "mailto:", "xmpp:", and others.   Querying the above might
seem to make sense, but one is then treading on namespace on web servers
that might actually be used for something.  Suppose a web site used "/acct/"
as the URI to log into one's account.  Then using Webfinger to query that
URL would be valid and should return information about the web page.  What
we need is a URI that returns information about an account.

I looked into using URNs.  We could use something like this:
   urn:acct:[e-mail]

However, URNs are location-independent (like OIDs or ISBN numbers).  Thus,
the above is technically incorrect, as it has location information
associated with it (namely packetizer.com).
 
> If, on the other hand, webfinger makes additional operational,
> administrative or technical associations with an acct: URI, the whole idea
> of using an arbitrary scheme name for accessing different information
> seems to be dangerous, as the scheme has been loaded with additional
> semantics that might conceivably conflict with semantics of existing
> schemes.

It should not.  The "acct" URI should exist for the solitary purpose of
querying information about a user's account via WebFinger.

Paul