Subject: [VCARDDAV] A word on "extensions"

From: Simon Perreault <[email-masked]>
Date: Sat, 26 Jul 2008 14:21:54 -0700

Hello all,

There's been some recurring discussion about what properties go into the 
core vCard spec and what properties will be left for "extensions".

First, I'd like to clear up some apparent confusion. By "extensions" it 
is not implied properties that start with "X-" nor properties in the 
vendor spaces. Instead, it refers to separate RFCs that describe 
additional properties. For example, one could write an RFC titled "vCard 
Genealogy Extensions" where the properties FLOURISHED and BAPTISED would 
be defined, along with (let's say) a bunch of new values for the RELATED 
property letting one express complex genealogical relationships. That 
RFC would contain directions for IANA to register those new items into 
the vCard registries.

If you can think of a way that Section 12.1 could be rewritten so as to 
prevent confusion, please speak up. That would be very helpful.

Second, it was always the intention of adding common, core properties to 
the core spec. Take for example the MEMBER and RELATED properties which 
have been added to the core spec.

Finally, we work by consensus. If the group wants a property added to 
the core spec, it will be. Each issue closed with "no action, left for 
extension document" has been discussed. There were summary emails sent 
advising people to speak up now either for or against the proposed 
resolution, and replies were received to the effect of "+1" in most 
cases. I think any issue may be reopened by consensus, but I'm not the 
protocol expert here.

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

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 26 Jul 2008 15:54:19 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>There's been some recurring discussion about what properties go into 
>the core vCard spec and what properties will be left for "extensions".
>
>First, I'd like to clear up some apparent confusion.

[...]

Thank you; that makes things clearer, for me at least.

>prevent confusion, please speak up. That would be very helpful.

Section 12.1 of what?

>Second, it was always the intention of adding common, core properties 
>to the core spec. Take for example the MEMBER and RELATED properties 
>which have been added to the core spec.

What are the perceived benefits of adding properties as extensions, 
rather than core components, or vice versa?

>cases. I think any issue may be reopened by consensus, but I'm not the 

You don't cite any specific examples, but you might be referring to my 
recent comments, particularly on:

   New sub-property: Initials (Issue 154)

    <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00476.html>

   Geographic properties (issue 155):

    <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00473.html>

   Alternative dates (Issue 156)

    <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00474.html>

I was not aware that discussion (in many cases, of my original 
proposals) was continuing, and apologise if that was due to my 
inattentiveness. I'm having trouble locating records of some if it, 
assuming it took place on this list. Please can you provide references, 
preferably as URIs for the list archives?

I do note the discussion around coordinate schema, from February, which 
makes no mention of the new schema for the imminent European GPS system, 
nor of schema for coordinates on other bodies, such as the moon.

I have also found your e-mail of 9 June, "Closing many issues without 
action", which contains no such "speak up now or..." warning, nor any 
deadline date for doing so; and your e-mail of 2 July, "vCard 4 
Summary", which says "the following issues may be closed soon".

The latter seems to have attracted only a single "+1" comment (from 
Javier Godoy on 3 July); hardly a robust basis for making decisions.

On 15 July (less than two weeks after your "soon" comment), I did speak 
up, in each case identifying apparent misapprehensions and/ or giving 
additional reasoning as to why discussion should continue, if not 
proposed decisions (apparently proposed by you as "closed with no 
action", not "closed with no action, left for extension document") 
reversed.

I would also point out that the current documentation clearly says that 
the items are "proposed for closure..., " not "closed".

By all means disagree with or refute the points I have made and the 
evidence I have given - I'm happy to discuss them - but please don't 
simply disregard them.

Regards,

-- 
Andy Mabbett

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 26 Jul 2008 16:28:15 +0100

In message <[email-masked]>, I wrote

>evidence I have given - I'm happy to discuss them - but please don't 

As I now see you didn't - apologies; your other two, recent, e-mails 
were trapped by a spam filter and I only saw them after writing the 
above.

---

From: Simon Perreault <[email-masked]>
Date: Sat, 26 Jul 2008 17:05:17 -0700

> Section 12.1 of what?

The draft of the next version of vCard:

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-03

> rather than core components, or vice versa?

For one, those that are necessary for i.e. CardDAV should definitely be 
part of core vCard 4.0 (I'm thinking about MEMBER here, depending on 
whether CardDAV will do recursive search or not).

I don't think we should be too formal about criteria for being included 
in core and instead we should evaluate each case separately.

> preferably as URIs for the list archives?

Here's the initial email where it was asked for comments on issues 154, 
155, and 156:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00406.html

BTW, it is still time to speak up, the issues have not been closed yet. :)

> nor of schema for coordinates on other bodies, such as the moon.

If you have propositions for changes to be brought to the current text, 
please write them to this mailing list.

> Javier Godoy on 3 July); hardly a robust basis for making decisions.

Remember that many people who agree will simply not write anything, 
while those in disagreement will probably say so. I'm not the expert on 
IETF procedures (the chairs should be able to answer with assurance), 
but I think that WG consensus is needed when sending a completed work 
item to the IESG, not for every single change. Otherwise I would never 
have written the PIDs-as-UUIDs proposal which I knew would be reverted 
in a later revision but still provided something to work on. (I've often 
seen this referred to in IETF circles as a "strawman proposal". Even 
obviously non-strawman proposals get the epithet, probably from fear by 
the proposer of being stoned in public otherwise. ;-) )

> evidence I have given - I'm happy to discuss them - but please don't 

Ok, back to the main discussion. The current proposal for issues 154, 
155, and 156 is "no action". We expect that if there is enough traction, 
extension documents will be written to address them. Now that you have 
been informed of what constitutes an "extension", was your mind changed?
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 26 Jul 2008 18:39:11 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-03

Thank you. That I wasn't aware of that document perhaps says more about 
me; but it might also reflect a need for a more easy-to-assimilate 
introduction for newcomers.

[...]

>> You don't cite any specific examples, but you might be referring to 
>>my  recent comments, particularly on:
>>assuming it took place on this list. Please can you provide 
>>references,  preferably as URIs for the list archives?
>

Thank you; I saw that, and wrongly referred to it being from 9 July (I 
should have said 2 July)

>> I do note the discussion around coordinate schema, from February, 
>>which  makes no mention of the new schema for the imminent European 
>>GPS system,  nor of schema for coordinates on other bodies, such as 
>>the moon.
>

I will work on that next week; I thought it might be presumptuous of me 
to post such text, before full discussion had taken place.

The final text would of course, be dependent on the presence or 
otherwise of a "body" child-of-ADR property, for the Moon, Mars, etc.

>155, and 156 is "no action". We expect that if there is enough 
>traction, extension documents will be written to address them. Now that 
>you have been informed of what constitutes an "extension", was your 
>mind changed?

About what?

If you mean in regard to the importance of the three proposals 
referenced above, then no.

If you mean that they should be in "core-" rather then "extension to-" 
vCard, then my mind has not yet been made up either way, as I still 
don't fully understand the relative implications of either course of 
action - though from my recent reading in this list's archives, I'm 
tending to think that things should be in core rather than extensions 
(of course, adoption via extensions would be better than nothing).