Re: Contact API & vCard: phone numbers (like ims) should be explicitly scheme independent

Hi Erick,

Erick Johnson wrote:
> http://www.ietf.org/mail-archive/web/vcarddav/current/msg01667.html
>
> In that message, he makes it clear that vCard properties should not be
> tied to a specific protocol, otherwise the field becomes too rigid and
> would create the need to overuse generic URL properties. This notion
> of scheme independence is directly in line w/ the `ims` field, the
> field allows for specifying the IM address in any number of IM
> protocols, Jabber, AIM, etc... This definition of the `ims` field
> makes it directly compatible w/ the flexibility of the vCard `IMPP`
> field.

Great. I'll claim this flexibility as one of the principles for the 
design then :)

>
> Since there is no canonical definition of the attribute value currently
 > I think that what I'm asking for is implicitly allowed, however I
 > worry that with the current name of the field and without an explicit
 > definition of the value, that the validity of using any voice capable
 > URL in the phone field would become unclear.
>

We didn't place any semantic or syntactic values on these properties for 
precisely this reason. While your concerns are not explicitly covered in 
the specification they are implicitly valid and therefore don't 
absolutely require prose. User agents are free to do what they wish with 
such data contained therein (e.g. highlight sip: addresses for click 
activation to start a call or launch an external application to start a 
comms session).

> Going further than that - but something I think would break the
> symmetry with POCO - would be to use a more generic name for the field
> like `tel` in the vCard case to more accurately describe the purpose
> of the field value... however I feel this may be too radical a change
> this late in the game.
>

On the subject of re-naming this field (and other fields) it is a cost 
vs. benefit exercise. Perhaps the costs outweigh the benefits at this 
stage (e.g. we would be breaking current implementations). OTOH, if 
we're going to do it sometime then we should do it now, before things 
are set in concrete, so to speak. Personally, I'm happy to stick with 
our current approach unless anyone considers this a blocker to Last Call 
publication status.

Thanks for the feedback.

- Rich

Received on Thursday, 19 May 2011 17:18:22 UTC