Subject: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?

From: Daniel Pocock <[email-masked]>
Date: Mon, 28 Jan 2013 23:01:17 +0100

Just forwarding my feedback on draft-ietf-appsawg-acct-uri - see
comments further below

The prefix `acct:' may not be the right solution for what was intended
in my original query on xmpp-operators, but if it is not suitable, then
that may imply that some other prefix is also needed in addition to acct:

For example, rtc:[email-masked] could be defined in another draft
to imply any type of real-time communication (im, sip or xmpp) perhaps?

-------- Original Message --------
Subject: Re: [Operators] Protocol agnostic URI for voice or video call?
Date: Sun, 27 Jan 2013 00:30:16 +0100
From: Daniel Pocock <[email-masked]>
To: Mikko Lehto <[email-masked]>
CC: XMPP Operators Group <[email-masked]>, [email-masked]

On 26/01/13 22:03, Mikko Lehto wrote:
> 2013-01-07 (Mon) 15:16 UTC +0100  Daniel Pocock <[email-masked]>:
> 
>> However, im: implies text chat only.  Are there equivalent prefixes to suggest voice and/or video sessions, and is there any generic prefix to suggest any arbitrary possibility (including smtp) at the caller's discretion?
> 
> Hi Daniel
> 
> Are you aware of acct: URI scheme¹ ?
> Maybe that can be utilized.
> 
> [1] draft-ietf-appsawg-acct-uri

Thanks for bringing that to my attention, I think it almost addresses
what I had in mind

s4.7 interoperability doesn't mention the fact that xmpp: and sip: have
slightly different sets of permitted characters for the user@ portion of
a URI.  s4.3 could probably be extended to define a subset that is
compatible with mailto:, xmpp: and sip: all at once

---

From: Bill Mills <[email-masked]>
Date: Mon, 28 Jan 2013 14:34:54 -0800

I think you'd need to have rtc:xmpp:[email-masked], or were you thinking that there would be a user specific lookup to determine what RTC protocol a user advertises?

________________________________
From: Daniel Pocock <[email-masked]>
To: [email-masked] 
Sent: Monday, January 28, 2013 2:01 PM
Subject: [apps-discuss] Fwd: draft-ietf-appsawg-acct-uri-02 Re: [Operators] Protocol agnostic URI for voice or video call?

-------- Original Message --------
Subject: Re: [Operators] Protocol agnostic URI for voice or video call?
Date: Sun, 27 Jan 2013 00:30:16 +0100
From: Daniel Pocock <[email-masked]>
To: Mikko Lehto <[email-masked]>
CC: XMPP Operators Group <[email-masked]>, [email-masked]

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jan 2013 15:42:10 -0700

On 1/28/13 3:01 PM, Daniel Pocock wrote:
> The prefix `acct:' may not be the right solution for what was
> intended in my original query on xmpp-operators, but if it is not
> suitable, then that may imply that some other prefix is also needed
> in addition to acct:
> 
> For example, rtc:[email-masked] could be defined in another
> draft to imply any type of real-time communication (im, sip or
> xmpp) perhaps?

Actually, both im: and pres: are of the form you're thinking about
(they are "meta-URIs", if you will, which could trigger interaction
via some particular protocol like SIP or XMPP). However, they are
rarely used perhaps because the resolution process is somewhat complex
(see RFC 3859, RFC 3860, and RFC 3861), so I don't think they provide
a good model to follow.

Peter

> 
> 
> 
> 
> -------- Original Message -------- Subject: Re: [Operators]
> Protocol agnostic URI for voice or video call? Date: Sun, 27 Jan
> 2013 00:30:16 +0100 From: Daniel Pocock <[email-masked]> To:
> Mikko Lehto <[email-masked]> CC: XMPP Operators Group
> <[email-masked]>, [email-masked]
> 
> 
> 
>>> However, im: implies text chat only.  Are there equivalent
>>> prefixes to suggest voice and/or video sessions, and is there
>>> any generic prefix to suggest any arbitrary possibility
>>> (including smtp) at the caller's discretion?
>> 
>> Hi Daniel
>> 
>> Are you aware of acct: URI scheme¹ ? Maybe that can be utilized.
>> 
> Thanks for bringing that to my attention, I think it almost
> addresses what I had in mind
> 
> s4.7 interoperability doesn't mention the fact that xmpp: and sip:
> have slightly different sets of permitted characters for the user@
> portion of a URI.  s4.3 could probably be extended to define a
> subset that is compatible with mailto:, xmpp: and sip: all at once
> 
> 
> _______________________________________________ apps-discuss
> mailing list [email-masked]

---

From: Daniel Pocock <[email-masked]>
Date: Mon, 28 Jan 2013 23:53:42 +0100

On 28/01/13 23:42, Peter Saint-Andre wrote:
>> intended in my original query on xmpp-operators, but if it is
>> not suitable, then that may imply that some other prefix is also
>> needed in addition to acct:
> 
>> For example, rtc:[email-masked] could be defined in
>> another draft to imply any type of real-time communication (im,
>> sip or xmpp) perhaps?
> 
> (they are "meta-URIs", if you will, which could trigger
> interaction via some particular protocol like SIP or XMPP).
> However, they are rarely used perhaps because the resolution
> process is somewhat complex (see RFC 3859, RFC 3860, and RFC 3861),
> so I don't think they provide a good model to follow.
> 

I agree it is not easy, but from an end-user perspective, having a
single omni-URI (omni:[email-masked] ?) has very compelling
ease-of-use benefits.

In the wild, my Lumicall implementation hunts for mailto: addresses in
your phone and if their domains have boilerplate SRV records (e.g.
_sips._tcp.example.org), assumes the full email address
mailto:[email-masked] can be adapted to sip:[email-masked] - most
likely it will check for NAPTR records too in the near future, and
offer xmpp: with the same paradigm.

http://www.lumicall.org has a brief demo video deducing
sip:[email-masked] from the mailto: address

>> 2013 00:30:16 +0100 From: Daniel Pocock <[email-masked]>
>> To: Mikko Lehto <[email-masked]> CC: XMPP Operators Group 
>>>> prefixes to suggest voice and/or video sessions, and is
>>>> there any generic prefix to suggest any arbitrary
>>>> possibility (including smtp) at the caller's discretion?
>>> 
>>> Hi Daniel
>>> 
>> s4.7 interoperability doesn't mention the fact that xmpp: and
>> sip: have slightly different sets of permitted characters for the
>> user@ portion of a URI.  s4.3 could probably be extended to
>> define a subset that is compatible with mailto:, xmpp: and sip:
>> all at once
> 
>

---

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

On 1/28/13 3:53 PM, Daniel Pocock wrote:
>>> Just forwarding my feedback on draft-ietf-appsawg-acct-uri -
>>> see comments further below
> 
>>> not suitable, then that may imply that some other prefix is
>>> also needed in addition to acct:
> 
>>> another draft to imply any type of real-time communication
>>> (im, sip or xmpp) perhaps?
> 
>> Actually, both im: and pres: are of the form you're thinking
>> about (they are "meta-URIs", if you will, which could trigger 
>> process is somewhat complex (see RFC 3859, RFC 3860, and RFC
>> 3861), so I don't think they provide a good model to follow.
> 
> 
> 

The problem is that the one ring to bind them all can also be used for
any purpose, and thus might be void for vagueness. Telling the end
user "omni:[email-masked] enables you to interact in every possible
way with foo" doesn't seem very helpful to me.

In any case, it's not the intent of the 'acct' scheme to enable every
kind of interaction with accounts, only to provide a generic
identifier for accounts. Unfortunately, the distinction between
identification and interaction seems to be hard for folks to grasp...

Peter

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