Subject: [Enum] vCard-draft - subtype considerations

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 22 Nov 2005 13:37:16 +0100

Hi,

I'm updating the vCard Enumservice draft 
(http://www.ietf.org/internet-drafts/draft-mayrhofer-enum-vcard-00.txt) to 
include subtypes. This would make the enumservice registration extensible 
once new methods of fetching vCards come up.

I've came up with the following options:

Enumservice          URI scheme          Note
-----------          ----------          ----
vcard:plain          http, https, ftp?   RFC2426 - need better name?
vcard:rdf            http, https, ftp?   http://www.w3.org/TR/vcard-rdf
vcard:xml            http, https, ftp?   http://www.w3.org/TR/vcard-rdf
vcard:carddav        http, https         draft-daboo-carddav-00.txt
vcard:xmpp           xmpp                URI & vCard encap docs expired!
vcard:ldap           ldap, ldaps         RFC2739 - URI reference, again!

Anything else? It seems to me that the area of real time access to vCards is 
mostly undefined - i was unable to find out how vCards are supposed to be 
transported in the CALSCH framework, btw. I'd rather not like to include all 
of the methods above, mostly because that much choice would either lead to 
incompatibilities between implementations if methods are optional or to no 
implementations at all if _all_ protocols are mandatory...

I've also done some "research" on clients & handsets using my "plain" vCard 
at http://nona.net/i/test.vcf (feel free to report more tests, esp. with 
mobile clients and groupware stuff!):

- Windows with Palm Desktop installed: Both Firefox and IE open up Palm 
Desktop when visiting a vCard on http, Palm Desktop offers to add vCard to 
contact database

- Windows with Outlook: Both Firefox and IE open up outlook, which offers to 
add it to the contacts

- Nokia 6630: "object not supported"

- SonyEricsson V800: offers to add contact to phone book - wow!

I'd like to get the feeling of the WG about which service types should go 
into the document - i'm a bit nervous about adding too much of those, just 
to find out afterwards that 90% of those are never gonna make it...

comments appreciated.

alex

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum