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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 22 May 2012 07:22:53 +0000

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 May 2012 09:57:15 -0400

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:[email-masked]" or
"mailto:[email-masked]", 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: [email-masked] [mailto:[email-masked]]
On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 22, 2012 3:23 AM
To: [email-masked]
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

---

From: Graham Klyne <[email-masked]>
Date: Tue, 22 May 2012 16:22:54 +0100

On 22/05/2012 14:57, Paul E. Jones wrote:
> might also return other URIs like"sip:[email-masked]"  or

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

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?

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?  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/[email-masked], 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.

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.

#g
--

(For the avoidance of doubt: these comments are made in a purely personal capacity.)

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 22 May 2012 14:01:37 -0400

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...
> 

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:[email-masked]" 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.

> 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/[email-masked]

It might be clearer as to its meaning, but then that gets confused with
"xmpp:[email-masked]".  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 [email-masked]" 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/[email-masked], 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/[email-masked]

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:[email-masked]

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 12:27:42 -0600

On 5/22/12 12:01 PM, Paul E. Jones wrote:

> The "acct" URI should exist for the solitary purpose of

I'm sure that others have wondered why we don't define a 'webfinger' URI
scheme, then, but 'acct' seems fine to me. Much discussion has occurred
over the years about the matter, RFC 6415 requires a URI, and 'acct' is
suitably neutral. I'm in favor of accepting 'acct' and moving on with
our lives.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Jones <[email-masked]>
Date: Tue, 22 May 2012 18:35:31 +0000

Architecturally, I believe that discovery and the acct: scheme are distinct, therefore I believe they should be separate RFCs, but I won't lose sleep over it if the working group decides otherwise.  I believe that both documents will actually progress faster if discussions about one feature don't become entangled in the other one.

I STRONGLY believe that discovery should have its own working group.  Thanks for bringing that possibility up, Murray.  If acct: is split from discovery, I'm fine with it being in the same working group.

Thanks for asking the questions, Murray.

                                                                -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, May 22, 2012 12:23 AM
To: [email-masked]
Subject: [apps-discuss] The acct: scheme question

-MSK

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 14:42:48 -0400

I would prefer a separate working group, with two specs one for discovery and one for the URI scheme.

As another poster pointed out schemes have particular semantics and trigger specific browser behaviours.   The scheme needs to answer questions around expected browser behaviour.

The answer might be do WF discovery and display results in some form, but that should be separate from the discovery spec that can operate on any URI.

John B.

On 2012-05-22, at 2:35 PM, Mike Jones wrote:

> Architecturally, I believe that discovery and the acct: scheme are distinct, therefore I believe they should be separate RFCs, but I won’t lose sleep over it if the working group decides otherwise.  I believe that both documents will actually progress faster if discussions about one feature don’t become entangled in the other one.
>  
> I STRONGLY believe that discovery should have its own working group.  Thanks for bringing that possibility up, Murray.  If acct: is split from discovery, I’m fine with it being in the same working group.
>  
> 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.
>  
> (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
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 12:53:26 -0600

On 5/22/12 12:42 PM, John Bradley wrote:
> I would prefer a separate working group, 

Spinning up a working group is a lot of work (writing the charter,
probably organizing a BoF session at a future IETF meeting, finding
chairs, etc.). Are you volunteering to help with that? :)

> with two specs one for
> discovery and one for the URI scheme.

Having separate specs seems reasonable.

/psa

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 15:08:05 -0400

Yes.

I would have preferred to have this in OAuth as we proposed in Paris.

I don't have the feeling that this is making much real progress in the general apps area.

OpenID Connect is nearing completion,  Unless some real progress happens it will likely continue to  be based on SWD.

So the question is how best to make progress so there can be a reference-able  spec.

John B.

---

From: William Mills <[email-masked]>
Date: Tue, 22 May 2012 12:22:15 -0700 (PDT)

I say leave acct: in the current spec.  While I don't think it's strictly necessary for the purposes of WF I don't think it's a significant flaw either.  I also think breaking it out into a separate spec at this point is just extra work.

John, will WF in it's current form do the job for you?

-bill

>________________________________
> From: John Bradley <[email-masked]>
>To: Peter Saint-Andre <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, May 22, 2012 12:08 PM
>Subject: Re: [apps-discuss] The acct: scheme question
> 
>Yes.
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 May 2012 15:23:27 -0400

> chairs, etc.). Are you volunteering to help with that? :)

My sense is that given the discussion so far, we can do this without a
BoF.  And I'm starting to be more and more convinced that we need to
take this out of AppsAWG and give it its own working group (though I'm
not certain of that yet, and I haven't talked with Pete about it).

That still means we need a draft charter, probably at least a couple
of weeks for discussion and bashing of it, then at least three or four
weeks for the IESG to process it.  Let's say 6 to 8 weeks, if it goes
efficiently and smoothly.  Add time for glitches if they happen.

If the document can be done in less than, say, 12 to 15 weeks, and if
can get adequate attention, then we should finish it here.  But the
discussion needs to converge.  If it needs more focused attention in
order to converge, then that's a reason to pull it off into a WG of
its own.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 13:54:52 -0600

On 5/22/12 1:22 PM, William Mills wrote:
> I say leave acct: in the current spec.  While I don't think it's
> strictly necessary for the purposes of WF I don't think it's a
> significant flaw either.  I also think breaking it out into a separate
> spec at this point is just extra work.

Probably, yes. Minimizing the work is valuable.

/psa

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 22 May 2012 16:20:18 -0400

++

My sentiments exactly.

Cheers,

Gonzalo

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 16:35:17 -0400

While minimizing work is valuable.  Minimizing risk is also.

WF should work with any URI.

It should not be dependant on acct:

acct: will undergo more scrutiny than WF to get approved as a scheme.

John B.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 22 May 2012 14:38:06 -0600

> WF should work with any URI.

It does.

> It should not be dependant on acct:

It's not.

> acct: will undergo more scrutiny than WF to get approved as a scheme.

I'm not sure about that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 16:44:56 -0400

The current WF draft is dependent on acct: 

It uses acct in link relations and it normalizes relative URI like [email-masked] to acct:[email-masked].

I have been through this before with trying to register xri: with almost the same semantics,  for retrieving XRD about a subject.  I thought it would not be a problem.  That was until the W3C TAG intervened, and effectively blocked the OASIS spec.

You are probably right that there is not issue.  However I prefer to manage the risk by separating them.

John B.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 22 May 2012 18:22:58 -0400

> order to converge, then that's a reason to pull it off into a WG of

After having just completed the long drawn out process of authoring a controversial charter that was agreeable to all and finally forming a WG, I would really prefer if we can avoid all that overhead and delay.  We all share the common goal of a robust discovery protocol delivered as expeditiously as possible. I feel we have come a long way given that both camps (SWD and WF) have made concessions and came to an agreeable initial state for a WG draft, along with the maturity of the WF draft and the amount of review and scrutiny it has received from this group I think this is possible if we all remain open-minded and willing to work together.  As far as the acct: URI, I get the sense that most folks don't mind the URI scheme itself. It seems that that the real point of contention is whether it should be split from the original WF doc or not.  

IMO a strong case can be made for the acct: URI scheme being part of the core WF spec considering the existence of 6415 and its foundational nature for the proposed discovery mechanism and how it is entirely URI driven. Further considering the added work and delay in removing acct: from the current WF spec and how it is already implemented and in the wild,  I'd prefer not to split them at this point. I'm happy to defer to group consensus, though.

Cheers,

Gonzalo

---

From: Bob Wyman <[email-masked]>
Date: Tue, 22 May 2012 19:29:59 -0400

I would very much prefer that we do NOT create a new WG but rather proceed
with acct: as part of WebFinger.

WebFinger is designed to work with any URI -- but it needs acct: since what
acct: does is not currently done by any other URI scheme.

bob wyman

On Tue, May 22, 2012 at 6:22 PM, Gonzalo Salgueiro <[email-masked]>wrote:

> After having just completed the long drawn out process of authoring a
> controversial charter that was agreeable to all and finally forming a WG, I
> would really prefer if we can avoid all that overhead and delay.  We all
> share the common goal of a robust discovery protocol delivered as
> expeditiously as possible. I feel we have come a long way given that both
> camps (SWD and WF) have made concessions and came to an agreeable initial
> state for a WG draft, along with the maturity of the WF draft and the
> amount of review and scrutiny it has received from this group I think this
> is possible if we all remain open-minded and willing to work together.  As
> far as the acct: URI, I get the sense that most folks don't mind the URI
> scheme itself. It seems that that the real point of contention is whether
> it should be split from the original WF doc or not.
>
> IMO a strong case can be made for the acct: URI scheme being part of the
> core WF spec considering the existence of 6415 and its foundational nature
> for the proposed discovery mechanism and how it is entirely URI driven.
> Further considering the added work and delay in removing acct: from the
> current WF spec and how it is already implemented and in the wild,  I'd
> prefer not to split them at this point. I'm happy to defer to group
> consensus, though.
>
> Cheers,
>
> Gonzalo
>
>
> >
> > Barry

---

From: William Mills <[email-masked]>
Date: Tue, 22 May 2012 16:58:52 -0700 (PDT)

How about we go with the current draft, and if we hit a significant headwind, we break it out and deal with it separately.

If we hit a headwind we couldgo with a few more characters and use urn:acct:$username@$domain. Probably easier to register with IANA a new URN namespace and we're done.

-bill

> From: Bob Wyman <[email-masked]>
>To: Gonzalo Salgueiro <[email-masked]> 
>Cc: Barry Leiba <[email-masked]>; "[email-masked] Discuss" <[email-masked]> 
>Sent: Tuesday, May 22, 2012 4:29 PM
>I would very much prefer that we do NOT create a new WG but rather proceed with acct: as part of WebFinger.
>
>
>WebFinger is designed to work with any URI -- but it needs acct: since what acct: does is not currently done by any other URI scheme.
>
>
>bob wyman
>
>
>On Tue, May 22, 2012 at 6:22 PM, Gonzalo Salgueiro <[email-masked]> wrote:
>
>

---

From: John Bradley <[email-masked]>
Date: Tue, 22 May 2012 20:39:47 -0400

URN don't have authority portions, so may not be a good fit.

The authority segment is necessary to bootstrap the resolution process.

How about we do the core spec with http://$username@$domain

If we are not intending to have a special protocol handler then http: should work just fine.

The link relationship doesn't need to be a custom scheme.

Whatever Connect references  is going to be around for a long time,  later could be awkward.

John B.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 22 May 2012 17:40:48 -0700

On Tue, May 22, 2012 at 4:58 PM, William Mills <[email-masked]> wrote:
> How about we go with the current draft, and if we hit a significant
> headwind, we break it out and deal with it separately.
>
> If we hit a headwind we couldgo with a few more characters and use
> urn:acct:$username@$domain. Probably easier to register with IANA a new URN
> namespace and we're done.
>
> -bill
>

Actually, a URN namespace will not work here, because the domain name
system does not meet the requirements of a persistence required for a
URN.  This is explained in RFC 3405, but a quick excerpt of the larger
text is:

   For the purposes of URNs, a "namespace" is a collection of uniquely-
   assigned identifiers.  That is, the identifiers are not ever assigned
   to more than 1 resource, nor are they ever re-assigned to a different
   resource.

Since domain names can change hands (for example, when the
organization previously running that domain is purchased), there is no
inherent guarantee that [email-masked] is permanent.

regards,

Ted Hardie

> state for a WG draft, along with the maturity of the WF draft and the amount
> of review and scrutiny it has received from this group I think this is
> possible if we all remain open-minded and willing to work together.  As far
> as the acct: URI, I get the sense that most folks don't mind the URI scheme
> itself. It seems that that the real point of contention is whether it should
> be split from the original WF doc or not.
>

---

From: William Mills <[email-masked]>
Date: Tue, 22 May 2012 20:25:19 -0700 (PDT)

Better to go with no scheme than use http.

>To: William Mills <[email-masked]> 
>Cc: Bob Wyman <[email-masked]>; Gonzalo Salgueiro <[email-masked]>; Barry Leiba <[email-masked]>; "[email-masked] Discuss" <[email-masked]> 
>Sent: Tuesday, May 22, 2012 5:39 PM

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 23 May 2012 15:42:49 +0900

> How about we do the core spec with http://$username@$domain

I have explained earlier that this is not an option. $username is not 
the user *about* which you want information, but the user who *accesses* 
the server.

To give a specific example, if you use an URI such as:

http://[email-masked]/

then e.g. on Firefox, I get the following message:
    You are about to log in to the site "www.ietf.org" with the username
    "john_bradley", but the website does not require authentication.
    This may be an attempt to trick you.

Under the hood, "john_bradley" is being sent in the relevant http header(s).

Regards,   Martin.

>> From: Bob Wyman<[email-masked]>
>> To: Gonzalo Salgueiro<[email-masked]>
>> Cc: Barry Leiba<[email-masked]>; "[email-masked] Discuss"<[email-masked]>
>> On Tue, May 22, 2012 at 6:22 PM, Gonzalo Salgueiro<[email-masked]>  wrote:
>>

---

From: [email-masked] (Henry S. Thompson)
Date: Wed, 23 May 2012 12:27:18 +0100

John Bradley writes:

> As another poster pointed out schemes have particular semantics and
> trigger specific browser behaviours.  The scheme needs to answer 
> questions around expected browser behaviour.

Precisely.  I have no detailed interest in webfinger as such, but new
URI schemes are not something to be created casually.  We have
guidelines for these things, in the form of RFC 4395 [1], which says,
_inter alia_,

  "The use and deployment of new URI schemes in the Internet
   infrastructure is costly; . . . For these reasons, the unbounded
   registration of new schemes is harmful.  New URI schemes SHOULD
   have clear utility to the broad Internet community, beyond that
   available with already registered URI schemes."

Pushing through a new scheme because it's a relatively minor part of a
larger project which people are keen to get finished doesn't seem like
the best way to get the necessary careful review that a new scheme
requires.

ht

[1] http://tools.ietf.org/html/rfc4395
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: Bob Wyman <[email-masked]>
Date: Wed, 23 May 2012 11:06:20 -0400

acct: is NOT "a relatively minor part of a larger project." acct:
identifies a fundamental class of resource on the network that we've
traditionally ignored due to the inappropriate assumption that there was a
binding between accounts and email addresses. However, as we increase the
richness of services available on the network, we see more and more that
such a binding is inappropriate. Not all services that offer accounts do or
should provide email support as well.

Would people be happier with acct: if there were other protocols that used
it? For instance, if we had an "Account Creation and Management Protocol"
that used acct:? (Such a thing and its utility would not be that hard to
imagine....) if so, then for goodness sake, let acct: be created now and
then we can be sure that someone will eventually submit the Internet Draft
to define the full-fledged acct: protocol. But, today, we only need this
one aspect of acct: to be defined. Let it be.

bob wyman

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 23 May 2012 18:03:41 +0200

> WF should work with any URI.

While I dont mind whether WF works with any URI or not.  It should be noted:

http already has discovery (follow your nose)

xmpp i believe already has discovery

mailto: is the gap that it would be good to close

were there any alternate schemes that there is a use case for, other than
the 3 above?

> It should not be dependant on acct:

+1

> acct: will undergo more scrutiny than WF to get approved as a scheme.

+1

---

From: William Mills <[email-masked]>
Date: Wed, 23 May 2012 11:37:25 -0700 (PDT)

I would argue that discovery for mailto: is covered by MX records in DNS, no?

> From: Melvin Carvalho <[email-masked]>
>To: John Bradley <[email-masked]> 
>Sent: Wednesday, May 23, 2012 9:03 AM
>were there any alternate schemes that there is a use case for, other than the 3 above?
> 
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 23 May 2012 22:44:02 -0400

You're correct, though WebFinger could accept any URI, including "mailto".
The question is "what should a WF server return for such a URI?"  The same
information as for a user account ("acct")?  Something related to the user's
mail server or services?  Something else?

The use of "mailto:" is one of convenience since it's defined, but not the
right solution, IMO.

I mentioned before that "acct" was felt necessary after much debate (like
we're having now) since there are user accounts on domains for which there
is no associated email ID or where it just does not make sense.  I've
provided some examples before (twitter, photo sharing site, file sharing
site, etc.).

At the end of the day, we have the option to define an account URI for use
with WebFinger or to overload another to query for information related to a
user account.  The problem is that there are no others that are really
appropriate to overload.  Overloading "http:" using something like
http://packetizer.com/acct/paulej is not a good choice since there just
might be some domains already that use URLs of this form for other reasons
and querying those via WebFinger might return an XRD or JRD related to that
existing URL.  Mailto is not right, though it could be used for sites that
have email IDs.  But, arguing for use of "mailto:" is on par with arguing
for the use of "sip:".  Why do we propose using "mailto" but not "sip" or
"xmpp" or "h323"?  They could all be hacked for our purpose ;-)

The "acct" URI scheme has a narrow scope, well-defined application, no
conflicts with other URIs (that could also be used with WF for some
applications), does not overload / hack existing schemes, etc.  Thus, as
I've said before, I think it's a reasonable solution, even if it's not
necessarily the most appreciated URI scheme out there.  I suspect
appreciation for that URI scheme will grow with wider deployment of
WebFinger, though.

Paul

From: [email-masked] [mailto:[email-masked]]
On Behalf Of William Mills
Sent: Wednesday, May 23, 2012 2:37 PM
To: Melvin Carvalho; John Bradley
Cc: [email-masked]
Subject: Re: [apps-discuss] The acct: scheme question

I would argue that discovery for mailto: is covered by MX records in DNS,
no?

  _____  

 

+1

+1

John B.

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 24 May 2012 11:45:51 +0100

Paul E. Jones writes:

> The "acct" URI scheme has a narrow scope . . . I suspect

I find those two statements bordering on the contradictory.  It is
precisely because if it does indeed turn out that acct: URIs address a
real need, they will 'leak' out of WF and into wider contexts
(i.e. "appreciation . . . will grow"), and so acct: needs review as
such in the normal way any new URI scheme needs review.

ht

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 24 May 2012 10:03:34 -0400

Henry,

> Paul E. Jones writes:
> 
> > The "acct" URI scheme has a narrow scope . . . I suspect appreciation
> > for that URI scheme will grow with wider deployment of WebFinger,
> > though.
> 
> real need, they will 'leak' out of WF and into wider contexts (i.e.
> "appreciation . . . will grow"), and so acct: needs review as such in the
> normal way any new URI scheme needs review.

It wasn't intended to be.  Several have said before that they do not like
"acct" and prefer something else.  However, I think that is because "acct"
is presently not widely deployed and the novelty concerns people.  It has
been suggested, for example, to use the URI scheme "mailto" instead.  So, my
intent was just to say that once "acct" is adopted for querying for a user's
account information using "acct", people will appreciate it more than they
do now.  I think back on the examples I've given where I feel "mailto" just
isn't right because it relates to email and some of my accounts on the
Internet have no relationship to email.

That's not to say that "mailto" could not be used.  If the OpenID spec
declared that was the URI to use, then that's what that protocol mandates
and I'd have no objection to it.  What I'd like to see mailto used for,
though, is to provide information to my mail client so it can be
provisioned.  Someone referred to RFC 6186 as a way to do that, but that RFC
only specifies what POP, IMAP, and SMTP servers to use globally.  Users are
often clustered on certain machines and I'd personally like to see a link
relation called "config-email" that has a URI that, when queried, would
return JSON like this:

  {
    "imaps" : "cluster23.imap.packetizer.com",
    "smtp-submission" : "smtp.packetizer.com"
  }

That link relation could be returned when querying for my account (via the
"acct" URI), but if there was a document that defined mail
auto-configuration, then it could specify the use of "mailto" and I believe
that would be a perfectly good example of where "mailto:" would be more
appropriate than "acct".

The "acct" URI should be used to return a wide variety of information about
a user's account.  I view it as information that is largely of interest to
people other than the actual user.  That would include information like my
contact list or my picture or other information.

Anyway, we've discussed before that WebFinger can operate on a variety of
URIs.  The one that should relate to the users account we put a stake in the
ground and declare to be "acct".  If we want to specify other URIs for a
subset of that information or instead of "acct" (e.g., mailto for mail
configuration), that would be a reasonable thing to do.

Paul

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 24 May 2012 16:18:33 +0200

> configuration), that would be a reasonable thing to do.

Let me make an analogy with a relational database:

Consider you had a database table of information about a user.  One field
in the table is a (unique) email address and you wish to get the whole row,
which may contain things like blog and name, but could be any number of
fields.

The acct: protocol says the folloiwng:  'we should look up the table record
by the primary key, which is not the email address'.  Since we dont know
what the primary key is, let's give it a name : 'acct:user@host'.  Then we
can look things up.

There's a few challenges with this:

- it assumes lookup by "foreign" key (email) is problematic, which it need
not be

- if there is an existing primary key the acct: scheme may not be needed or
wanted

- it transitions the social web to a world where users will necessarily
have a keyring of multiple identifiers to carry out a cross platform lookup
(for example facebook already use http uris in their graph) making
implementations more complex

- developers and implementors may get confused of when to use mailt: acct:
or just user@host

- it's going to take many years (both time and work) for this to become
anywhere near as mainstream as http: or mailto:

If the payoff is considered worth the effort, then I think that's probably
fine.  Personally I think acct: should have it's own document.  Perhaps if
it's ultra simple (under 1 page as it is now) it can get approved very
quickly.

---

From: John Bradley <[email-masked]>
Date: Thu, 24 May 2012 10:27:21 -0400

The question comes down to the same one that has been discussed in the past.

What to use as a abstract identifier for a user.

I am sympathetic to the use of acct:

However I have not been convinced that it belongs in WF directly.

Until acct: is an approved URI I am not keen to have openID Connect take a normative reference to it.

If the WG and the chairs decide to do it as one spec,  that will likely impact our decision to reference WF for discovery.

That is just a personal opinion and the Connect WG will need to take the decision.

John B.

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 24 May 2012 11:15:05 -0400

John,

It seems that most people largely agree with the procedures we've defined
now; I've seen no other proposed changes (noting -05 contained only a very
few).  It also seems that most people see the utility for "acct", even
though other URIs might be used for some use cases (e.g., mail client
configuration or XMPP client configuration).

The only remaining concern I see is with approval of "acct" and delays that
might happen.  I think that if properly positioned for what "acct" is, it
would be opposed.  If there was opposition, though, we could always split
the draft into two pieces in order to get the draft moved to RFC status.  Of
course, I'd prefer to keep all of the text together, but I would prefer to
not hold up progress on OpenID Connect.

Paul

> -----Original Message-----
> From: John Bradley [mailto:[email-masked]]
> Sent: Thursday, May 24, 2012 10:27 AM
> To: Paul E. Jones
> Cc: Henry S. Thompson; [email-masked] Discuss
> If the WG and the chairs decide to do it as one spec,  that will likely
> impact our decision to reference WF for discovery.
> 
> >> precisely because if it does indeed turn out that acct: URIs address
> >> a real need, they will 'leak' out of WF and into wider contexts (i.e.
> >> "appreciation . . . will grow"), and so acct: needs review as such in
> >> the normal way any new URI scheme needs review.
> >
> > It wasn't intended to be.  Several have said before that they do not
> > like "acct" and prefer something else.  However, I think that is because
> "acct"
> > is presently not widely deployed and the novelty concerns people.  It
> > has been suggested, for example, to use the URI scheme "mailto"
> > instead.  So, my intent was just to say that once "acct" is adopted
> > for querying for a user's account information using "acct", people
> > will appreciate it more than they do now.  I think back on the
> > examples I've given where I feel "mailto" just isn't right because it
> > relates to email and some of my accounts on the Internet have no
> relationship to email.
> >
> > declared that was the URI to use, then that's what that protocol
> > mandates and I'd have no objection to it.  What I'd like to see mailto
> > used for, though, is to provide information to my mail client so it
> > can be provisioned.  Someone referred to RFC 6186 as a way to do that,
> > but that RFC only specifies what POP, IMAP, and SMTP servers to use
> > globally.  Users are often clustered on certain machines and I'd
> > personally like to see a link relation called "config-email" that has
> > a URI that, when queried, would return JSON like this:
> >
> >  {
> > That link relation could be returned when querying for my account (via
> > the "acct" URI), but if there was a document that defined mail
> > auto-configuration, then it could specify the use of "mailto" and I
> > believe that would be a perfectly good example of where "mailto:"
> > would be more appropriate than "acct".
> >
> > The "acct" URI should be used to return a wide variety of information
> > about a user's account.  I view it as information that is largely of
> > interest to people other than the actual user.  That would include
> > information like my contact list or my picture or other information.
> >
> > Anyway, we've discussed before that WebFinger can operate on a variety
> > of URIs.  The one that should relate to the users account we put a
> > stake in the ground and declare to be "acct".  If we want to specify
> > other URIs for a subset of that information or instead of "acct"
> > (e.g., mailto for mail configuration), that would be a reasonable thing
> to do.
> >
> > Paul
> >
> >

---

From: Michiel de Jong <[email-masked]>
Date: Fri, 25 May 2012 11:06:43 +0000

> Until acct: is an approved URI I am not keen to have openID Connect take a normative reference to it.

Indeed I think we can conclude:
- an acct: scheme would be helpful
- it does not currently exist
- we have to think about what to do until it exists

On Wed, May 16, 2012 at 4:34 PM, Blaine Cook <[email-masked]> wrote:
> I'm completely and totally opposed to webfinger not accepting
> scheme-less addresses.
>
> Please start from the user experience – no-one in the history of the
> internet has typed "http://" into a browser window address bar (I may
> be overstating that, but statistically speaking it's true).
>
> Likewise, no-one will ever type "acct" or "mailto" or "xmpp" or
> anything else into a form field.
>
> To require clients to convert "[email-masked]" into
> "acct:[email-masked]" is just pedantry of the worst sort. If I had it
> my way, webfinger (not host-meta) wouldn't even resolve URIs; it would
> only resolve scheme-less email identifiers, because that's what we're
> doing.
>
> I *understand* that there *should* be an URI for these things;
> however, there is prior art for not having an URI – DNS is a core
> piece of internet infrastructure that uses "bare" identifiers all the
> time precisely to find *resolvable* resources that *do* use URIs.
>
> I'm not going to stand in the way of consensus, but if the IETF
> specification ends up stating that bare identifiers are not supported,
> then I will personally consider this work a failure as I believe
> strongly enough that URIs are not necessarily appropriate here. :-/
>
> b.

And this was +1'ed by Mike Jones. So I pointed out that:

Once acct: is a URI scheme, you'll be able to say the parameter takes
"any URI". Until then, you'll have two options:

1) say the parameter takes "any URI or user@host"
2) say the parameter takes "any existing URI scheme or acct:user@host"

I think we agree that as Blaine said, there *should* be an URI, but I
think we also can agree that the limbo period would be too long to say
"let's first wait to see if acct: gets accepted, and then decide what
we do". So we have to make a choice about the period between now and
the 'verdict'. For that period, I would vote for option 1. I think
it's clear that option 1 has a down-side:
- it deviates from host-meta as such

but option 2 has three downsides:
- in relying on a scheme that does not *yet* exist, it also deviates
from host-meta, so that doesn't change
- it could lead to rejection-domino, should acct: get rejected
- it involves dropping bare user addresses, and Blaine already said
he's "completely and utterly" opposed to that.

I'm in favour of option 1, and from what i read, some more people are.
Some other people have stated they are simply not interested in making
the scheme-less case work, which is fair enough. I don't think anybody
is in favour of suspending production use until we get an answer about
the proposed URI scheme, although I might be wrong. There are probably
some other positions which i'm underrepresenting here, sorry if that's
the case.

But when phrased this way, is anybody in favour of option 2?

---

From: John Bradley <[email-masked]>
Date: Fri, 25 May 2012 07:39:51 -0400

> 1) say the parameter takes "any URI or user@host"

Also move acct: tp a different spec.  If it gets approved that's fine.  If people use an un-appoved scheme name as an identifier for computability with existing deployments that is fine as well, but it should not be in the WF spec.

I think Blane and I agree on the point that the server not the client is in the best position to figure out what the user intended if they type in [email-masked].   The client is adding acct: to say that it doesn't know.  sending a relative URI as we do in SWD and letting the server figure it out is probably the best thing.

It is a parameter, I don't see any reason that a relative URI would not be valid, as long as a authority is present.

John B.

---

From: Michiel de Jong <[email-masked]>
Date: Fri, 25 May 2012 11:46:00 +0000

On Fri, May 25, 2012 at 11:39 AM, John Bradley <[email-masked]> wrote:
> Also move acct: to a different spec.

Yes, that is what i meant and also what i think would make sense.