Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04

This is a good point. Remember that email itself doesn't need nor use 
mailto:. It's HTML and other locations where mailto: is used.

Regards,   Martin.

On 2012/05/18 3:31, Paul E. Jones wrote:
> John,
>
>
>
> The "acct" URI would not be typed into an OpenID login box, but that does
> not mean it would never be used.  Users do not usually type in "xmpp:" or
> "mailto:", either, but they are nonetheless useful.  The "acct" URI scheme
> would be used similarly.  The query over the wire would request the XRD/JRD
> document for the account identified by that acct URI.
>
>
>
> Further, inside the XRD/JRD document, there may be link relations that allow
> a user to reference his or her other accounts at various services.  These
> references might allow WF queries to span across multiple domains and learn
> information such as where my photo stream is located, where my public file
> storage is located, etc.  It is a means of linking social networking
> accounts, etc.  I have this example earlier:
>
>
>
> <Link rel="acct" href="acct:paulej@cool_new_pic_service"/>
>
> <Link rel="acct" href="acct:10475893@cool_new_cloud_storage_service"/>
>
> <Link rel="acct" href="acct:543543@cool_new_social_network"/>
>
> <Link rel="acct" href="acct:paulej555@cool_new_whatever"/>
>
>
>
> These "href" values all refer to some kind of URI.  No current URI scheme is
> appropriate.  We can slaughter an existing one, but it's not the right
> solution, IMO.
>
>
>
> Paul
>
>
>
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]
> On Behalf Of John Bradley
> Sent: Thursday, May 17, 2012 10:43 AM
> To: Graham Klyne
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] [OAUTH-WG] draft-jones-appsawg-webfinger-04
>
>
>
> Graham,
>
>
>
> The use of acct: is not dissimilar to the proposed use in Handle
> <http://www.itu.int/osg/csd/emerging_trends/handle_system/index.html>   or
> XRI<http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html>
>
>
>
> It provides a new namespace for Identifiers and uses its own resolver WF to
> deference them to http uri for retrieval.
>
>
>
> Arguably Handle and XRI added persistence and other arguments that are not
> present in acct:/WF.
>
>
>
> As far as linking to a XRD document using acct: requiring the use of the WF
> resolver the XRD can just as easily contain the http URI enabling direct
> access.
>
>
>
> I can't see the requirement for a new scheme based simply on needing a new
> link relationship.
>
>
>
> Someone will also eventually notice that we are effectively duplicating the
> existing http: syntax for naming a user at a domain
> "http://jbradley@foo.com".
>
>
>
> If acct: is used simply as an identifier, that is never intended for a user
> to type then the argument for a new scheme is weak.
>
>
>
> If acct: is intended to be a new name resolution protocol (It is) then it is
> causing namespace fragmentation and breaking the semantic web.
>
>
>
> I have had the W3C TAG intervene on OASIS standards wanting to register a
> new scheme so I am cautious.
>
>
>
> Registering acct: vs info:acct: is important from a browser behaviour point
> of view if a user clicks on a link.
>
> What browser support do people anticipate for WF?   Do people expect to
> place acct:jbradley@foo.com as a link in a html document and have something
> useful happen if the user clicks on it?
>
> I know we did in XRI, and that was part of the scheme justification.
>
>
>
> WF should start the registration process for acct: now to enable the
> inevitable wider debate.
>
>
>
> Until there is at least a provisional registration, we probably should not
> make the scheme registration a requirement in the proposed starting
> document.
>
>
>
> John B.
>
>
>
>
>
> On 2012-05-17, at 9:05 AM, Graham Klyne wrote:
>
>
>
>
>
> On 17/05/2012 10:52, Melvin Carvalho wrote:
>
>
>
> I don't know about the particulars of your proposed acct: scheme, but as a
>
>>   thought experiment, does it achieve anything that could not be achieved
> as
>
>>   easily with (something like):
>
>>      http://acct.example.org/<your string here>
>
>>   ?
>
>>
>
>>   (Bearing in mind that it does not matter that
> thehttp://acct.example.org/URI  may be not dereferencable.)
>
>>
>
> Facebook do something quite similar to this with
>
> graph.facebook.com/user... my suggestion from the webfinger list was
>
> http://host/@/user, but there are possible deployment issues.
>
>
>
> One tricky thing with the approach suggested, is that you dont know whether
>
> you will be dealing with http or https until you try, so there's
>
> potentially an extra round trip.
>
>
> If the URI is being used primarily for identification purposes, and is not
> used operationally for dereferencing as-is, that seems a minor issue.  If
> the http: URI is also used to serve as a route to "follow-your-nose"
> high-level information, why would it be published using https?
>
> #g
> --
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss