Subject: [VCARDDAV] One question about the URL property

From: <[email-masked]>
Date: Thu, 10 Jul 2008 10:05:55 +0200

Hi,

Could it be interesting to be able to differentiate between "homepage
URL", "personal website URL", "personal blog URL", 
"avatar URL (a website homepage used  in place of my picture )",  etc,
etc ? 

Thanks for your answers.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Thu, 10 Jul 2008 09:35:50 -0700

> "avatar URL (a website homepage used  in place of my picture )",  etc, 

One again, good ideas, but let's leave this out of the base spec. With 
vCard 4.0 there will be an IANA registry set up to facilitate the 
registration of new properties.

Simon

---

From: "Javier Godoy" <[email-masked]>
Date: Thu, 10 Jul 2008 15:55:26 -0300

Simon Perreault wrote:

>> Could it be interesting to be able to differentiate between "homepage URL", 
>> "personal website URL", "personal blog URL",
>> "avatar URL (a website homepage used  in place of my picture )",  etc, etc ?
>
> One again, good ideas, but let's leave this out of the base spec. With vCard 
> 4.0 there will be an IANA registry set up to facilitate the registration of 
> new properties.

If the extension mechanism were used, it would result in several vendor 
properties being specified, and implementations will not know how to deal with 
these new properties.

X-BLOG-URL:http:/example.org/blog/jdoe
X-HOMEPAGE-URL:http:/example.org/~jdoe

(alike the workaround for RELATED using vCard 3.0, and x-properties)

I think this situation would be best addressed by an standard parameter 
specifying the role of each URL. Then, vendors could register values for this 
parameter, instead of new properties.

URL:role=x-blog::http:/example.org/blog/jdoe
URL:role=x-homepage:http:/example.org/~jdoe

An implementation which does not recognize a particular role, may treat the 
property instance as a generic URL.

URL:http:/example.org/blog/jdoe
URL:http:/example.org/~jdoe

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Jul 2008 09:29:12 -0400

On Thursday 10 July 2008 14:55:26 Javier Godoy wrote:
> specifying the role of each URL. Then, vendors could register values for
> this parameter, instead of new properties.
>

This is also best addressed by extensions. An extension may specify new 
parameters as well. See section 12.1.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 11 Jul 2008 14:34:47 -0300

> parameters as well. See section 12.1.

Which I think may result in several vendor-specific parameters (and properties
and values) for representing the same information.

URL:vnd-foo-role=vnd-foo-blog::http:/example.org/blog/jdoe
URL:vnd-foo-role=vnd-foo-homepage:http:/example.org/~jdoe

URL:vnd-bar-role=vnd-bar-curriculum:http:/cv.example/jdoe
URL:vnd-bar-role=vnd-bar-homepage:http:/example.org/~jdoe

VND-XYZ-HOMEPAGE-URL:http:/example.org/~jdoe

The extension mechanism should be used not only for asserting uniqueness (which
is already guaranteed by the vnd-company prefix) but also for encouraging
semantic interoperability among different implementations (supposing that some
implementor cares about that...). IMHO, a single register of URL "link type"
values for a vendor-neutral parameter would be better than a set of
vendor-specific approaches, ***but I understand if you consider this is a minor
issue and should be out of the core spec.***

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Jul 2008 13:58:05 -0400

On Friday 11 July 2008 13:34:47 Javier Godoy wrote:
> Which I think may result in several vendor-specific parameters (and
> properties and values) for representing the same information.
>

I'm not sure we understand each other. There is indeed a vendor-specific 
namespace (Section 12.1.2), but top-level names can also be registered by a 
standard track RFC. So for example the "role" URL parameter could be 
registered as part of an RFC titled (let's say) "vCard Extension for URL 
Roles" defining it.

It would be standard, not vendor-specific, and separate from the core spec.

See section 12.1.1 for the registration procedure.

---

From: "Javier Godoy" <[email-masked]>
Date: Fri, 11 Jul 2008 15:24:39 -0300

> See section 12.1.1 for the registration procedure.

OK, I thought you were suggesting extensions in the vendor namespace, now I
understant you were not.

I would agree with leaving this issue out of the core spec (and address it after
some vendors have explictly requested it) *IF* it were irrelevant now (I'm not
sure it is... I would have expected a "semantic predisposition" in vCard 4.0) .

Best Regards

Javier

---

From: "Darryl Champagne" <[email-masked]>
Date: Fri, 11 Jul 2008 14:50:14 -0400

I just want to remind people that while it is great that extensions can be
registered, few companies generally bother, which leads to interoperability
problems.  It is much better for interoperability to define the items
already in current use in the core (like bringing RFC4770 into core).  Leave
future things, or things without a well established meaning out, but not
everything.  If you want stuff used, make it easy to find - not everyone
reads every RFC as it comes out.

For example, most of the following x- extensions are supported by multiple
SyncML servers & Clients at present (despite the existence of RFC 4770,
which "should" have addressed IM):

Some of these include (And I am NOT suggesting these be put in at this
time):

X-ANNIVERSARY property YYYY-MM-DD arbitrary anniversary, in addition to BDAY
= birthday 
X-ASSISTANT property string assistant name (instead of Agent) 
X-MANAGER property string manager name 
X-SPOUSE property string spouse name 
X-AIM property string Instant Messaging (IM) contact information; TYPE
parameter as for TEL (I.e. WORK/HOME/OTHER) 
X-ICQ property string " 
X-JABBER property string " 
X-MSN property string " 
X-YAHOO property string " 
X-GADUGADU property string " 
X-GROUPWISE property string " 
introduced and used by Mozilla, also used by Evolution (software) 
X-MOZILLA-HTML property TRUE/FALSE mail recipient wants HTML email 
introduced and used by Evolution (software) 
X-EVOLUTION-ANNIVERSARY property YYYY-MM-DD arbitrary anniversary, in
addition to BDAY = birthday 
X-EVOLUTION-ASSISTANT property string assistant name (instead of Agent) 
X-EVOLUTION-BLOG-URL property string/URL blog URL 
X-EVOLUTION-FILE-AS property string file under different name (in addition
to N = name components and FN = full name 
X-EVOLUTION-MANAGER property string manager name 
X-EVOLUTION-SPOUSE property string spouse name 
X-EVOLUTION-VIDEO-URL property string/URL video chat address 
X-EVOLUTION-CALLBACK TEL TYPE parameter value - callback phone number 
X-EVOLUTION-RADIO TEL TYPE parameter value - radio contact information 
X-EVOLUTION-TELEX TEL TYPE parameter value - Telegraphy#Telex contact
information 
X-EVOLUTION-TTYTDD TEL TYPE parameter value - TTY (?) contact information 
X-FUNAMBOL-ANNIVERSARY    
X-FUNAMBOL-BILLINGINFO    
X-FUNAMBOL-CALLBACK   Phone number to call back 
X-FUNAMBOL-CHILDREN    
X-FUNAMBOL-COMPANIES    
X-FUNAMBOL-CUSTOMERID    
X-FUNAMBOL-FOLDER    
X-FUNAMBOL-GENDER    
X-FUNAMBOL-GOVERNMENTID    
X-FUNAMBOL-HOBBIES    
X-FUNAMBOL-INSTANTMESSENGER   A single instant messenger address (such as
with Microsoft Outlook) 
X-FUNAMBOL-INITIALS    
X-FUNAMBOL-LANGUAGES    
X-FUNAMBOL-MANAGER    
X-FUNAMBOL-MILEAGE    
X-FUNAMBOL-ORGANIZATIONALID    
X-FUNAMBOL-RADIO    
X-FUNAMBOL-SPOUSE    
X-FUNAMBOL-SUBJECT    
X-FUNAMBOL-TELEX    
X-FUNAMBOL-YOMICOMPANYNAME    
X-FUNAMBOL-YOMIFIRSTNAME    
X-FUNAMBOL-YOMILASTNAME    

Plus some X-NOKIAs, X_SYMBIANs, and so on, most of which have considerable
overlap with the above list (especially since half the list is dedicated to
providing an exact representation of what Outlook has).

dgc

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Javier Godoy
> Sent: Friday, July 11, 2008 2:25 PM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [VCARDDAV] One question about the URL property
> 
> Simon Perreault wrote:
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Jul 2008 15:25:05 -0400

On Friday 11 July 2008 14:50:14 Darryl Champagne wrote:
> If you want stuff used, make it easy to find - not
> everyone reads every RFC as it comes out.

I'd just like to point out that there will be an IANA registry. All extensions 
will be centralized and easy to find with references to defining RFCs. In the 
near future IANA will even implement something like Atom feeds so that we can 
be notified quickly of any changes to a registry.

There are many other IETF protocols that follow this way of doing things. One 
(in)famous example is the sip-parameters registry 
(http://www.iana.org/assignments/sip-parameters). Even though many RFCs 
define the SIP protocol, its popularity and interoperability are in pretty 
good shape.