Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 20:46:27 -0700

(Apologies for the slow response time...)

On 1/29/13 1:21 PM, Dave Cridland wrote:
> What about:
> 
>    Because an 'acct' URI enables abstract identification only and not
>    interaction, this specification provides no method for deferencing
>    an 'acct' URI on its own, e.g., as the value of the 'href' attribute of
>    an HTML anchor element.  For example, there is no behaviour
>    specified in this document for an 'acct' URI used as follows:
> 
>    <a href='acct:[email-masked]'>find out more</a>
> 
>    Instead, an 'acct' URI is employed indirectly and typically is passed
>    around as a parameter in the background within a protocol flow so
>    that an entity can interact with a resource related to that identified
>    by the 'acct' URI in a particular way or for a particular purpose. [...
> continues ...]

Thanks, that is helpful; I'll incorporate that into the spec.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 21:02:12 -0700

On 1/29/13 9:55 AM, Bill Mills wrote:
> I believe an argument against making it a urn is that urns
> supposed ot be globally unique?  acct: supports locka identifiers
> so won't be globally unique.

There was discussion about allowing local identifiers (acct:bob rather
than acct:[email-masked]) but I recall no consensus to support them.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 21:15:31 -0700

On 1/29/13 9:49 AM, Melvin Carvalho wrote:
> On 29 January 2013 17:45, Evan Prodromou <[email-masked]> wrote:
> 
>> On 13-01-28 09:13 PM, Evan Prodromou wrote:
>> 
>> Section 3 says, in part,
>> 
>> For example, an 'acct' URI would not be used as follows:
>> 
>> For many kinds of accounts, there are reasonable ways to resolve
>> that URI and show a representation of the account in the
>> browser.
>> 
>> I believe there's been some experimental work on this with
>> Webfinger in particular:
>> 
>> http://www.open-mike.org/entry/people-in-the-address-bar-with-webfinger
>>
>>
>> 
For accounts that don't support Webfinger, it's possible to do one-off
>> resolution, e.g. changing a well-known domain like 
>> acct:[email-masked] into an HTTP URL like 
>> https://www.facebook.com/evan.prodromou is a simple
>> transformation.
>> 
>> Given that it's *possible* to do this, and that it might even be
>> *useful*, is there a reason we need to explicitly disavow it?
>> 
>> If acct: URIs are supposed to be URN-like, maybe it would make
>> more sense for "acct" to be an URN namespace, per RFC 2141.
>> 
>> urn:acct:[email-masked]
>> 
> 
> I think this question has come up a few times, without a strong
> consensus, imho.
> 
> It strikes me that acct: is slightly more appropriate as a urn than
> as a 'top level' URI scheme.

Well, using urn:acct:[email-masked] instead of acct:[email-masked]
would pretty much discourage people from putting them in HREFs, eh? ;-)

It strikes me that accounts are not good candidates for URNs, since
domains can change hands, accounts can be disabled or reassigned, etc.
Thus urn:acct:[email-masked] might not always identify the same Bob
or the same provider of account-related services at the example.com
domain.

For this reason, I think that defining a URI scheme is the right way
to go.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 18 Feb 2013 21:22:48 -0700

Hi Evan!

On 1/28/13 7:13 PM, Evan Prodromou wrote:
> that URI and show a representation of the account in the browser.
> 
>  For accounts that don't support Webfinger, it's possible to do
> one-off resolution, e.g. changing a well-known domain like 
> Given that it's /possible/ to do this, and that it might even be 
> /useful/, is there a reason we need to explicitly disavow it?

In the text that Dave Cridland proposed, the construction is not
disavowed, but this specification does not define such behavior. If
the authors of another specification wishes to do so, there's nothing
to stop them. :-)

Peter

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