Subject: [VCARDDAV] vCard 4 Summary

From: "Javier Godoy" <[email-masked]>
Date: Thu, 3 Jul 2008 07:50:17 -0300

----- Original Message ----- 
From: "Javier Godoy" <[email-masked]>
To: "Simon Perreault" <[email-masked]>
Sent: Thursday, July 03, 2008 3:39 AM
Subject: Re: [VCARDDAV] vCard 4 Summary

> (now the last email tonight ;-)
>
> Simon Perreault wrote:
>
>>* Recently closed issues:
>>
>> - #166 Private extensions namespace
>> - #183 Change ref to ISO 9070 to ref to RFC 3406
>> - #226 Formatting of ABNF comments
>> - #252 Many typos in ABNF
> +1
>
>> - #235 Ordering of pref
> I would prefer accepting this instead of dropping PREF.
>
>
>> * Current issues being considered for closure:
>>
>> The following issues may be closed soon. Please review the proposals
>> and speak up (either in favour or against) soon.
>>
>> - #152 TEL Type Definition
>
> Current proposal:
>  1. Drop PREF. (Mark Paterson)
>
> 1a. Will be PREF dropped from all the properties or only from TEL ? There
> are some use cases backing it, at least for EMAIL.
>
> 1b. Slightly disagree. IMHO, a minimal representation of preferences 
> should
> be possible by vCard-only means. For instance, if you have an exclusive
> phone number for your office, and other shared among several offices, 
> there
> is a use case for PREF, in which nothing else is required. (However, it 
> does
> not disallow more detailed preferences being available by other 
> mechanisms.)
> I can imagine that some devices will only be able to access stored vCards,
> and then will need PREF information (at least, a loose hint about it)
>
> 1c. If this issue is controversial, it would be OK for me keeping the
> current approach instead of ordered preferences, but I would prefer the
> latter.
>
>  2. Reuse group syntax instead of WORK/HOME. (Peter K. Sheerin)
> [Neutral]
> Now that groups have been removed, the proposed solution will require
> parsing group-like constructs. While it is not complicated, nothing is 
> added
> to the expression power of vCard 3.0, then I don't see any advantage 
> (other
> than a semantic distinction between WORK/HOME and the other types). Am I
> missing any argument?
>
>  3. Restrict TYPE to this set:
>     "VOICE" / "VIDEO" / "TEXT" / "FAX" / "CELL" / "PAGER" / iana-token /
> x-token
> +1
>
>> - #154 New sub-property: Initials
>> - #155 Geographic properties
>> - #159 New property: Global Location Number
> +1
>
>> - #156 Alternative dates
> +1, close with no action.
> Maybe it would have been useful in some cases, but certainly it is 
> overkill
> (and I can expect it will not be widely implemented).
>
>> - #181 vcard should be an exchange format with no loss
>
> Close it, but consider adding text based on Simon's note dated
> 2008-06-09T10:45:29.
> Actually, it doesn't add anything to RFC 2426, but RFC 2426 is not clear
> enough (otherwise no concern would have ever been raised), and the vCard 
> 4.0
> spec does nothing for clarifying this issue (AFAIK).
>
>
>> - #301 Remove TYPE parameter for EMAIL and IMPP properties
> +1 about EMAIL, neutral about IMPP.
>
>
> Best Regards
>
> Javier
> 

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 3 Jul 2008 09:36:28 -0400

> > than a semantic distinction between WORK/HOME and the other types). Am I

You're right in that the only thing added is a semantic value to the group 
name. In fact, an IANA registry would be set up to register semantic meanings 
for groups. Groups not registered with IANA would start with "X-".

Now, we'd be removing some other things by doing that:

- Removing the duplication of the TYPE parameter values "work", "home" for 
some properties.
- Removing the TYPE parameter altogether in at least one case.
- Removing the constraint that some properties which did not have the TYPE 
parameter in the first place could not have different values for "work" 
and "home".

-- 
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