Subject: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

From: Graham Klyne <[email-masked]>
Date: Wed, 15 Aug 2012 10:47:35 +0100

ref: http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-00

I'm uneasy about:

[[
4.4.  URI Scheme Semantics

    The 'acct' URI scheme is used to identify user accounts hosted at
    service providers.  It is used only for identification, not
    interaction.  A protocol that uses the 'acct' URI scheme is
    responsible for specifying how an 'acct' URI is to be dereferenced in
    the context of that protocol.  There is no media type associated with
    the 'acct' URI scheme.
]]

Specifically, the bit about "protocol that uses the acct URI scheme".

My understanding was that the intent was that acct: would be dereferenced using 
the WebFinger protocol.  If there is no such expectation, then an acct: URI 
appearing in isolation (e.g. in a web page or some document) has no actionable 
meaning.

For me, this was a key argument for acct: to be a URI scheme rather than a URN 
namespace.

#g

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 16 Aug 2012 12:30:03 -0600

On 8/15/12 3:47 AM, Graham Klyne wrote:
> [[ 4.4.  URI Scheme Semantics
> 
> responsible for specifying how an 'acct' URI is to be dereferenced
> in the context of that protocol.  There is no media type associated
> with the 'acct' URI scheme. ]]
> 
> My understanding was that the intent was that acct: would be 
> dereferenced using the WebFinger protocol.  If there is no such 
> expectation, then an acct: URI appearing in isolation (e.g. in a
> web page or some document) has no actionable meaning.

My understanding, which I tried to capture in the document, was that
some folks here thought that acct URIs might be used by other
protocols. If there is consensus that acct URIs will be used only for
WebFinger, I am happy to update the document accordingly. I'm truly
just acting in an editorial capacity on this document.

Peter

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 16 Aug 2012 19:45:17 +0000

Several examples of other protocols that could/might/may/would have used acct: have already been discussed on the list.  It's definitely not only for WebFinger.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, August 16, 2012 11:30 AM
To: Graham Klyne
Cc: [email-masked]
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

On 8/15/12 3:47 AM, Graham Klyne wrote:
> the 'acct' URI scheme. ]]
> 
> expectation, then an acct: URI appearing in isolation (e.g. in a web 
> page or some document) has no actionable meaning.

My understanding, which I tried to capture in the document, was that some folks here thought that acct URIs might be used by other protocols. If there is consensus that acct URIs will be used only for WebFinger, I am happy to update the document accordingly. I'm truly just acting in an editorial capacity on this document.

Peter

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

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

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Thu, 16 Aug 2012 16:05:23 -0400

On Aug 16, 2012, at 2:30 PM, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
I had the same understanding.  Consensus was to divorce acct from WebFinger so it would have its own standalone fate and not affect that of WebFinger. Additionally, it was argued that, while still relatively narrow in scope, it could be implemented in various other protocols satisfying the general need for "I need information about this user" when it's not in the context of a specific application protocol.

A small sampling supporting this: 
 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06615.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06462.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06693.html
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06463.html

Cheers,

Gonzalo

> Peter
> 
> - -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAlAtPCsACgkQNL8k5A2w/vyOUwCeMAUUJ7bEo4wkzArj4VzNJ4Qw
> 1dwAn1Jv1leY03gD3oB1lYUfxFKOuH1s
> =ADc0
> -----END PGP SIGNATURE-----

---

From: Melvin Carvalho <[email-masked]>
Date: Fri, 17 Aug 2012 15:03:33 +0200

> just acting in an editorial capacity on this document.

Once a new scheme/protocol is established, it can sometimes be hard to
predict which specifications will make use of it, in the future.

Tho acct: is currently recommended in the webfinger RFC.  I think it was
pretty much consensus that webfinger could operate with various URI schemes
e.g. mailto: http: acct: etc.

Thus, my impression was that it was viewed as an advantage, that neither
spec, becomes a blocker for the other.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 17 Aug 2012 09:47:32 -0400

I see the acct: URI scheme as signifying an account and WebFinger as a
protocol for obtaining information about accounts.

WebFinger applications may attempt to dereference any URI that is
'accountish' that they like. The point of choosing the acct: URI as
canonical is to define the version that should work.

acct: is what mailto: should have been in the first place. The problem
with mailto is that it conflates the entity signified 'mail recipient'
with the action to be performed 'send them an email'. This was always
a bad choice as what I often want to do with an email recipient is to
put the address in my address book.

-- 
Website: http://hallambaker.com/

---

From: Graham Klyne <[email-masked]>
Date: Mon, 20 Aug 2012 09:51:30 +0100

> just acting in an editorial capacity on this document.

I certainly understand that the intent is that acct: URIs can be used *with* 
other protocols, it's just that I also understood the standard dereferencing 
mechanism (or, if you like, the definitive identification semantics) is defined 
by the WebFinger protocol.

An example for comparison: the standard dereferencing semantics for an ftp: URI 
is to use the FTP protocol, but an ftp: URI can be used with the HTTP protocol.

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Aug 2012 10:22:08 -0600

On 8/20/12 2:51 AM, Graham Klyne wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>> The 'acct' URI scheme is used to identify user accounts hosted
>>> at service providers.  It is used only for identification, not 
>>> responsible for specifying how an 'acct' URI is to be
>>> dereferenced in the context of that protocol.  There is no
>>> media type associated with the 'acct' URI scheme. ]]
>>> 
>>> dereferenced using the WebFinger protocol.  If there is no
>>> such expectation, then an acct: URI appearing in isolation
>>> (e.g. in a web page or some document) has no actionable
>>> meaning.
>> 
>> My understanding, which I tried to capture in the document, was
>> that some folks here thought that acct URIs might be used by
>> other protocols. If there is consensus that acct URIs will be
>> used only for WebFinger, I am happy to update the document
>> accordingly. I'm truly just acting in an editorial capacity on
>> this document.
> 
> I certainly understand that the intent is that acct: URIs can be
> used *with* other protocols, it's just that I also understood the
> standard dereferencing mechanism (or, if you like, the definitive
> identification semantics) is defined by the WebFinger protocol.
> 
> An example for comparison: the standard dereferencing semantics for
> an ftp: URI is to use the FTP protocol, but an ftp: URI can be used
> with the HTTP protocol.

Graham, thank you for drawing the distinction between using acct URIs
and dereferencing acct URIs. I have not yet heard of anyone proposing
to dereference acct URIs using technologies other than WebFinger,
although if the Simple Web Discovery work
(draft-jones-simple-web-discovery) continues independently then it
seems possible that acct URIs might be derefenced using that
technology. For example :

   GET /.well-known/simple-web-discovery
       ?principal=acct:[email-masked]
       &service=urn:example:service:calendar HTTP/1.1
   Host: example.com

   HTTP/1.1 200 OK
   Content-Type: application/json

   {
    "locations": ["https://calendars.example.net/calendars/joseph"]
   }

Clarification would be appreciated from folks on this list. I just
hold the editing pen on this one.

Peter

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 23 Aug 2012 18:49:36 +0000

Yes, SWD could make use of an acct: URI, should one be approved, and should SWD continue to be used.  SWD's current solution to not having an acct: uri is to allow bare identifiers such as "[email-masked]" or simply "joe" to be used as the principal value.  (I'm not saying that I want there to continue to be two parallel discovery solutions in use, however.)

As long as I'm writing about the acct: URI, let me add my voice supporting allowing local account identifiers such as "acct:joe" to be used, in addition to fully qualified names such "acct:[email-masked]".  The reason that this this can work fine for discovery is that if you're contacting the discovery server at example.com, the identifier "acct:joe" is unambiguous in that context.

Going meta, is the question about whether to allow local acct: identifiers the only open issue for the spec?  If there are others, could we try to identify them soon?  It would be really good for us to try to identify the open issues, discuss them, and drive them to closure, now that we have a working group specification.

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, August 23, 2012 9:22 AM
To: Graham Klyne
Cc: [email-masked]
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

On 8/20/12 2:51 AM, Graham Klyne wrote:
> I certainly understand that the intent is that acct: URIs can be used 
> *with* other protocols, it's just that I also understood the standard 
> dereferencing mechanism (or, if you like, the definitive 
> An example for comparison: the standard dereferencing semantics for an 
> ftp: URI is to use the FTP protocol, but an ftp: URI can be used with 
> the HTTP protocol.

Graham, thank you for drawing the distinction between using acct URIs and dereferencing acct URIs. I have not yet heard of anyone proposing to dereference acct URIs using technologies other than WebFinger, although if the Simple Web Discovery work
(draft-jones-simple-web-discovery) continues independently then it seems possible that acct URIs might be derefenced using that technology. For example :

   HTTP/1.1 200 OK

   {

Clarification would be appreciated from folks on this list. I just hold the editing pen on this one.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Aug 2012 13:41:18 -0600

On 8/23/12 12:49 PM, Mike Jones wrote:

> As long as I'm writing about the acct: URI, let me add my voice 
> supporting allowing local account identifiers such as "acct:joe"
> to be used, in addition to fully qualified names such 
> "acct:[email-masked]".  The reason that this this can work fine
> for discovery is that if you're contacting the discovery server at 
> example.com, the identifier "acct:joe" is unambiguous in that 
> context.

Mike, to date it appears that you and Phillip Hallam-Baker have been
in favor of local account identifiers such as "acct:joe", the idea
being that "an acct: name that does not have a domain name part is
going to have to be resolved in the same fashion as relative URIs are
- - by reference to context and local state" (as Phil said in a message
to this list on July 2).

Martin Thomson, John Bradley, Graham Klyne, and I expressed concerns
about the implicit nature of such identifiers and the resulting
fragility in systems that use them, and about our understanding that
"URIs are intended to be a global namespace" (as Graham said in a
message to this list on July 2).

Mike, what are your thoughts now about the issues that Martin, John,
Graham, and I raised at the beginning of July?

Peter

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Aug 2012 15:55:56 -0400

I don't know who told you that all URIs had to be globally unique but
there have been relative URIs from the very start.

The URI syntax permits an identifier to be specified in a fashion that
is unique or relative. The part that is critical is that it must be
possible to distinguish which one is intended from the syntax alone.

On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre <[email-masked]> wrote:
> iEYEARECAAYFAlA2h14ACgkQNL8k5A2w/vy3dQCg6aVB692w70Rqcq0JqcFB7OtC
> bDQAnj9ytEQB5hRgOptWdMSGl7+loTls
> =RyI0

---

From: Tim Bray <[email-masked]>
Date: Thu, 23 Aug 2012 13:04:48 -0700

A URI is absolute and unique.  A “URI Reference” may be relative, but
in general they only exist and are used in contexts where they may be
absolutized.  I.e. there’s no problem when you find <a
href="pix/cat.jpg"> in a web page that you’ve fetched, but if you
fetch the HTML with curl and leave it on a local hard disk, you’ve
created a bug.  -T

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 25 Aug 2012 01:21:02 +0900

> there have been relative URIs from the very start.

Yes indeed. And URI schemes that are not global at all, such as file:.

> possible to distinguish which one is intended from the syntax alone.

Yes. But please note that "acct:joe" is not a relative version of 
"acct:[email-masked]" in the sense that given a base URI of 
acct:[email-masked]" and an URI of "acct:joe", the relative resolution 
algorithm (see http://tools.ietf.org/html/rfc3986#section-5.2) does NOT 
produce "acct:[email-masked]". So "acct:joe" may be called local (or 
whatever) but cannot be called relative.

Regards,   Martin.

> On Thu, Aug 23, 2012 at 3:41 PM, Peter Saint-Andre<[email-masked]>  wrote:

---

From: John Bradley <[email-masked]>
Date: Fri, 24 Aug 2012 13:23:21 -0400

I agree that as long as there is a way to distinguish a relative acct: URI from a fully qualified one I don't have a problem.

In with HTTP you can make a relative reference in html.
However you can't really pass around /foo/bar without context.

For a acct: uri to be relative I am OK with omitting the host subsegment. 

We may also need to define a format for specifying the base acct:@example.com

It just needs to be thought through as it is not exactly like a http relative URI.

John B.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Aug 2012 13:47:33 -0400

acct:joe is relative to the accounts file of the server to which it is
addressed. That is not a DNS qualified domain unless people want to
count .local or .corp.

Call it contextually bound or whatever if people like.

Just like other incomplete URIs this is a form that is going to be
easily resolved by context. If your host is in a windows domain, well
you really know that, same for UNIX.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Aug 2012 19:55:56 +0200

> It just needs to be thought through as it is not exactly like a http relative URI.

Please don't confuse what's being discussed with "relative references", 
as described in RFC 3986, Section 4.2. They are not, and this is IMHO 
explains why people (including me) are unhappy.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Fri, 24 Aug 2012 23:44:15 +0000

I agree that it's not a relative reference, in the RFC 3986 sense.  It's intended to be a context-dependent reference, as explained by Phillip.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Friday, August 24, 2012 10:56 AM
To: John Bradley
Cc: Graham Klyne; [email-masked]
Subject: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt

> It just needs to be thought through as it is not exactly like a http relative URI.

Please don't confuse what's being discussed with "relative references", as described in RFC 3986, Section 4.2. They are not, and this is IMHO explains why people (including me) are unhappy.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 24 Aug 2012 19:21:26 -0600

On 8/24/12 5:44 PM, Mike Jones wrote:
> I agree that it's not a relative reference, in the RFC 3986 sense. 
> It's intended to be a context-dependent reference, as explained by 
> Phillip.

Can you point to examples of context-dependent references in other URI
schemes, or would the acct scheme be breaking new ground here?

Peter

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

---

From: William Mills <[email-masked]>
Date: Fri, 24 Aug 2012 21:50:51 -0700 (PDT)

An interesting question here is.... In the windows world an account might be represented as NAMESPACE\username, do we handle this with acct:?  

>________________________________
> From: Peter Saint-Andre <[email-masked]>
>To: Mike Jones <[email-masked]> 
>Cc: Julian Reschke <[email-masked]>; Graham Klyne <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Friday, August 24, 2012 6:21 PM
>iEYEARECAAYFAlA4KJYACgkQNL8k5A2w/vzaRACfVlVAaVnYEdXs9B82kLP6C9s8
>3v0AoNm2q4cKeMMmbexxa539uc10Z7fH
>=ez0H

---

From: Graham Klyne <[email-masked]>
Date: Tue, 28 Aug 2012 16:41:10 +0100

> schemes, or would the acct scheme be breaking new ground here?

The one that springs to mind is file:, which (in my experience) is almost always 
used in a localized context.  (Relative references are a red herring here.) 
Another is about:, which is specifically defined for accessing a local context.

I think there's some conflation going on of my earlier comment that you quoted 
("URIs are intended to be a global namespace") with the notion that every URI 
must be a global identifier with a unique referent.

I made my comment when speaking in support of keeping the domain name part, this 
was on the basis that I could see acct: URIs likely to be used in ways that 
escape their original context; e.g. as a hyperlink in a document.  In the case 
of file: - if a file: URI (as opposed to a relative reference, which is by 
definition scheme-free) appears in (say) a web page, it's usually an error.

That said, I will also concede that the web already lives with contextualized 
URIs, so if there really is a compelling case for domain-less acct: URIs, I 
could live with that.

I've said previously that I think the acct: scheme should be associated with a 
specific dereferencing mechanism (i.e. WebFinger - so it can be used as a 
generic hyperlink).  If domain-free acct: URIs are allowed, then I think 
something should also be said about how they should be dereferenced.

#g

---

From: elf Pavlik <[email-masked]>
Date: Tue, 28 Aug 2012 17:05:04 +0000

> As long as I'm writing about the acct: URI, let me add my voice supporting allowing local account identifiers such as "acct:joe" to be used, in addition to fully qualified names such "acct:[email-m…

While ago I've suggested on webfinger mailing list to allow identifiers without local part, just: @domain.tld
This way projects could have sort of catch all accounts like: @ietf.org and people having personal domains could also just use @name.me (rather than [email-masked] or [email-masked] etc.) It seams to me attractive if used in ostatus for federated microblogging.

On that thread someone also mentioned that in xmpp realm @domain.tld makes a valid jid but i haven't research it further yet :(

original thread: https://groups.google.com/d/topic/webfinger/DErWmYpXdzE/discussion

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 11:50:29 -0600

On 8/28/12 11:05 AM, elf Pavlik wrote:
>> for discovery is that if you're contacting the discovery server
>> at example.com, the identifier "acct:joe" is unambiguous in that 
>> context.
> 
> While ago I've suggested on webfinger mailing list to allow 
> identifiers without local part, just: @domain.tld

Hmm, if local part and domain part are both optional, can we also have
"acct:@"? ;-)

> This way projects could have sort of catch all accounts like:
> @ietf.org and people having personal domains could also just use
> @name.me (rather than [email-masked] or [email-masked] etc.)

Yes, I recall that discussion, and if I recall correctly most people
thought it wasn't a great idea. What does it mean to, say, perform a
WebFinger query against a bare domain?

> It seams to me attractive if used in ostatus for federated
> microblogging.

Could you perhaps explain that scenario in a bit more detail? I'm
curious to learn what requirements that brings in.

> On that thread someone also mentioned that in xmpp realm
> @domain.tld makes a valid jid but i haven't research it further yet
> :(

You can have xmpp:domain.tld (the address of a server), but you can't
have xmpp:@domain.tld (some sort of catch-all for all accounts at the
server??).

Peter

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

---

From: John Bradley <[email-masked]>
Date: Tue, 28 Aug 2012 14:06:39 -0400

For protocols like openID that attempt too preserve privacy there is the concept of a directed Identifier, one that provides generic account information  to the RP and allows the user to select a specific identifier at the IdP so it can provide a pseudonymous identifier to the RP.

So from a privacy perspective there is a need to signal do account selection at the IdP, there may be other uses for a generic user discovery account as well.

In openID Connect's use of SWD the user enters the domain of the IdP to trigger account selection at the IdP.

I guess the question is if we were using Web-Finger and the user enters example.com what would the RP normalize that to,  or would the rule be to treat it as a http: URI if it doesn't have a @ or a scheme.

Given that Web-Finger is attempting to normalize input into acct: uri as opposed to just passing the input to the server we need to be clear on how input is normalized.

I also don't underestimate the challenge of pulling the server out of a random string a user inputs.

I expect to see people try inputing a lot of creative things.

John B.

On 2012-08-28, at 1:50 PM, Peter Saint-Andre <[email-masked]> wrote:

> iEYEARECAAYFAlA9BOUACgkQNL8k5A2w/vxLogCcDWpb4yoaDbj/vOkEkvhQ6iAk
> sToAniB2GuXTz+u2uX+2dqa5ILZhgT2g
> =Z/Nw

---

From: ☮ elf Pavlik ☮ <[email-masked]>
Date: Tue, 28 Aug 2012 18:18:51 +0000

> WebFinger query against a bare domain?
Yes, many people mentioned the original intention to mimic familiar to most people email addresses

> curious to learn what requirements that brings in.
At some point i thought that for example twitter specific: @ietf could become possibly self hosted @ietf.org
as well as people with personal domains could use just identifiers like @franky.me and choose where they want to host their accounts.

I also recall Markus Sabadello enthusiasm to in some ways infamous i-names which just use =name for individuals and @name for organizations
https://en.wikipedia.org/wiki/I-name

Honestly I just wanted to hear more opinions about it, seeing myself possible convenience in having option to just skip local part.

> have xmpp:@domain.tld (some sort of catch-all for all accounts at the
Thanks for clarifying, also acct:domain.tld looks also somehow more sane than acct:@domain.tld :)

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 12:49:09 -0600

On 8/28/12 9:41 AM, Graham Klyne wrote:
>>> I agree that it's not a relative reference, in the RFC 3986
>>> sense. It's intended to be a context-dependent reference, as
>>> explained by Phillip.
>> 
>> Can you point to examples of context-dependent references in
>> other URI schemes, or would the acct scheme be breaking new
>> ground here?
> 
> The one that springs to mind is file:, which (in my experience) is 
> almost always used in a localized context.  (Relative references
> are a red herring here.) Another is about:, which is specifically
> defined for accessing a local context.
> 
> I think there's some conflation going on of my earlier comment that
> you quoted ("URIs are intended to be a global namespace") with the
> notion that every URI must be a global identifier with a unique
> referent.
> 
> I made my comment when speaking in support of keeping the domain
> name part, this was on the basis that I could see acct: URIs likely
> to be used in ways that escape their original context; e.g. as a
> hyperlink in a document.  In the case of file: - if a file: URI (as
> opposed to a relative reference, which is by definition
> scheme-free) appears in (say) a web page, it's usually an error.
> 
> That said, I will also concede that the web already lives with 
> contextualized URIs, so if there really is a compelling case for 
> domain-less acct: URIs, I could live with that.

I confess that I still don't understand the case for domain-less
"acct" URIs. What exactly is the local context, and why would "acct"
URIs be used in that context? For example, I could imagine that a
local context might be accessing a device under my physical control or
using a terminal to access infrastructure on a local network, but it's
not clear to me why one would use an "acct" URI in those scenarios.
What am I missing?

> I've said previously that I think the acct: scheme should be
> associated with a specific dereferencing mechanism (i.e. WebFinger
> - so it can be used as a generic hyperlink).  If domain-free acct:
> URIs are allowed, then I think something should also be said about
> how they should be dereferenced.

Agreed.

Peter

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 28 Aug 2012 15:21:59 -0400

Without the domain part, I would not know what server to go to to issue a
query.  What would a client do with "acct:paulej"?  If there is a "default
server" defined, then a default domain could equally be assigned.  The
latter usually is, anyway.

I think having input forms that accept just "paulej" are reasonable, but
client should construct fully-qualified URIs by adding "acct:" and
"@packetizer.com".

Paul

> Sent: Tuesday, August 28, 2012 2:49 PM
> To: Graham Klyne
> >> Can you point to examples of context-dependent references in other
> >> URI schemes, or would the acct scheme be breaking new ground here?
> >
> > almost always used in a localized context.  (Relative references are a
> > red herring here.) Another is about:, which is specifically defined
> > for accessing a local context.
> >
> > I made my comment when speaking in support of keeping the domain name
> > part, this was on the basis that I could see acct: URIs likely to be
> > used in ways that escape their original context; e.g. as a hyperlink
> > in a document.  In the case of file: - if a file: URI (as opposed to a
> > relative reference, which is by definition
> I confess that I still don't understand the case for domain-less "acct"
> URIs. What exactly is the local context, and why would "acct"
> URIs be used in that context? For example, I could imagine that a local
> context might be accessing a device under my physical control or using a
> terminal to access infrastructure on a local network, but it's not clear
> to me why one would use an "acct" URI in those scenarios.
> What am I missing?
> 
> > URIs are allowed, then I think something should also be said about how
> > they should be dereferenced.
> 
> Agreed.
> 
> Peter
> 
> - --
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> iEYEARECAAYFAlA9EqUACgkQNL8k5A2w/vymJwCgrBQliqt8GO6IGYw8na7ckabK
> BrEAnR/Vkj0AdiRO7heBqXuAOkba5YNa
> =+y5T

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 28 Aug 2012 13:24:59 -0600

On 8/28/12 1:21 PM, Paul E. Jones wrote:
> Without the domain part, I would not know what server to go to to
> issue a query.  What would a client do with "acct:paulej"?  If
> there is a "default server" defined, then a default domain could
> equally be assigned.  The latter usually is, anyway.
> 
> I think having input forms that accept just "paulej" are
> reasonable, but client should construct fully-qualified URIs by
> adding "acct:" and "@packetizer.com".

That's how it seems to me, which is why I'm confused. ;-)

Peter

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

---

From: Goix Laurent Walter <[email-masked]>
Date: Wed, 29 Aug 2012 10:25:03 +0200

> -----Messaggio originale-----
> Da: [email-masked] [mailto:[email-masked]] Per
> conto di ? elf Pavlik ?
> Inviato: martedì 28 agosto 2012 20.19
> A: Peter Saint-Andre
> Cc: apps-discuss
> Oggetto: Re: [apps-discuss] Comment on draft-ietf-appsawg-acct-uri-00.txt
>
> as well as people with personal domains could use just identifiers like
> @franky.me and choose where they want to host their accounts.
>
> I also recall Markus Sabadello enthusiasm to in some ways infamous i-names
> which just use =name for individuals and @name for organizations
> Honestly I just wanted to hear more opinions about it, seeing myself possible
> convenience in having option to just skip local part.
[walter] Personally I'd rather see the value of domain-only rather than domain-less acct: URIs for deployments. In [1] I illustrated a use case for large deployments and federated social networks where lots of webfinger discoveries could happen across users on distinct social networks (e.g. when start cross-following). That email suggested the use of templates and new template variables, which is not exactly the subject here, but the main point remains and allowing domain-only identifiers could help in that.
Potentially a server (knowing in advance it may deal with several users on the same foreign server) could issue a webfinger query to the resource acct:example.com instead of a specific user. I would expect a difference wrt to issuing a pure host-meta query where only a limited subset of endpoints/link rels may be provided: by specifying the domain-only resource explicitly it would be understood as a 2nd level query (meaning extracting the link rels provided by the lrdd descriptor typically) and thus could provide these additional links. Combined with templates (here we can then discuss on the reserved template parameter names) it could become a powerful mechanism to retrieve template-based endpoints that could be valid for all users on that server/domain, thus reducing the number of wf queries for distinct users on the same foreign server. In case some link rels do not follow a specific pattern and are more complex they could simply not be returned in that type of xrd/jrd, and the server would need to issue a user-specific query to retrieve extra link rels if needed.

Here is an example:
GET /.well-known/host-meta.json?resource=acct:example.com HTTP/1.1
Host: example.com

The reply might have this body (using a fictitious "{uri.userpart}" to represent only the user-part of the acct: URI):

{
  "subject" : "acct:example.com",
  "links" :
  [
    {
      "rel" : "http://webfinger.net/rel/avatar",
      "template" : "http://www.example.com/people/{uri}/images/{uri.userpart}.jpg"
    },
    {
      "rel" : "http://webfinger.net/rel/profile-page",
      "template" : "http://www.example.com/people/{uri}"
    },
    {
      "rel" : "http://schemas.google.com/g/2010#updates-from",
      "template" : "http://www.example.com/people/{uri}/blog/blog.xml"
    }
  ]
}

walter

[1] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06073.html

> Thanks for clarifying, also acct:domain.tld looks also somehow more sane than

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: "Paul E. Jones" <[email-masked]>
Date: Wed, 29 Aug 2012 13:57:57 -0400

Walter,

If you query /.well-known/host-meta[.json], one will get a set of link relations that are host-wide and templates that are resource-specific.  Isn't that more-or-less the same as what you are suggesting with acct:example.com?  I don't see the difference.

You can see an example:
curl -v https://packetizer.com/.well-known/host-meta.json

Paul

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Goix Laurent Walter
> Sent: Wednesday, August 29, 2012 4:25 AM
> To: ☮ elf Pavlik ☮; Peter Saint-Andre
> Cc: apps-discuss
> Subject: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
> 
> > Da: [email-masked]
> > [mailto:[email-masked]] Per conto di ? elf Pavlik ?
> > > Hmm, if local part and domain part are both optional, can we also
> > > have "acct:@"? ;-)
> > >
> > At some point i thought that for example twitter specific: @ietf could
> > become possibly self hosted @ietf.org as well as people with personal
> > domains could use just identifiers like @franky.me and choose where
> > they want to host their accounts.
> >
> > I also recall Markus Sabadello enthusiasm to in some ways infamous
> > i-names which just use =name for individuals and @name for
> > organizations https://en.wikipedia.org/wiki/I-name
> >
> > Honestly I just wanted to hear more opinions about it, seeing myself
> > possible convenience in having option to just skip local part.
> [walter] Personally I'd rather see the value of domain-only rather than
> domain-less acct: URIs for deployments. In [1] I illustrated a use case
> for large deployments and federated social networks where lots of
> webfinger discoveries could happen across users on distinct social
> networks (e.g. when start cross-following). That email suggested the use
> of templates and new template variables, which is not exactly the subject
> here, but the main point remains and allowing domain-only identifiers
> could help in that.
> Potentially a server (knowing in advance it may deal with several users on
> the same foreign server) could issue a webfinger query to the resource
> acct:example.com instead of a specific user. I would expect a difference
> wrt to issuing a pure host-meta query where only a limited subset of
> endpoints/link rels may be provided: by specifying the domain-only
> resource explicitly it would be understood as a 2nd level query (meaning
> extracting the link rels provided by the lrdd descriptor typically) and
> thus could provide these additional links. Combined with templates (here
> we can then discuss on the reserved template parameter names) it could
> become a powerful mechanism to retrieve template-based endpoints that
> could be valid for all users on that server/domain, thus reducing the
> number of wf queries for distinct users on the same foreign server. In
> case some link rels do not follow a specific pattern and are more complex
> they could simply not be returned in that type of xrd/jrd, and the server
> would need to issue a user-specific query to retrieve extra link rels if
> needed.
> 
> Here is an example:
> The reply might have this body (using a fictitious "{uri.userpart}" to
> represent only the user-part of the acct: URI):
> 
> {
>       "template" :
> "http://www.example.com/people/{uri}/images/{uri.userpart}.jpg"
>     },
>     {
> > > > @domain.tld makes a valid jid but i haven't research it further
> > > > yet :(
> > >
> > > You can have xmpp:domain.tld (the address of a server), but you
> > > can't have xmpp:@domain.tld (some sort of catch-all for all accounts
> > > at the server??).
> 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: Goix Laurent Walter <[email-masked]>
Date: Thu, 30 Aug 2012 11:39:17 +0200

Hello Paul,

I agree it is "more or less" the same at the end. However I expect that from current implementations of webfinger, very little link rels are provided in the host-meta vs resource-specific descriptor so putting many templates in the host-meta already is not best practice yet afaik.
Of course nothing prevents from changing this behaviour in the future but as this scenario may become mainstream (I do hope that in a few years very big social islands will webfinger each other).

Thus I am wondering whether it could make sense:
- adding it as an example in the draft clarifying the practice and emphasizing the insertion of additional link rel templates already in the host-meta
- specifying new templates variable names to be used in templates, as this scenario makes strong use of templates and may need to reference additional information. The first that comes into my mind (as per the example in my previous email) is the local username, that could be identified as {uri.userpart}, {username} or anything else. Maybe other could also make sense.

Walter

> Da: Paul E. Jones [mailto:[email-masked]]
> Inviato: mercoledì 29 agosto 2012 19.58
> A: Goix Laurent Walter; '☮ elf Pavlik ☮'; 'Peter Saint-Andre'
> Cc: 'apps-discuss'
> Oggetto: RE: [apps-discuss] R: Comment on draft-ietf-appsawg-acct-uri-00.txt
>
> Walter,
>
> If you query /.well-known/host-meta[.json], one will get a set of link
> relations that are host-wide and templates that are resource-specific.  Isn't
> that more-or-less the same as what you are suggesting with acct:example.com?
> I don't see the difference.
>
> You can see an example:

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 31 Aug 2012 21:08:27 -0400

Walter,

> I agree it is "more or less" the same at the end. However I expect that
> from current implementations of webfinger, very little link rels are
> provided in the host-meta vs resource-specific descriptor so putting many
> templates in the host-meta already is not best practice yet afaik.
> Of course nothing prevents from changing this behaviour in the future but
> as this scenario may become mainstream (I do hope that in a few years very
> big social islands will webfinger each other).
> 
> - adding it as an example in the draft clarifying the practice and
> emphasizing the insertion of additional link rel templates already in the
> host-meta

I could certainly show an example similar to what is in RFC 6415 Section 1.1, perhaps adding additional host-wide properties and link relations.  However, I'm not sure what you mean by "emphasizing the insertion of additional link rel templates".  Host-wide information uses link relations, not templates.  Templates are used for resource-specific information.

> - specifying new templates variable names to be used in templates, as this
> scenario makes strong use of templates and may need to reference
> additional information. The first that comes into my mind (as per the
> example in my previous email) is the local username, that could be
> identified as {uri.userpart}, {username} or anything else. Maybe other
> could also make sense.

I really think it's a bad idea for us to introduce more template variables.  This gets complicated.  WebFinger was designed to operate on a single URI.  Since a URI can contain any kind of information, I think that should be sufficient.

Paul