Subject: Re: [apps-discuss] open issues with acct-uri spec

From: t.petch <[email-masked]>
Date: Thu, 1 Nov 2012 15:10:13 +0000

----- Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: <[email-masked]>
Cc: "'Graham Klyne'" <[email-masked]>
Sent: Monday, October 29, 2012 2:47 PM
>
> I see two open issues with draft-ietf-appsawg-acct-uri (which I think
> we can resolve on the mailing list, thus saving precious meeting time
> for topics that require realtime discussion):
>
> 1. In version -01, I think that I was too aggressive about trying to
> simplify the ABNF, to wit:
>
>    acctURI      =  "acct" ":" userinfo "@" host
>
> The userinfo rule allows the colon character ':', but I don't think
> that's what we want here. Instead, I think we want:
>
>    acctURI      =  "acct" ":" userpart "@" host
>    userpart     =  1*( unreserved / pct-encoded / sub-delims )
>
> If you disagree with that definition, please reply to this message.

This definition bears a passing resemblance to that of an e-mail
address, which makes me wonder whether or not the syntax should be
aligned with that of e-mail with a reference thereto.  I understand the
change you have just made, but cannot see a rationale for it.  It is not
that I disagree with the definition but that I disagree with the reason
for it, not knowing what that is.

Tom Petch

> 2. I would like to verify that the updated text about dereferencing
> 'acct' URIs is sensible. That is (last paragraph of
> draft-ietf-appsawg-acct-uri-01, section 3):
>
>    Because an 'acct' URI enables identification only and not
>    interaction, it cannot be deferenced directly.  Any protocol that
>    might use the 'acct' URI scheme, such as the WebFinger protocol
>    [I-D.ietf-appsawg-webfinger] or the Simple Web Discovery protocol
>    [I-D.jones-simple-web-discovery], is responsible for specifying how
>    an 'acct' URI is dereferenced in the context of that protocol.  For
>    example, an 'acct' URI might be passed as a parameter in an HTTP
>    request and the service might retrieve the relevant information
>    associated with the account identified by that URI and then provide
>    that information to the requesting entity in an HTTP response.
>
> Thanks!
>
> Peter
>
> - --
> Peter Saint-Andre
> https://stpeter.im/
> >

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 05 Nov 2012 16:29:22 -0500

On 11/1/12 11:10 AM, t.petch wrote:
> ----- Original Message ----- From: "Peter Saint-Andre"
> <[email-masked]> To: <[email-masked]> Cc: "'Graham
> Klyne'" <[email-masked]> Sent: Monday, October 29, 2012 2:47 PM
>> 
>> I see two open issues with draft-ietf-appsawg-acct-uri (which I
>> think we can resolve on the mailing list, thus saving precious
>> meeting time for topics that require realtime discussion):
>> 
>> 1. In version -01, I think that I was too aggressive about trying
>> to simplify the ABNF, to wit:
>> 
>> The userinfo rule allows the colon character ':', but I don't
>> think that's what we want here. Instead, I think we want:
>> 
>> acctURI      =  "acct" ":" userpart "@" host userpart     =  1*(
>> unreserved / pct-encoded / sub-delims )
>> 
> aligned with that of e-mail with a reference thereto.  I understand
> the change you have just made, but cannot see a rationale for it.
> It is not that I disagree with the definition but that I disagree
> with the reason for it, not knowing what that is.

The change is intended to remove ':' from the allowable characters in
the localpart, since the point of ':' as a delimiter (as I understand
it) was to allow localparts of the "username:password".

I do think it would be helpful to show how various protocol
identifiers (for email, SIP, XMPP, etc.) can be translated to 'acct'
URIs, similar to what we did in section 4 of
draft-saintandre-sip-xmpp-core:

http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-02#section-4

I'm not sure if that belongs in the acct-uri spec, but it might be
helpful to document somewhere (e.g., on a wiki page).

Peter

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Nov 2012 23:24:16 -0500

I've never seen a colon in an email address, but for the sake of not
proscribing things needlessly, could a colon in a user part (what we in
email call the "local part") simply be escaped somehow?

I don't think this is especially critical.  Just asking.

-MSK, participatin'

On Mon, Nov 5, 2012 at 4:29 PM, Peter Saint-Andre <[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlCYL7IACgkQNL8k5A2w/vx60gCgw/jxQTIThFHRW7wqLXxfIziK
> OMUAn1XMFoRGn4eB5iT3nd31MsaU91Mx
> =5QSV
> -----END PGP SIGNATURE-----
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 06 Nov 2012 21:03:50 +0900

> email call the "local part") simply be escaped somehow?

Not just "somehow". These are URIs, so it would be %3A.

Regards,    Martin.

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 07:49:08 -0500

Is including a port number valid?

From my read it would not be.

For debugging/testing we want to be able to run the resolver on an alternate port.  

Entering acct:[email-masked]:4444

I think that was the proposal that Mike was making yesterday in the apps area meeting.

John B.

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 6 Nov 2012 13:09:34 +0000

If there's a port, you have to specify a protocol, in which case acct:
doesn't make sense to me.

-- 
Joe Hildebrand

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 08:48:49 -0500

There is a relationship between acct: and Web-Finger where it is treated by the protocol as a locator. 

Saying that you can't specify a alternate port for web-finger to use as part of the locator is fine, as long as people understand what is happening.

The Web-Finger spec will have to provide guidance on how input is normalized.
acct:[email-masked]:8888    Is invalid and rejected
[email-masked]                       Is normalized to  acct:[email-masked]  for input to the resolver
[email-masked]:8888             May be a interoperability issue as I can imagine a number of interpretations.

My concerns are that whatever the final spec it is interoperable.

I have this nagging feeling that allowing any string as input in WF may be something that is never used and complicates the spec or is never used in practice.

This is probably more a WF issue.

John B.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 06 Nov 2012 16:53:32 +0000

I've argued elsewhere that I think the normal resolution protocol for acct: 
should be WebFinger.  Then the port world make sense, IMO.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Tue, 06 Nov 2012 17:01:29 +0000

Hmmm.  This feels a bit screwy to me.  Not fatal, just with potential to surprise.

If acct: URIs are considered as locators using the WebFinger protocol - this 
does not preclude using them as identifiers in other contexts using different 
protocols - then it makes sense to allow and recognize port numbers.  Then all 
of this use of alternative ports for testing, etc., just works without any 
further dance.  (As webfinger runs over HTTP, I expect the default port is just 80.)

IMO, treating acct: URIs as much as possible like other familiar URIs reduces 
the need for additional verbal gymnastics to explain what's going on.

#g
--

On 06/11/2012 14:27, Mike Jones wrote:
> The point I was making about ports at the meeting yesterday was that it should be explicitly allowed to run WebFinger on alternate ports, provided those ports also use TLS.  This is useful for debugging configurations and potentially other situations as well.  As I said yesterday, specifying how to select the alternative port is out of scope for the WebFinger spec.
>
> For OpenID Connect identifier normalization, I would propose that we do allow port numbers on e-mail-syntax identifiers.  For instance, we should accept [email-masked]:8888 to say that discovery for the identifier [email-masked] is to be performed on the discovery server at port 8888.
>
> That's a different thing than whether acct: needs to allow port numbers.  I could discover acct:[email-masked] at the port 8888 discovery server based upon the user input [email-masked]:8888 without incurring any interoperability issues.
>
> Make sense to everyone?
>
> 				-- Mike
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
> Sent: Tuesday, November 06, 2012 5:49 AM
> To: Joe Hildebrand (jhildebr)
> Cc: 'Graham Klyne'; [email-masked]
> Subject: Re: [apps-discuss] open issues with acct-uri spec
>
>>>> The change is intended to remove ':' from the allowable characters
>>>> in the localpart, since the point of ':' as a delimiter (as I
>>>> understand

---

From: Evan Prodromou <[email-masked]>
Date: Tue, 06 Nov 2012 14:29:48 -0500

-1

If you don't have control over port 80, you don't have control of the 
domain and you shouldn't be implementing Webfinger.

There are many ways to test Webfinger implementations without using 
alternate ports.

 1. Use the ".test" TLD reserved for this very use by RFC 2606.
    "[email-masked]".
 2. Use a sub-domain, "[email-masked]"

-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: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Nov 2012 15:53:43 -0500

On 11/6/12 11:53 AM, Graham Klyne wrote:
> I've argued elsewhere that I think the normal resolution protocol for
> acct: should be WebFinger.

Graham, in the latest version of draft-ietf-appsawg-acct-uri I have:

As far as I understand the discussion so far, other resolution protocols
are allowed, which is why I wrote the text as it is right now. Feedback
is welcome.

Peter

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

---

From: Graham Klyne <[email-masked]>
Date: Tue, 06 Nov 2012 22:40:16 +0000

Peter,

I saw your revised text, but it doesn't reflect my take.  At the time, it didn't 
seem worth dragging out the discussion.

You comment "other resolution protocols are allowed".  Maybe there's something 
I'm misunderstanding here, but my perception is that this applies no more to 
acct: URIs than it does to any other URI scheme.  That is, there's nothing to 
stop one using *any* URI in some resolution protocol (e.g. a database lookup, 
DDDS, a hash table, etc.) and there are specific situations in which this may be 
the right thing for an application to do.  This is the light in which I see 
acct: URIs being used with other protocols.  But stripped of context, all you're 
left with the the "native" dereferencing mechanism for the URI scheme, if there 
is one.

For schemes like http:, ftp:, etc., it is generally pretty clear what is the the 
standard mechanism for dereferencing.

For other schemes like, say, mailto: one may have to squint a little to see the 
standard operation (like firing uo an email client) as dereferencing, but

And for schemes like urn: and info:, there is, by design, no common 
dereferencing mechanism.

Against this background, my perception has been that acct: is not *only* about 
identification.  It has a specific association with WebFinger, even if it is 
also expected to be used with other protocols.  I'm not seeing that is any 
different from sending an HTML document containing a mailto: URI via HTTP, there 
the mailto: URI is ultimately used to identify a person, not send a mail 
message.  So I expect the acct: scheme to be associated with WebFinger in the 
same way that http: scheme is associated with HTTP protocol.  When I reviewed 
acct:, I expected that part of the reason for having it as a separate URI scheme 
was that it could be used free of protocol context (e.g. in a web page) and 
still be dereferencable by some common mechanism.

If I'm missing something, or if other people see this differently then that's 
fine.  I don't want to harp on about this.  But the recent discussion about 
acct: URIs and port numbers was, for me, a nice example of how associating acct: 
specifically and concretely with WebFinger and making it behave like other 
commonly used URIs can simplify life for some people without, as far as I can 
tell, taking away any of the uses that others may have in mind.

#g
--

---

From: John Bradley <[email-masked]>
Date: Tue, 6 Nov 2012 18:54:16 -0500

This is essentially how I see the relationship.

John B.
On 2012-11-06, at 5:40 PM, Graham Klyne <[email-masked]> wrote:

> Peter,
> 
> I saw your revised text, but it doesn't reflect my take.  At the time, it didn't seem worth dragging out the discussion.
> 
> You comment "other resolution protocols are allowed".  Maybe there's something I'm misunderstanding here, but my perception is that this applies no more to acct: URIs than it does to any other URI scheme.  That is, there's nothing to stop one using *any* URI in some resolution protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there are specific situations in which this may be the right thing for an application to do.  This is the light in which I see acct: URIs being used with other protocols.  But stripped of context, all you're left with the the "native" dereferencing mechanism for the URI scheme, if there is one.
> 
> For schemes like http:, ftp:, etc., it is generally pretty clear what is the the standard mechanism for dereferencing.
> 
> For other schemes like, say, mailto: one may have to squint a little to see the standard operation (like firing uo an email client) as dereferencing, but
> 
> And for schemes like urn: and info:, there is, by design, no common dereferencing mechanism.
> 
> Against this background, my perception has been that acct: is not *only* about identification.  It has a specific association with WebFinger, even if it is also expected to be used with other protocols.  I'm not seeing that is any different from sending an HTML document containing a mailto: URI via HTTP, there the mailto: URI is ultimately used to identify a person, not send a mail message.  So I expect the acct: scheme to be associated with WebFinger in the same way that http: scheme is associated with HTTP protocol.  When I reviewed acct:, I expected that part of the reason for having it as a separate URI scheme was that it could be used free of protocol context (e.g. in a web page) and still be dereferencable by some common mechanism.
> 
> If I'm missing something, or if other people see this differently then that's fine.  I don't want to harp on about this.  But the recent discussion about acct: URIs and port numbers was, for me, a nice example of how associating acct: specifically and concretely with WebFinger and making it behave like other commonly used URIs can simplify life for some people without, as far as I can tell, taking away any of the uses that others may have in mind.
> 
> #g
> --
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Nov 2012 00:28:21 -0500

Graham, thanks for taking the time to explain your thinking at greater
length. I now see your perspective and will ponder it a bit before
replying further.

Peter

On 11/6/12 5:40 PM, Graham Klyne wrote:
> Peter,
> 
> I saw your revised text, but it doesn't reflect my take.  At the time,
> it didn't seem worth dragging out the discussion.
> 
> You comment "other resolution protocols are allowed".  Maybe there's
> something I'm misunderstanding here, but my perception is that this
> applies no more to acct: URIs than it does to any other URI scheme. 
> That is, there's nothing to stop one using *any* URI in some resolution
> protocol (e.g. a database lookup, DDDS, a hash table, etc.) and there
> are specific situations in which this may be the right thing for an
> application to do.  This is the light in which I see acct: URIs being
> used with other protocols.  But stripped of context, all you're left
> with the the "native" dereferencing mechanism for the URI scheme, if
> there is one.
> 
> For schemes like http:, ftp:, etc., it is generally pretty clear what is
> the the standard mechanism for dereferencing.
> 
> For other schemes like, say, mailto: one may have to squint a little to
> see the standard operation (like firing uo an email client) as
> dereferencing, but
> 
> Against this background, my perception has been that acct: is not *only*
> about identification.  It has a specific association with WebFinger,
> even if it is also expected to be used with other protocols.  I'm not
> seeing that is any different from sending an HTML document containing a
> mailto: URI via HTTP, there the mailto: URI is ultimately used to
> identify a person, not send a mail message.  So I expect the acct:
> scheme to be associated with WebFinger in the same way that http: scheme
> is associated with HTTP protocol.  When I reviewed acct:, I expected
> that part of the reason for having it as a separate URI scheme was that
> it could be used free of protocol context (e.g. in a web page) and still
> be dereferencable by some common mechanism.
> 
> If I'm missing something, or if other people see this differently then
> that's fine.  I don't want to harp on about this.  But the recent
> discussion about acct: URIs and port numbers was, for me, a nice example
> of how associating acct: specifically and concretely with WebFinger and
> making it behave like other commonly used URIs can simplify life for
> some people without, as far as I can tell, taking away any of the uses
> that others may have in mind.
> 
> #g
> -- 
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 07 Nov 2012 15:30:30 +0900

> doesn't make sense to me.

Yes indeed. It would be the first time I'd heard of an account with a 
port. Just in case it matters, mailto: also doesn't have ports, because 
mail addresses don't have ports.

Regards,   Martin.

> On 11/6/12 7:49 AM, "John Bradley"<[email-masked]>  wrote:
>
>> On 2012-11-05, at 4:29 PM, Peter Saint-Andre<[email-masked]>  wrote:
>>
>>>> <[email-masked]>  To:<[email-masked]>  Cc: "'Graham
>>>> Klyne'"<[email-masked]>  Sent: Monday, October 29, 2012 2:47 PM
>>>>>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 07 Nov 2012 19:22:15 +0900

Hello Graham,

On 2012/11/07 7:40, Graham Klyne wrote:
> Peter,
>
> I saw your revised text, but it doesn't reflect my take. At the time, it
> didn't seem worth dragging out the discussion.

It would be good to know if you are making these comments as the 
reviewer, or just individually (or both, or whatever).

> applies no more to acct: URIs than it does to any other URI scheme.

In theory, yes. In practical terms, it applies quite a bit more to the 
acct: protocol than to something like http: or ftp:.

> That
> is, there's nothing to stop one using *any* URI in some resolution
> application to do.

There's also the case where you can proxy most protocols over http.

> This is the light in which I see acct: URIs being
> used with other protocols. But stripped of context, all you're left with
> the the "native" dereferencing mechanism for the URI scheme, if there is
> one.
>
> about identification. It has a specific association with WebFinger, even
> if it is also expected to be used with other protocols. I'm not seeing
> that is any different from sending an HTML document containing a mailto:
> URI via HTTP, there the mailto: URI is ultimately used to identify a
> person, not send a mail message.

You mean because that's because the message ultimately reaches that 
person (assuming it gets sent) or in some other way?

> So I expect the acct: scheme to be
> associated with WebFinger in the same way that http: scheme is
> associated with HTTP protocol. When I reviewed acct:, I expected that
> part of the reason for having it as a separate URI scheme was that it
> could be used free of protocol context (e.g. in a web page) and still be
> dereferencable by some common mechanism.

Yes. But it looks like currently, that common mechanism is "WebFinger or 
SimpleWebDiscovery". Sooner or later, there may be only one.

> that others may have in mind.

As I said in a separate mail, mailto: never had a port. Syntax-wise, a 
port on a non-hierarchical scheme (i.e. not starting with //) is of 
curse not impossible, but I think it would be difficult to come up with 
an example scheme that did. Also, in terms of concept (acct: stands for 
account), it's difficult to conceptually associate accounts with ports.

I think that using common syntax and thinking in common usage patterns 
(resource retrieval over a single preferred protocol) is very helpful as 
a framework, but the great advantage of URIs is that they aren't limited 
to to fixed usage patterns.

Regards,   Martin.

---

From: Blaine Cook <[email-masked]>
Date: Wed, 7 Nov 2012 15:27:55 +0000

-1000 to the idea of putting ports on acct "URIs". I'm biased, because I
think the acct scheme / conceiving of these things as URIs is problematic
in the first place.

Beyond the mailto: counter-example I'll again raise DNS as an example where
you can't specify, e.g., "example.com:5353" to have the DNS lookup happen
on a different port than the default 53. The default is the only option.

What would that look like in practice, were it possible?
http://example.com:5353:8080/ ???

Please, can we agree that this should be as simple as possible if it's
going to exist at all? What are the *problems* we're trying to solve? This
feels like answering "how can we apply URI semantics to email addresses",
which is not a good goal in and of itself.

b.

On 7 November 2012 10:22, "Martin J. Dürst" <[email-masked]> wrote:

> It would be good to know if you are making these comments as the reviewer,
> or just individually (or both, or whatever).
>
>
> You mean because that's because the message ultimately reaches that person
> (assuming it gets sent) or in some other way?
>
>
>
> port on a non-hierarchical scheme (i.e. not starting with //) is of curse
> not impossible, but I think it would be difficult to come up with an
> example scheme that did. Also, in terms of concept (acct: stands for
> (resource retrieval over a single preferred protocol) is very helpful as a
> framework, but the great advantage of URIs is that they aren't limited to
> to fixed usage patterns.
>
> Regards,   Martin.
>
>
>  #g
>> --
>>
>>> [I-D.jones-simple-web-**discovery], is responsible for specifying how
>>>  ______________________________**_________________
>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>>  ______________________________**_________________
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

---

From: Melvin Carvalho <[email-masked]>
Date: Wed, 7 Nov 2012 16:52:21 +0100

On 7 November 2012 16:27, Blaine Cook <[email-masked]> wrote:

> Beyond the mailto: counter-example I'll again raise DNS as an example
> where you can't specify, e.g., "example.com:5353" to have the DNS lookup
> happen on a different port than the default 53. The default is the only
> option.
>

I totally agree with you about keeping things simple.

The advantage of using a URI is to have a global permanent identifier in a
permanent way.

You are absolutely right that www.example.com, "to all intents and
purposes", might as well be the same as the http://.  Similarly
user@hostwe can reasonably assume is the mailto:version.

But consider many years from now we may have http2 or spdy or any number of
protocols that use domain names.  Now our choices are less clear.

Similarly *if* acct: gains widespread adoption, we've conflated what was a
relatively simple choice ie is uesr@host a mailto: or an acct: ?

So the reason to use a URI is for unambiguity and longevity ... ie a
permanent global variable.  But as of today, we can use some very valuable
heuristics, as you suggest, to simplify things.  But in future those
heuristics may become less valid, especially if, in that future, we need to
choose between acct: and mailto:

Personally I'm not wild about acct: at all, but I can live with it.

>
> b.
>
>
> On 7 November 2012 10:22, "Martin J. Dürst" <[email-masked]>wrote:
>
>> Hello Graham,
>>
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Nov 2012 10:55:43 -0500

On 11/7/12 10:52 AM, Melvin Carvalho wrote:

> Similarly *if* acct: gains widespread adoption, we've conflated
> what was a relatively simple choice ie is uesr@host a mailto: or an
> acct: ?

No. The user just types "user@host" or even (depending on the UI)
"user". The user agent converts that to acct:user@host and all is good.

Peter

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

---

From: Graham Klyne <[email-masked]>
Date: Wed, 07 Nov 2012 14:09:44 +0000

On 07/11/2012 10:22, "Martin J. Dürst" wrote:
> It would be good to know if you are making these comments as the reviewer, or
> just individually (or both, or whatever).

OK.

For the avoidance of doubt, all my recent comments here about the acct: URI 
scheme are in a purely personal capacity.

#g

---

From: Graham Klyne <[email-masked]>
Date: Wed, 07 Nov 2012 14:56:25 +0000

Hi Martin,

Continuing to respond in a personal capacity...

On 07/11/2012 10:22, "Martin J. Dürst" wrote:
> In theory, yes. In practical terms, it applies quite a bit more to the acct:
> protocol than to something like http: or ftp:.

Maybe, but I'm not sure it's to an extent that makes a qualitative difference. YMMV.

> There's also the case where you can proxy most protocols over http.

Yes, that too.  (But I think the HTTP proxy is somewhat bound to break out to 
the implicit scheme semantics at some point.  This raises a question: what 
should an HTTP proxy do when it receives a request for an acct: URI?)

> (assuming it gets sent) or in some other way?

I'm not sure I understand the question here.  I'm talking about a URI being used 
in a way that is independent of the protocol with which it's associated.  Like 
http://... XML namespace URIs being used independently of HTTP protocol 
interactions.

> SimpleWebDiscovery". Sooner or later, there may be only one.

That's a point I hadn't previously realized, which does somewhat erode my 
position.

I think it would be unfortunate, but not necessarily fatal, if there isn't a 
single dereferencing mechanism that can be arrived at by a "follow your nose" 
process from the URI scheme registration.

> As I said in a separate mail, mailto: never had a port. Syntax-wise, a port on a
> non-hierarchical scheme (i.e. not starting with //) is of curse not impossible,
> but I think it would be difficult to come up with an example scheme that did.
> Also, in terms of concept (acct: stands for account), it's difficult to
> conceptually associate accounts with ports.

Fair point.  I concede it's less compelling to use ports with a non-hierarchical 
(i.e. non-authority-based) scheme.

(In this case, a port wouldn't be associating the *account* with a port, but the 
account information discovery mechanism.  I suppose a germane question here is 
if "acct:[email-masked]" and "acct:[email-masked]:8888" should be expected to 
refer to the same account.  Hence dereference to information about the same 
account - but not necessarily the same information.  As URIs, they're clearly 
different.)

What all this says to me is that my using the port number issue as an excuse to 
re-raise this point was misguided.  So I guess my other comments should be 
considered independently of the port number debate.

> I think that using common syntax and thinking in common usage patterns (resource
> retrieval over a single preferred protocol) is very helpful as a framework, but
> the great advantage of URIs is that they aren't limited to to fixed usage patterns.

"Yes, but..." is what I want to say.  Hmmm, "but" what?  I think one thing that 
all URIs should share is that there's an association between the URI and some 
"resource" (qua RFC3986) - the URI identifies a resource.  When there is a 
mechanical way of getting from the URI to the resource (or a representation 
thereof), it's preferable that the URI can provide an indication of what that 
mechanism is - I think this is what allows the principle of URI opacity in web 
applications.

Maybe this doesn't amount to a "fixed usage pattern", but I think it's a common 
benefit of using URIs.  And it doesn't preclude other usage patterns, but those 
other patterns are possible only with additional context information which means 
that a given URI can be interpreted differently, possibly contradictory, fashion 
in different [protocol] environments.  That's not necessarily a problem in 
itself, but who's to say which is right in a broader web context?

#g
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Nov 2012 07:17:54 -0500

Hi Graham,

Thanks again for sharing your thoughts on the matter. I happened to chat
about this with a few folks here at the IETF meeting in Atlanta, and
here is how I see it...

We have this protocol called WebFinger: in order to retrieve pointers to
further information about a person associated with a domain, a client
sends a special HTTP request to a server at that domain and passes as a
parameter in that request a URI that identifies the person. That URI
could be a 'mailto:', 'sip:', 'xmpp:', 'callto:' (?), or other URI that
includes an identifier for the person (i.e., for an account controlled
by the person).

When the client completes that operation, is it dereferencing the
'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a parameter? Or
it dereferencing the HTTP URL to which it sends the request? Example:

http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com

This might only indicate my ignorance of URIs, but that example doesn't
feel to me like a dereferencing of an 'xmpp:' URI, which I would expect
to be something like this (see XEP-0054 at xmpp.org):

xmpp:[email-masked]?vcard

Instead, the URI that is passed as a parameter in the WebFinger
operation feels to me like something that is used purely for
identification, not interaction (dereferencing).

If that line of reasoning is just wrong, please do let me know. :-)

The WebFinger community, through much conversation over the years,
decided that it was potentially confusing to use 'mailto:' URIs when
passing a parameter in the WebFinger operation, primarily because there
might not be an email service running at the domain or associated with
that person, and perhaps secondarily because they didn't want to set up
the expectation that the requesting entity was initiating any kind of
email-based interaction. Therefore, they decided to define a neutral URI
scheme that would be used purely for identification.

As I understand it, there is no expection that an HTML href attribute
containing an 'acct:' URI would trigger a WebFinger interaction:

<a href='acct:bob@example'>info</a>

Instead, the client would need to include the correct HTTP URL:

<a
href='http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com'>info</a>

Therefore, I continue to think that 'acct:' URIs are used purely for
identification and not at all for interaction. It's just a parameter
that you pass in the query part of an HTTP URL, not a URI that you
dereference directly.

If those who know more about URIs or WebFinger than I do disagree with
the foregoing characterization, I'd love to hear it.

Thanks for listening.

Peter

---

From: Melvin Carvalho <[email-masked]>
Date: Thu, 8 Nov 2012 13:42:15 +0100

> http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com

Here you are dereferencing the HTTP URL via the HTTP protocol, specifically
GET.  The xmpp URI would be a parameter.

> identification, not interaction (dereferencing).

URIs are Identifiers aka names aka references

Not all URIs can be dereferenced, in particular, URNs are just names
without the dereferencing part.

By implication http URIs can be dereferenced via http

> scheme that would be used purely for identification.

I have a slightly different take on this, and that is one of the
motivations for acct: was that it was considered better practice to use a
direct identifier, rather than, an indirect identifier.  Webfinger seems to
be a specific query where the input identifier should be the subject of the
data returned.

Indirect identifiers are explained in : "Architecture of the World Wide
Web, Volume One"

http://www.w3.org/TR/webarch/#indirect-identification

"Suppose that [email-masked] is Nadia's email address. The organizers of
a conference Nadia attends might use "mailto:[email-masked]" to refer
indirectly to her (e.g., by using the URI as a database key in their
database of conference participants). This does not introduce a URI
collision."

> that you pass in the query part of an HTTP URL, not a URI that you

As a slight aside, we had a really interested session with Tim Berners-Lee
last week at TPAC on identity and auth on the web.  The topic of webfinger
came up in passing, where he made an interesting comment.

He said that if you want to get an HTTP URI from an email address, the most
logical place to do so is via the SMTP protocol (something I had never
considered before!).  He also seemed to suggest that there was already a
specification for this, but people decided to turn it off, for security
reasons.

> the foregoing characterization, I'd love to hear it.

Above is based on my (limited) understanding of awww, corrections welcome :)

---

From: Graham Klyne <[email-masked]>
Date: Fri, 09 Nov 2012 11:35:39 +0000

> xmpp:[email-masked]?vcard

You're right.  It's dereferencing an HTTP URI which happens to contain an 
encoded xmpp URI (but HTTP protocol doesn't know about that).

> If that line of reasoning is just wrong, please do let me know. :-)

I don't disagree with anything you've said here.

But it doesn't say anything about what you do when starting with an acct: URI 
and want to find out more.

Let me posit for the purpose of debate that dereferencing an acct: URI is done 
using WebFinger.  It happens that execution of the WebFinger protocol involves 
dereferencing HTTP URIs, and those HTTP URIs may contain references to (parts 
of) the acct: URIs, or any other ind of URI.  So dereferencing an acct: URI 
involves constructing an http: URI and then dereferencing that.  I see no 
conflict here.

> scheme that would be used purely for identification.

Sure, no argument here from me.

> <a href='acct:bob@example'>info</a>

Maybe that's where our positions differ.  I think it's quite reasonable that an 
acct: URI could in principle, be used in this way (i.e. as an arbitrary link in 
a document.  Modulo implementation support, of course).

And that kind of dereferencing may not be what the WebFinger designers had in 
mind, but they have chosen to adopt an artifact (URI) from another framework 
(the Web), so there are expectations that might be associated with that 
artifact.  Web architecture tries to maintain a separation of purpose between 
URIs and protocols: in principle (though not always in practice) an application 
that uses a URI in a generic way (such as in HTML @href values) should strive be 
"colour blind" with respect to the URI provided (cf. "URI Opacity" - 
http://www.w3.org/TR/webarch/#uri-opacity) ...

 > href='http://example.com/lrdd/?f=json&uri=xmpp%3Abob%40example.com'>info</a>

... In  this case, I'd say the application that is generating a web page with a 
link in it should ideally not have to treat the acct: scheme differently (i.e. 
not need know that it has to generate the corresponding WebFinger http: URI) - 
that level of treatment is, IMO, best taken as part of the dereferencing 
semantics of the URI scheme itself, not the application that uses it.

> the foregoing characterization, I'd love to hear it.

I don't think there's a definitive right-or-wrong position here.  I just feel 
that, to the extent that acct: *is* associated with a specific protocol, that 
the dereferencing mechanism should be part of the URI specification.

You appear see acct: as a kind of URN (in the broad sense of URN), I prefer to 
see it as a kind of URL.  Either is technically acceptable, but I feel the URL 
view is potentially more useful as, among other things, it enables (automatable) 
follow-your-nose discovery to be associated with acct: URIs.

> Thanks for listening.

Thank you for listening :)

#g
--

---

From: t.petch <[email-masked]>
Date: Fri, 9 Nov 2012 16:45:12 +0000

--Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "'Graham Klyne'" <[email-masked]>
Sent: Monday, November 05, 2012 9:29 PM
> helpful to document somewhere (e.g., on a wiki page).

Just to make it easy to see, the table is

   Table 1: Allowed and disallowed characters

   +---+----------------------------------+
   | SIP/SIPS CHARACTERS                  |
   +---+----------------------------------+
   | A | !  $ &'()*+,-./ ; = ?     _    ~ |
   | D |  "# %          : < > @[\]^ `{|}  |
   +---+----------------------------------+
   | IM/PRES CHARACTERS                   |
   +---+----------------------------------+
   | A | ! #$%&'  *+ - /   = ?    ^_`{|}~ |
   | D |  "     ()  , . :;< > @[\]        |
   +---+----------------------------------+
   | XMPP CHARACTERS                      |
   +---+----------------------------------+
   | A | ! #$%  ()*+,-.  ; = ? [\]^_`{|}~ |
   | D |  "   &'       /: < > @           |
   +---+----------------------------------+

which may be helpful, but only because what has gone before is so
amazingly unhelpful - standards making should result in a standard, not
four different ways of saying the same thing:-(

We have an excellent specification in RFC5321 which the author of
RFC6068 had the wisdom not to try and improve on. The point I was
originally making, a bit coyly, was we need a very good reason to come
up with something different from those two, those being the most widely
visible.  Or else fall back on RFC3986 (and yes, I have seen colons used
with passwords and yes, it is an abysmal idea).

Tom Petch

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Nov 2012 11:17:40 -0700

On 11/9/12 4:35 AM, Graham Klyne wrote:
>> Thanks again for sharing your thoughts on the matter. I happened
>> to chat about this with a few folks here at the IETF meeting in
>> Atlanta, and here is how I see it...
>> 
>> We have this protocol called WebFinger: in order to retrieve
>> pointers to further information about a person associated with a
>> domain, a client sends a special HTTP request to a server at that
>> domain and passes as a parameter in that request a URI that
>> identifies the person. That URI could be a 'mailto:', 'sip:',
>> 'xmpp:', 'callto:' (?), or other URI that includes an identifier
>> for the person (i.e., for an account controlled by the person).
>> 
>> When the client completes that operation, is it dereferencing
>> the 'mailto:', 'sip:', 'xmpp:' (etc.) URI that is passed as a
>> parameter? Or it dereferencing the HTTP URL to which it sends the
>> request? Example:
>> 
>> This might only indicate my ignorance of URIs, but that example
>> doesn't feel to me like a dereferencing of an 'xmpp:' URI, which
>> I would expect to be something like this (see XEP-0054 at
>> xmpp.org):
>> 
> You're right.  It's dereferencing an HTTP URI which happens to
> contain an encoded xmpp URI (but HTTP protocol doesn't know about
> that).
> 
> But it doesn't say anything about what you do when starting with
> an acct: URI and want to find out more.

I think the short answer is: Don't do that. :)

As I understand it, an acct: URI is not intended to be used directly
as a way to "find out more". It's something that is passed around in
the background, not exposed to humans. It's a kind of abstract
identifier, if you will.

> Let me posit for the purpose of debate that dereferencing an acct:
> URI is done using WebFinger.

If that's what folks wanted all long, I wish they'd called it
webfinger: or wf:, not acct:...

> It happens that execution of the WebFinger protocol involves
> dereferencing HTTP URIs, and those HTTP URIs may contain references
> to (parts of) the acct: URIs, or any other ind of URI.  So
> dereferencing an acct: URI involves constructing an http: URI and
> then dereferencing that.  I see no conflict here.

Yes, that makes sense if we're talking about something that is
specific to the WebFinger protocol. If, say, the Simple Web Discovery
protocol or some other protocol decides to use acct: URIs then saying
that a bare acct: URI is dereferenced by performing a WebFinger
operation seems wrong to me.

>> The WebFinger community, through much conversation over the
>> years, decided that it was potentially confusing to use 'mailto:'
>> URIs when passing a parameter in the WebFinger operation,
>> primarily because there might not be an email service running at
>> the domain or associated with that person, and perhaps
>> secondarily because they didn't want to set up the expectation
>> that the requesting entity was initiating any kind of email-based
>> interaction. Therefore, they decided to define a neutral URI 
>> As I understand it, there is no expection that an HTML href
>> attribute containing an 'acct:' URI would trigger a WebFinger
>> interaction:
>> 
> Maybe that's where our positions differ.  I think it's quite
> reasonable that an acct: URI could in principle, be used in this
> way (i.e. as an arbitrary link in a document.  Modulo
> implementation support, of course).
> 
> And that kind of dereferencing may not be what the WebFinger
> designers had in mind, but they have chosen to adopt an artifact
> (URI) from another framework (the Web), so there are expectations
> that might be associated with that artifact.  Web architecture
> tries to maintain a separation of purpose between URIs and
> protocols: in principle (though not always in practice) an
> application that uses a URI in a generic way (such as in HTML @href
> values) should strive be "colour blind" with respect to the URI
> provided (cf. "URI Opacity" - 

What are the practical implications of URI opacity in this context?

> ... In  this case, I'd say the application that is generating a web
> page with a link in it should ideally not have to treat the acct:
> scheme differently (i.e. not need know that it has to generate the 
> corresponding WebFinger http: URI) - that level of treatment is,
> IMO, best taken as part of the dereferencing semantics of the URI
> scheme itself, not the application that uses it.
> 
>> Therefore, I continue to think that 'acct:' URIs are used purely
>> for identification and not at all for interaction. It's just a
>> parameter that you pass in the query part of an HTTP URL, not a
>> URI that you dereference directly.
>> 
>> If those who know more about URIs or WebFinger than I do disagree
>> with the foregoing characterization, I'd love to hear it.
> 
> I don't think there's a definitive right-or-wrong position here.  I
> just feel that, to the extent that acct: *is* associated with a
> specific protocol, that the dereferencing mechanism should be part
> of the URI specification.

I think we all agree on that. The question is whether acct: is indeed
strongly associated with the WebFinger protocol. That doesn't feel
right to me, but if that's what we decide in the working group here
then I'm happy to update the spec accordingly.

> You appear see acct: as a kind of URN (in the broad sense of URN),
> I prefer to see it as a kind of URL.

In the terms of RFC 3986 (Section 1.2.2), I see acct: as a URI that
provides identification, whereas you see acct: as a URI that enables
interaction (i.e., access to a resource in the form of a JSON Resource
Decriptor via the WebFinger protocol). Are identification-only URIs
limited to URNs ("in the broad sense")?

> Either is technically acceptable, but I feel the URL view is
> potentially more useful as, among other things, it enables
> (automatable) follow-your-nose discovery to be associated with
> acct: URIs.

Usefulness might be in the eye of the beholder or depend on the
application one has in mind. Designers of protocols other than
WebFinger might find it useful to have a URI scheme that provides pure
identification of an account at a service, which is how I've always
understood the acct: URI scheme.

Clearly, the two of us see things in different ways. IMHO we might
need the APPSAWG chairs to issue a call for consensus so that we can
get unstuck here...

Peter

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

---

From: John Bradley <[email-masked]>
Date: Wed, 14 Nov 2012 17:22:26 -0300

The two ways of looking at it are the problem I have had for some time with the acct: uri .

If acct:  is purely an identifier that is passed as a parameter then I think the argument for having it's own scheme rather than a URN namespace turns on how to encode a @.
There are other ways to pass identifiers  (Handle etc) that have yet to require dedicated schemes.

The value of a scheme comes from the ability to use follow your nose.  

Without tying acct: to a resolution protocol you have ambiguity , acct:[email-masked] may be interpreted as different accounts by different protocols.

If we want to tie WF resolution to acct: we should just say so.   It was part of the WF spec so it shouldn't be a surprise.

I think the argument for registering a scheme is weak without it.

John B.

On 2012-11-14, at 3:17 PM, Peter Saint-Andre <[email-masked]> wrote:

> iEYEARECAAYFAlCj4EQACgkQNL8k5A2w/vwSggCcDIIHvucqEps47SpAPEYD0asx
> CEYAnRInk9UTnZLTXAhwRjUharbJ3n9/
> =xuTL

---

From: t.petch <[email-masked]>
Date: Fri, 16 Nov 2012 12:36:40 +0000

---- Original Message -----
From: "Peter Saint-Andre" <[email-masked]>
To: "Graham Klyne" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 14, 2012 6:17 PM
> > On 08/11/2012 12:17, Peter Saint-Andre wrote:
<snip>
> the background, not exposed to humans. It's a kind of abstract

Not sure about the abstract but identifier yes, and I think that there
may be other quite different uses for it.  Twice, with other, Operations
protocols, I have found
localpart@domain
used to identify, well, an account, a person or persons accessing or
using a system, sometimes with a need to know more about them, such as
rights or security credentials, so a scheme with a nailed-down syntax
would have been useful, as opposed to reinventing the wheel.  mailto:
might do but is rather 'e-mailly', as one would expect!

Whether or not Webfinger would be suitable for dereferencing I do not
know enough about Webfinger to say; most of the discussion here seems to
be about 'Webby' type uses which might be too limiting; but even so,
having a usable syntax would be a step forward.

Tom Petch

> <snip>

---

From: Larry Masinter <[email-masked]>
Date: Mon, 19 Nov 2012 00:53:25 -0800

Joe Hildebrand (jhildebr) wrote Tuesday, November 06, 2012 5:10 AM
> doesn't make sense to me.

I see quite a bit of discussion about URI scheme guidelines.

RFC 4395 really needs updating. This kind of advice SHOULD be in the BCP for guidelines for new URI schemes: 

You have to decide whether the scheme is protocol based (in which it really is tied to the protocol whether http, ftp, imap .. and has port and can have an IPv6 or IPv4 address)
Or it is *Not* protocol based and no port is needed, like mailto (with a host name but no port and no raw addresses) or tel:,mid:, cid:  with no host name at all.

However, I think the update of RFC 4395 was taken up by the IRI working group which had little attention on it. 

http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 expired.  Actually, quite a bit got re-written, but I don't remember any review comments.
http://tools.ietf.org/rfcdiff?url1=rfc4395&url2=draft-ietf-iri-4395bis-irireg-04.txt

Now, if apps-discuss is willing to put so much energy into a single URI scheme definition, perhaps some energy could be put into updating the guidelines.

Maybe someone who hasn't been working on this topic for 20 years could find more energy to work on an update?

Larry

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 19 Nov 2012 18:00:51 +0900

Hello Larry,

> Maybe someone who hasn't been working on this topic for 20 years could find more energy to work on an update?

Is the XML at
http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.xml
up to date, or is there a more up-to-date internal version?
If not, can one of the authors who is in possession of the newest 
version commit it to the IRI WG svg repo or some other suitable location 
and announce where it's avaliable?

I have added a new issues for this in the IRI WG tracker.

Regards,    Martin.

P.S.: All this just to make sure things don't get dropped.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 19 Nov 2012 18:34:51 +0900

>> Now, if apps-discuss is willing to put so much energy into a single
>> URI scheme definition, perhaps some energy could be put into updating
>> the guidelines.
>>

I had to wait for Larry's mail to show up in the archives to create the 
issue. It's now at http://trac.tools.ietf.org/wg/iri/trac/ticket/137.

Regards,   Martin.