Subject: [VCARDDAV] IMPP property and "service providers"

From: Cyrus Daboo <[email-masked]>
Date: Fri, 05 Feb 2010 17:35:44 -0800

Hi folks,
The IMPP property (as originally defined in RFC 4770 and now incorporated 
in vcardrev) is defined to use a URI value. 4770 gave some example URIs 
(sip:, xmpp:, im:, pres:) but also had examples that, as far as I can tell, 
are not valid/registered URI schemes: irc, aim, ymsgr, msn. First of all 
having non-standard URI schemes is far from ideal. If those schemes are in 
wide spread use they need to be registered.

The second problem, is that even with registered schemes, there is no 
guaranteed way to determine who the "service provider" is. e.g. 
xmpp:[email-masked] and xmpp:[email-masked] don't really 
indicate the service provider. Yet address book apps often want to 
enumerate providers in a popup for users to choose from (and to display).

What I would like to propose is that we add a new parameter to this 
property with an enumerated value, with the values being registered with 
IANA. Something called "SERVICE-PROVIDER", for example. That could be 
registered with things like:

Google Talk
Yahoo Messenger
Jabber
AIM
MSN
Twitter

etc

This would give clients an interoperable way to present IM addresses to 
users with a more familiar description, as opposed to a URI. This is 
something of a unique situation (certainly in comparison to email 
addresses) that has arisen due to the fact that there are IM systems that 
do not interoperate so users need to pick a common provider when they need 
to communicate.

Thoughts?

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Sat, 06 Feb 2010 09:44:01 +0100

Cyrus Daboo wrote:
> Hi folks,
> The IMPP property (as originally defined in RFC 4770 and now 
> incorporated in vcardrev) is defined to use a URI value. 4770 gave some 
> example URIs (sip:, xmpp:, im:, pres:) but also had examples that, as 
> far as I can tell, are not valid/registered URI schemes: irc, aim, 
> ymsgr, msn. First of all having non-standard URI schemes is far from 
> ideal. If those schemes are in wide spread use they need to be registered.
> ...

Indeed.

> ...

Wait, why is that a problem, at least for these two examples? If my 
computer knows about "xmpp", it should be able to communicate with 
those, right?

> ...

> ...

Still trying to understand; what would be the service provider entry for 
the two xmpp examples above?

> addresses) that has arisen due to the fact that there are IM systems 
> that do not interoperate so users need to pick a common provider when 
> they need to communicate.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Sat, 6 Feb 2010 09:53:25 -0500

>> indicate the service provider. Yet address book apps often want to enumerate
>> providers in a popup for users to choose from (and to display).
>
> Wait, why is that a problem, at least for these two examples? If my computer
> knows about "xmpp", it should be able to communicate with those, right?

The problem Cyrus is talking about isn't
communication/interoperability, but labelling in a UI, if I understand
him correctly.  I agree that labelling the vCard entry is a good idea,
to help the UI deal with what users expect to see.

>> registered with things like:

The problem I have with having to register these is that it takes
flexibility away, for something that's not really an interoperability
issue.  I suggest that we create an IANA registry, but say that
services MAY (or SHOULD) be registered, and that the vCard entries
SHOULD prefer appropriate registered values, but MAY use any value,
registered or not.

Barry

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 06 Feb 2010 10:55:41 -0500

> to help the UI deal with what users expect to see.

right. I understood it that way. I agree that this feature, from a user 
perspective, would be useful.

moreover, I would suggest that we might want to generalize it. In some 
ways, this says: this url is serviced by this provider. Therefore, we 
might encounter other urls that have the same property (having to point 
to a service provider).

why don't we generalize this as a new, optional, parameter for any URL 
property in the vcard?

>>> registered with things like:

instead of creating yet another registry, maybe we could think of 
reusing something that already exists.

Private Enterprise Numbers might not be good here, given that a service 
provide might have registered a PEN while the vcard client wants to 
label it.

Why not use a domainname as the service provider id? that way, it is 
unique and we don't need to register anything. The UI might want to
have a mapping between some of the known domain names (google.com) to a 
real name "Google" (even with localization if wanted) and if the mapping 
does not exists in the software, just show the domain name. That way, we 
keep the flexibility, a new comer does not have to be registered, simple 
UI to do, etc...

That way, we could have as a service provider twitter.com, facebook.com, ...

Marc.

> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 08:20:08 -0700

On 2/6/10 8:55 AM, Marc Blanchet wrote:
>>>> enumerate
>>> computer

I know that a lot of IM clients already do something like this for
setting up multiple IM accounts. For example they might have a drop-down
list of service providers, such as AIM, Facebook, Google Talk, ICQ, Live
Journal Talk, MSN, and Yahoo. The fact that several of these services
use XMPP is opaque to the user.

> might encounter other urls that have the same property (having to point

Quite possible -- that might apply to services for blogging, social
networking, and microblogging, for example.

> why don't we generalize this as a new, optional, parameter for any URL

That seems reasonable.

> reusing something that already exists.

It's not clear to me that we need anything registry-like here. Why is a
human-readable string (e.g., "Facebook" or "AIM") not sufficient?

> That way, we could have as a service provider twitter.com, facebook.com,

I'd assume that your typical provider would prefer to use the
human-friendly name for their service (e.g., "Google Talk"), not
necessarily a domain name (e.g., "google.com" or "talk.google.com" or
somesuch).

Peter

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

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 16 Feb 2010 10:30:01 -0500

> necessarily a domain name (e.g., "google.com" or "talk.google.com" or

that was my point. the service provider id would be a FQDN. With a FQDN, 
we don't need a registry. And it is up to the UI of the application to 
localize the FQDN into a human-friendy name in the whatever LOCALE the 
user has. Therefore, the UI would have a mapping between the FQDNs and 
the display names in various LOCALEs. As an exception rule, if the app 
receives a new vcard where the FQDN does not have any mapping in the 
app, then the app displays the domain name. (provides a default (to me 
acceptable) behavior). Therefore, we have uniqueness and we don't have 
to maintain a registry of service providers in all scripts...

Marc.

> 
> Peter
> 
> 
> 
> ------------------------------------------------------------------------
> 

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Feb 2010 10:50:15 -0500

On 2010-02-16 10:30, Marc Blanchet wrote:
> the service provider id would be a FQDN.

Don't we already have that?

IMPP:xmpp:[email-masked]
                           ^^^^^^^^^

I fail to see what problem we have currently that we're trying to fix.

Users have been trained to parse email addresses. They know what 
@gmail.com means. Why don't we just show the XMPP URI to them directly? 
Why do we need to translate that to "Google"? Did anyone ask for that?

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 09:10:15 -0700

On 2/16/10 8:50 AM, Simon Perreault wrote:
> Why do we need to translate that to "Google"? 

Don't assume users know that AIM is provided by aol.com. :) As the
provider of a middling XMPP service called jabber.org, I can tell you
that many users don't know much at all ("my Jabber is broken" is about
as far as they can get sometimes -- they don't even know what IM client
they use).

> Did anyone ask for that?

I'm not sure.

Absent usability studies or explicit service provider requests, I don't
necessarily see a strong reason to add this, *but* as I said existing IM
clients already support this kind of thing. However, they map the domain
name (e.g., googlemail.com) to a provider on their own.

/psa

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Feb 2010 11:23:53 -0500

On 2010-02-16 11:10, Peter Saint-Andre wrote:
> Don't assume users know that AIM is provided by aol.com.

Yes, of course, but is that a problem? They know they can stick the part 
after the @ in a browser. Or even enter it into Google, and out comes 
information.

Portraying different providers of XMPP as being different "flavours" is 
wrong. It prevents smaller providers from getting equivalent treatment. 
A particular client trying to provide a nice GUI is one thing. Putting 
that into a protocol is another.

In any case, at this point I think this is much too fluffy to be 
included in vCard base. We need to wrap this up.

Thanks,
Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 16 Feb 2010 12:08:20 -0500

Hi Simon,

> I fail to see what problem we have currently that we're trying to fix.

Outsourced domains. I mighty choose to have daboo.name outsourced to Google 
for all my services. So my xmpp address would still use daboo.name as the 
domain, bit it would be a GoogleTalk service.

> Why do we need to translate that to "Google"? Did anyone ask for that?

Email is different because users do not have to enter a scheme because 
there is only one (which is also pretty much true for http/https in a 
browser). Requiring users to enter full URIs is not appropriate given that 
most of the services provide a "user id" field which does not include the 
domain. i.e. I go sign up for GoogleTalk and I get my user id (e.g. 
'cdaboo'). How am I supposed to know to enter xmpp:[email-masked] or 
whatever. From an address book client perspective we need to keep the UI 
simple - i.e. users pick from a popup of popular services (with the option 
to manually define a custom one) and then enter just their user id. Under 
the hood the ab client can translate that into URIs for well known services.

> In any case, at this point I think this is much too fluffy to be included
> in vCard base. We need to wrap this up.

That is fair enough (yes I would like to see vCard 4.0 published as soon as 
possible). If we do not have enough consensus on this I am willingly to do 
an individual submission and work on this outside the base spec.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 10:22:26 -0700

>> in vCard base. We need to wrap this up.

+1 to that. :)

> That is fair enough (yes I would like to see vCard 4.0 published as soon
> as possible). If we do not have enough consensus on this I am willingly
> to do an individual submission and work on this outside the base spec.

That might be the best path forward at this point.

Peter

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

---

From: Filip Navara <[email-masked]>
Date: Tue, 16 Feb 2010 18:23:59 +0100

> domain, bit it would be a GoogleTalk service.

DNS records come to mind here. We use MX records to identify
"outsourced" email, SRV records could similarly be used to detect the
"outsourced" XMPP provider.

Best regards,
Filip Navara

---

From: Simon Perreault <[email-masked]>
Date: Tue, 16 Feb 2010 12:26:49 -0500

On 2010-02-16 12:08, Cyrus Daboo wrote:
> Outsourced domains. I mighty choose to have daboo.name outsourced to
> Google for all my services. So my xmpp address would still use
> daboo.name as the domain, bit it would be a GoogleTalk service.

And why would anyone need to know that you're using Google as your XMPP 
provider?

> browser). Requiring users to enter full URIs is not appropriate given
> that most of the services provide a "user id" field which does not
> include the domain. i.e. I go sign up for GoogleTalk and I get my user
> id (e.g. 'cdaboo'). How am I supposed to know to enter
> xmpp:[email-masked] or whatever. From an address book client
> perspective we need to keep the UI simple - i.e. users pick from a popup
> of popular services (with the option to manually define a custom one)
> and then enter just their user id. Under the hood the ab client can
> translate that into URIs for well known services.

Clients can do that without protocol support as far as I know. Right?

> to do an individual submission and work on this outside the base spec.

In this case, consider my comments as applying to your future individual 
submission. ;)

Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 10:30:54 -0700

> "outsourced" XMPP provider.

In fact we will soon probably define such an SRV record for XMPP, for
other reasons.

Peter

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Feb 2010 18:36:52 +0100

> daboo.name as the domain, bit it would be a GoogleTalk service.

Actually, it would be the XMPP service right? What the user is 
interested in is the client to invoke, which is entirely orthogonal wo 
what service offers the IM functionality...

Best regards, Julian

---

From: Remco Post <[email-masked]>
Date: Tue, 16 Feb 2010 20:39:11 +0100

On 16 feb 2010, at 17:10, Peter Saint-Andre wrote:
> 
> Don't assume users know that AIM is provided by aol.com. :) 

Users don't need to know, application developers need to know, IMHO. Users never see the raw data of the vCard, they see what their app presents them. So all the vCard needs to contain is enough for an application developer to connect the user to the correct contact using whatever protocol he likes....

-- 
Met vriendelijke groeten,

Remco Post
[email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Tue, 16 Feb 2010 18:49:25 -0500

> That might be the best path forward at this point.

I would favour Cyrus's submitting an individual draft, and then having
the working group consider adopting it (as an extension).

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 17:57:49 -0700

> the working group consider adopting it (as an extension).

+1