Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-01.txt

From: [email-masked]
Date: Thu, 18 Oct 2012 20:20:56 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

	Title           : The 'acct' URI Scheme
	Author(s)       : Peter Saint-Andre
	Filename        : draft-ietf-appsawg-acct-uri-01.txt
	Pages           : 7
	Date            : 2012-10-18

Abstract:
   This document defines the 'acct' URI scheme as a way to identify a
   user's account at a service provider, irrespective of the particular
   protocols that can be used to interact with the account.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Oct 2012 21:30:50 -0600

Some relatively small tweaks to address feedback received. (However, I
realize just now that the ABNF simplification might not be what we want...)

Peter

On 10/18/12 9:20 PM, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Graham Klyne <[email-masked]>
Date: Sun, 21 Oct 2012 09:34:47 +0100

Hi Peter,

I've made this comment before, but I didn't get any clear sense of rtesolution 
in the ensuing discussion.

With the scheme semantics watered down to point that dereferencing is defined 
only in the context of a protocol in which is appears, I'm not seeing why this 
justifies being a new URI scheme.

For example, if I am browsing an HTML document (obtained by unspecified means) 
containing "<a href='acct:[email-masked]'>foo account</a>", can I not expect 
anything consistent to happen if I click on this link?

When I was involved in earlier reviews of this scheme, part of the reason I 
perceived that justified it being a separate URI scheme was that dereferencing 
would be performed using the WebFinger protocol, irrespective of the service for 
which for which is may be an account identifier.  This does not prevent use of 
the acct: URI in specialized contexts which handle it in different ways (such as 
lookup against a table of known accounts).

If you feel this point was fully considered and disregarded for cogent reasons, 
then I don't feel so strongly about this to pursue it, but I'm not sure if it 
might be falling through the cracks.

#g
--

On 19/10/2012 04:30, Peter Saint-Andre wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 21 Oct 2012 11:51:59 -0400

Graham,

My opinions on this...

If the browser encountered "acct:", I would like to have the browser open up
a "page" that displays the information obtained via WebFinger.  It might be
presented in the form of a user "profile" page, showing the person's
picture, name, contact information, blog URL, etc.  It might not show
everything discovered, since the browser may not know what the rel type
"foo" means, but it could assemble a useful page for known data elements.

At least that was my thought for using "acct" within the context of an HTML
page.

Outside of an HTML page, "acct" would be used by WebFinger to query for
information about a user account and the client issuing the query might be
looking for lots of information or very specific pieces of information
(e.g., an OpenID URL).

I think there was a question raised on the list before about "do we see use
of acct outside of WebFinger."  I think it might be used outside, e.g., in
HTML documents, but my assumption had been that it would still relate to a
WebFinger query.  It might be used elsewhere, but the main driver has been
WebFinger.

Paul

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Graham Klyne
> Sent: Sunday, October 21, 2012 4:35 AM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-
> 01.txt
> 
> Hi Peter,
> 
> I've made this comment before, but I didn't get any clear sense of
> rtesolution in the ensuing discussion.
> 
> With the scheme semantics watered down to point that dereferencing is
> defined only in the context of a protocol in which is appears, I'm not
> seeing why this justifies being a new URI scheme.
> 
> For example, if I am browsing an HTML document (obtained by unspecified
> means) containing "<a href='acct:[email-masked]'>foo account</a>", can
> I not expect anything consistent to happen if I click on this link?
> 
> When I was involved in earlier reviews of this scheme, part of the
> reason I perceived that justified it being a separate URI scheme was
> that dereferencing would be performed using the WebFinger protocol,
> irrespective of the service for which for which is may be an account
> identifier.  This does not prevent use of the acct: URI in specialized
> contexts which handle it in different ways (such as lookup against a
> table of known accounts).
> 
> If you feel this point was fully considered and disregarded for cogent
> reasons, then I don't feel so strongly about this to pursue it, but I'm
> not sure if it might be falling through the cracks.
> 
> #g
> --
> 
> 
> >> Internet-Draft directories: http://www.ietf.org/shadow.html or
> >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>

---

From: Graham Klyne <[email-masked]>
Date: Mon, 22 Oct 2012 20:22:04 +0100

Paul,

I regard your position here as being consistent with dereferencing of acct: URIs 
using WebFinger.  Some additional use of content negotiation (recalling that 
WebFinger is HTTP-based) might be needed to achieve the full effect in-browser 
that you describe, but IMO the principle that WebFinger is the main/default 
mechanism for dereferencing acct: URIs stands.

#g
--