Subject: Re: [VCARDDAV] VCARDDAV Digest, Vol 30, Issue 7

From: Jean-Luc Schellens <[email-masked]>
Date: Sat, 6 Feb 2010 17:24:36 +0100

> 
> 
>   1. Re:  IMPP property and "service providers" (Marc Blanchet)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sat, 06 Feb 2010 10:55:41 -0500
> From: Marc Blanchet <[email-masked]>
> Subject: Re: [VCARDDAV] IMPP property and "service providers"
> To: CardDAV <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Barry Leiba a ?crit :
>>>> 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).
>>> 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.
>> 
> 
> 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?
> 
>>>> 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:
>> 
> 
> 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.

I totaly support the idea of using the DNS to identify an URL or IMPP and we'll apply it in the next release of Netmino.
Regards
Jean-Luc
> 
>> 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
>> _______________________________________________
>> VCARDDAV mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/vcarddav
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
> 
> 
> End of VCARDDAV Digest, Vol 30, Issue 7
> ***************************************