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

From: Salvatore Loreto <[email-masked]>
Date: Mon, 28 Jan 2013 15:24:44 +0200

Dear WG partecipants,

I would like to initiate a 2 weeks WG Last Call on
draft-ietf-appsawg-acct-uri-02.txt ("The 'acct' URI Scheme")
http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt

Please send your reviews, as well as expression of support regarding
document readiness for IESG (or not) either to the *apps-discuss* 
mailing list,
or directly to the WG chairs (Murray Kucherawy and myself).

The WG LC will end on Friday, February 8th.

Thank you,
Salvatore as an APPSAWG co-chair.

---

From: SM <[email-masked]>
Date: Mon, 28 Jan 2013 11:07:52 -0800

>http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt

I took a quick look at the draft.  Shouldn't the draft define a 
registry for protocols that use the scheme?

Regards,
-sm

---

From: William Mills <[email-masked]>
Date: Mon, 28 Jan 2013 19:22:41 +0000

I don't believe so, as I don't think a registry would serve a useful purpose.  Applications supporting WebFinger service discovery for example may support it, but what would an app do when it sees multiple registered protocols that support "acct:"?

Regards,

-bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
Sent: Monday, January 28, 2013 11:08 AM
To: Salvatore Loreto; [email-masked]
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02

>http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt

I took a quick look at the draft.  Shouldn't the draft define a registry for protocols that use the scheme?

Regards,
-sm 

_______________________________________________
apps-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: SM <[email-masked]>
Date: Mon, 28 Jan 2013 12:28:21 -0800

Hi Bill,
At 11:22 28-01-2013, William Mills wrote:
>I don't believe so, as I don't think a registry would serve a useful 
>purpose.  Applications supporting WebFinger service discovery for 
>example may support it, but what would an app do when it sees 
>multiple registered protocols that support "acct:"?

Good question.  This draft is basically the paperwork to get the 
"acct" scheme registered.  Based on what you mentioned about the 
draft might not qualify as a Proposed Standard.

Section 4.7 mentions that there aren't any interoperability 
considerations.  As a quick reaction I would say there would be 
interoperability issues when you have the same "identifier" used in 
different protocols to get different things.  If the application 
supports multiple protocols it would have to pick one of them to 
deference the URI.

Regards,
-sm

---

From: Bill Mills <[email-masked]>
Date: Mon, 28 Jan 2013 12:42:56 -0800

It's possible to have duplicate indentifiers in the world as acct: supports "local" identifiers.  As opposed to Proposed Standard is this then informational?

________________________________
From: SM <[email-masked]>
To: William Mills <[email-masked]> 
Cc: [email-masked] 
Sent: Monday, January 28, 2013 12:28 PM
Subject: RE: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02

Hi Bill,
> I don't believe so, as I don't think a registry would serve a useful purpose.  Applications supporting WebFinger service discovery for example may support it, but what would an app do when it sees…

Good question.  This draft is basically the paperwork to get the "acct" scheme registered.  Based on what you mentioned about the draft might not qualify as a Proposed Standard.

Section 4.7 mentions that there aren't any interoperability considerations.  As a quick reaction I would say there would be interoperability issues when you have the same "identifier" used in different protocols to get different things.  If the application supports multiple protocols it would have to pick one of them to deference the URI.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Mon, 28 Jan 2013 13:36:04 -0800

Hi Bill,
At 12:42 28-01-2013, Bill Mills wrote:
>It's possible to have duplicate indentifiers in the world as acct: 
>supports "local" identifiers.  As opposed to Proposed Standard is 
>this then informational?

Yes.  I flagged it as an issue as it is easier if it is considered now.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 28 Jan 2013 15:04:48 -0800

SM,

Can you please elaborate on your point about qualification as a PS?

-MSK

On Mon, Jan 28, 2013 at 12:28 PM, SM <[email-masked]> wrote:

>> purpose.  Applications supporting WebFinger service discovery for example
>> may support it, but what would an app do when it sees multiple registered
>> protocols that support "acct:"?
>>
>
> Good question.  This draft is basically the paperwork to get the "acct"
> scheme registered.  Based on what you mentioned about the draft might not
> qualify as a Proposed Standard.
>
> different protocols to get different things.  If the application supports
> multiple protocols it would have to pick one of them to deference the URI.
>
>
> Regards,
> -sm
> ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: SM <[email-masked]>
Date: Mon, 28 Jan 2013 16:07:00 -0800

Hi Murray,
>Can you please elaborate on your point about qualification as a PS?

There is an AppsDir review from Tim Bray about a previous scheme at 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05435.html 
The issue may be different here.  I'll describe Proposed Standard as 
when interoperability is necessary.  I don't feel strongly about this.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jan 2013 18:26:39 -0700

On 1/28/13 1:28 PM, SM wrote:
> Hi Bill, At 11:22 28-01-2013, William Mills wrote:
>> I don't believe so, as I don't think a registry would serve a
>> useful purpose.  Applications supporting WebFinger service
>> discovery for example may support it, but what would an app do
>> when it sees multiple registered protocols that support "acct:"?
> 

I don't follow your logic there.

> interoperability issues when you have the same "identifier" used
> in different protocols to get different things.

That's not interoperability, that's multi-functionality. :-)

So let's say that we have lots of protocols using acct as a parameter
in various REST-based protocols...

a. WebFinger
http://example.com
  /.well-known/webfinger?resource=acct%3Abob%40example.com

b. mythical SendMessage protocol
http://example.com
  /.well-known/msg?resource=acct%3Abob%40example.com

c. Daniel Pocock's uber-RTC thingie
http://example.com
  /.well-known/callme?resource=acct%3Abob%40example.com

[etc.]

As we've discussed before, we're not encouraging people to do things
like <a href='acct:[email-masked]'>Bob</a> precisely because the
'acct' scheme is define primarily for the purpose of identification,
not interaction.

However, given that people are still confused about this after saying
it so many times, perhaps it needs to be even clearer in the spec? As
in, even, a MUST NOT?

> If the application supports multiple protocols it would have to
> pick one of them to deference the URI.

So don't shove the URI into hyperlinks and so on.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jan 2013 19:01:44 -0700

On 1/28/13 5:07 PM, SM wrote:
> Hi Murray, At 15:04 28-01-2013, Murray S. Kucherawy wrote:
> when interoperability is necessary.  I don't feel strongly about

Well, 'about' URIs are truly local -- each browser does something
different with them, supports different parameters, etc. The use of
'acct' URIs within WebFinger or other using protocols does have
implications for interoperability. However, per RFC 4395, the purpose
of the "Interoperability considerations" section in the URI scheme
registration is as follows:

      If you are aware of any details regarding your scheme that might
      impact interoperability, please identify them here.  For example:
      proprietary or uncommon encoding method; inability to support
      multibyte character sets; incompatibility with types or versions
      of any underlying protocol.

I don't see anything about the 'acct' scheme itself that would cause
interoperability problems of that kind (the scheme is handled
consistently, doesn't use a weird encoding scheme, etc.), but perhaps
you're right that we might want to mention that the scheme could be
reused by multiple different protocols, as you've noted.

Peter

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 28 Jan 2013 21:44:04 -0500

Peter,

> like <a href='acct:[email-masked]'>Bob</a> precisely because the 'acct'
> scheme is define primarily for the purpose of identification, not
> interaction.
> 
> However, given that people are still confused about this after saying it
> so many times, perhaps it needs to be even clearer in the spec? As in,
> even, a MUST NOT?

While the above might not be encouraged, people could still do that.  What
the browser does when it sees any URI scheme is really implementation
dependent.  There's a general agreement on what to do with http or https,
but there isn't agreement on what to do with mailto, ftp, sftp, etc.  Some
browsers do nothing.  Some launch default applications, usually
user-specified.  Personally, I think it would be cool if the browser
displayed some kind of user profile page for such URIs, but having MUST NOT
would make that illegal.

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jan 2013 20:02:09 -0700

On 1/28/13 7:44 PM, Paul E. Jones wrote:
> Peter,
> 
>> As we've discussed before, we're not encouraging people to do
>> things like <a href='acct:[email-masked]'>Bob</a> precisely
>> because the 'acct' scheme is define primarily for the purpose of
>> identification, not interaction.
>> 
>> However, given that people are still confused about this after
>> saying it so many times, perhaps it needs to be even clearer in
>> the spec? As in, even, a MUST NOT?
> 
> While the above might not be encouraged, people could still do
> that.  What the browser does when it sees any URI scheme is really
> implementation dependent.  There's a general agreement on what to
> do with http or https, but there isn't agreement on what to do with
> mailto, ftp, sftp, etc.  Some browsers do nothing.  Some launch
> default applications, usually user-specified.  Personally, I think
> it would be cool if the browser displayed some kind of user profile
> page for such URIs, but having MUST NOT would make that illegal.

Well, that's more of a UI issue than a protocol issue anyway, so I
don't think MUST NOT would be appropriate...

Peter

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

---

From: SM <[email-masked]>
Date: Mon, 28 Jan 2013 21:57:20 -0800

Hi Peter,
>That's not interoperability, that's multi-functionality. :-)

:-)

>it so many times, perhaps it needs to be even clearer in the spec? As

Thanks for the explanation.  I see what you mean by "typically passed 
around as a parameter in the background within a protocol flow so 
that an entity can interact with the resource identified".  I don't 
think a "MUST NOT" is needed.

>So don't shove the URI into hyperlinks and so on.

Ok.

Regards,
-sm

---

From: Daniel Pocock <[email-masked]>
Date: Tue, 29 Jan 2013 10:10:03 +0100

On 29/01/13 06:57, SM wrote:
> around as a parameter in the background within a protocol flow so that
> an entity can interact with the resource identified".  I don't think a
> "MUST NOT" is needed.
>

I don't want to be hijacking this draft for my own convenience with an
omni-URL, but I feel that proposing or even referring to such an
alternative might be the best way to show people how acct: is not
intended to be used.

Looking at the IANA registry, I notice the following

Permanent, generic:  im, pres, mailto, tel
Permanent, specific:  sip, xmpp, h323

Provisional, generic: sms, mms
Provisional, specific: callto   (for Netmeeting?)

Could callto: be suggested for (try any of) sip/xmpp/h323 (if a NAPTR
exists) and based on the client capabilities?

Could a more general prefix like `contact:' be useful to indicate that
an acct is contactable?

---

From: Goix Laurent Walter <[email-masked]>
Date: Tue, 29 Jan 2013 11:22:17 +0100

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di Peter Saint-Andre
> Inviato: martedì 29 gennaio 2013 4.02
> A: Paul E. Jones
> Oggetto: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-
> acct-uri-02
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

+1 for the scenario and the consideration. Some browsers and mobile phones may trigger intents based on a click on an acct: uri. Then it is up to the app logic to offer other alternatives of "communication" if applicable (because of the jrd answer containing some pointers for example), or of retrieving additional information etc

walter

>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlEHO7EACgkQNL8k5A2w/vy0NwCdH0ojoHH47XgCHYuN49nSl4FC
> eXkAoPX3WFUWGQWyVTNGVybN2OMBRB9t
> =SdsB
> -----END PGP SIGNATURE-----

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 29 Jan 2013 11:03:12 -0500

Section 3 says, in part,

    For example, an 'acct' URI would not be used as follows:

    <a href='acct:[email-masked]'>find out more</a>

For many kinds of accounts, there are reasonable ways to resolve that 
URI to an HTTP URL and show a representation of the account.

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?

-Evan

-- 
Evan Prodromou, CEO and Founder, StatusNet Inc.
1124 rue Marie-Anne Est #32, Montreal, Quebec, Canada H2J 2B7
E: [email-masked] P: +1-514-554-3826

---

From: Evan Prodromou <[email-masked]>
Date: Mon, 28 Jan 2013 21:13:06 -0500

Section 3 says, in part,

For many kinds of accounts, there are reasonable ways to resolve that 
URI and show a representation of the account in the browser.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 29 Jan 2013 11:45:36 -0500

On 13-01-28 09:13 PM, Evan Prodromou wrote:
> I believe there's been some experimental work on this with Webfinger 
> in particular:
>
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]

-Evan

---

From: Melvin Carvalho <[email-masked]>
Date: Tue, 29 Jan 2013 17:49:55 +0100

On 29 January 2013 17:45, Evan Prodromou <[email-masked]> wrote:

>  For many kinds of accounts, there are reasonable ways to resolve that URI
> and show a representation of the account in the browser.
>
> 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.

---

From: Bill Mills <[email-masked]>
Date: Tue, 29 Jan 2013 08:55:05 -0800

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.

________________________________
 From: Melvin Carvalho <[email-masked]>
To: Evan Prodromou <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Tuesday, January 29, 2013 8:49 AM
Subject: Re: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-acct-uri-02

>>><a href='acct:[email-masked]'>find out more</a>
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:
>>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.

---

From: James M Snell <[email-masked]>
Date: Tue, 29 Jan 2013 10:42:18 -0800

I'm really just now starting to turn my attention to the acct uri aspect of
the WebFinger discussion.. generally speaking I'm +1 on the current
acct-uri draft. When going through various implementation scenarios,
however, one thought did strike me, although it may be a bit too late in
the game to put this on the table at all. I apologize for making this late
suggestion...

In some scenarios, such as hosted cloud application environments, a service
provider may wish to host the information about a given user within a
different domain. For instance, suppose Company Foo.com utilizes services
from ISV Bar.com. The user accounts, however, are drawn from Foo.com, but
Bar.com is the provider that actually hosts the profiles and account
information. What I want is something that identifies the user account AND
the service provider.

Example:

  acct:[email-masked]?provider=bar.com<http://acct:[email-masked]/?provider=bar.com>

In a WebFinger type of scenario, resolving this would involve something
like...

  GET /.well-known/webfinger?resource=[email-masked]
  Host: bar.com

Encoding the third party provider into the URL in this way provides a
fairly flexible way of enabling the third party support without complicated
redirects from foo.com to bar.com. It also gives domains a way of enabling
bits of information to be shared from multiple sources...
acct:[email-masked]?provider=isv1.com<http://acct:[email-masked]/?provider=isv1.com>
 vs. acct:[email-masked]?provider=isv2.com<http://acct:[email-masked]/?provider=isv2.com>

To enable this kind of thing, it would be helpful if the basic acct URI
syntax allowed for optional parameters like the mailto URI scheme does
(RFC2368). The specific parameters themselves can be figured out later...

- James

p.s. My apologies for those of you who received this comment twice, I
inadvertently posted it to the webfinger list as feedback to the WF last
call thread. It really belongs over here instead...

On Mon, Jan 28, 2013 at 11:07 AM, SM <[email-masked]> wrote:

>> draft-ietf-appsawg-acct-uri-**02.txt ("The 'acct' URI Scheme")
>> http://tools.ietf.org/id/**draft-ietf-appsawg-acct-uri-**02.txt<http://tools.ietf.org/id/draft-ietf-appsawg-acct-uri-02.txt>
>>
>

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Jan 2013 20:15:56 +0000

I've read through the draft, and it seems essentially good.

I tend to agree that having an acct URI directly within an HTML anchor
element is not really something to be ruled out, but I understand the point
of that paragraph to be declaring the scheme to be protocol independent,
and not have a standard resolution.

I'll have a try at crafting some text.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 29 Jan 2013 20:21:14 +0000

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:

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

---

From: SM <[email-masked]>
Date: Tue, 29 Jan 2013 17:06:33 -0800

Hi James,
At 10:42 29-01-2013, James M Snell wrote:
>In some scenarios, such as hosted cloud application environments, a 
>service provider may wish to host the information about a given user 
>within a different domain. For instance, suppose Company Foo.com 
>utilizes services from ISV Bar.com. The user accounts, however, are 
>drawn from Foo.com, but Bar.com is the provider that actually hosts 
>the profiles and account information. What I want is something that 
>identifies the user account AND the service provider.

Section 2 of the draft mentions that:

   'The "Internet resource" identified by an 'acct' URI is a
    user's account hosted at a service provider, where the service
    provider is typically associated with a DNS domain name.'

The definition would have to be reviewed if you would like to cover 
vanity domains.  The problem could also be restated as a de-referencing issue.

Regards,
-sm