Subject: [VCARDDAV] A registry for vCard versions?

From: Mykyta Yevstifeyev <[email-masked]>
Date: Thu, 15 Sep 2011 20:33:27 +0300

Hello again,

So recently published RFC 6350 specifies vCard 4, obsoleting RFC 2426, 
that defined vCard 3.  Also, vCard 2.1 spec is available 
(http://www.imc.org/pdi/vcard-21.txt).  As far as new versions may 
appear in the future, I'd like we created the registry for vCard 
versions, for convenience of interested in vCard (vCard history).  (BTW, 
what are the specifications of vCard 2.0 and 1.0?)  Is there a support 
of such idea?

Mykyta

---

From: Julian Reschke <[email-masked]>
Date: Thu, 15 Sep 2011 20:01:06 +0200

On 2011-09-15 19:33, Mykyta Yevstifeyev wrote:
> (http://www.imc.org/pdi/vcard-21.txt). As far as new versions may appear
> in the future, I'd like we created the registry for vCard versions, for
> convenience of interested in vCard (vCard history). (BTW, what are the
> specifications of vCard 2.0 and 1.0?) Is there a support of such idea?
>
> Mykyta

Collect the information and put it into the Wikipedia page.

Best regards, Julian

---

From: Simon Perreault <[email-masked]>
Date: Thu, 15 Sep 2011 14:52:41 -0400

>> specifications of vCard 2.0 and 1.0?) Is there a support of such idea?

If this is done, there would be no need for a new registry. It would be
sufficient to register the versions in the property values registry, as values
of the VERSION property.
<http://www.iana.org/assignments/vcard-elements/vcard-elements.xml#property-values>

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sat, 17 Sep 2011 11:19:30 +0300

> <http://www.iana.org/assignments/vcard-elements/vcard-elements.xml#property-values>

So I've uploaded a draft to perform the registration: 
http://tools.ietf.org/html/draft-yevstifeyev-vcarddav-version-00.  
Comments are welcome.

I'd also like, if possible and if enough support appears, we adopted the 
draft as WG item.  I'll wait WG chairs to act here to decide whether it 
may be of some interest to WG participants.

Mykyta Yevstifeyev

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Sep 2011 09:20:01 -0400

> http://tools.ietf.org/html/draft-yevstifeyev-vcarddav-version-00.  Comments
> are welcome.

I think this is a reasonable approach.  Comments on this draft:

Section 2.1 has too many citations of "[RFC5234]", and it's
distracting.  The normal style is to use a citation at first reference
and not afterward, unless there's a strong reason to repeat the
citation (a particularly important point, and/or several document
sections in between).

Also, I don't see why we ought to restrict the "dot" versions to a
single digit.  We likely will never need more than one, but we
shouldn't codify that limitation.

Also also, I think we should say something about not going back to,
say, 3.5 after having produced 4.0.  That ought to go without saying,
but, unfortunately, it often doesn't.

I suggest this (correcting English grammar along the way):

OLD
   Each of the aforementioned specifications defined a separate syntax
   for VERSION property which is appropriate for use in vCard entities
   conformant to such specification, such as (from RFC 6350; ABNF
   [RFC5234] is used):

     VERSION-value = "4.0"

   for VERSION property value of vCard 4.0.

   This document defines a simple generic syntax for VERSION property
   values, that is expressed using Augmented Backus-Naur Form (ABNF)
   [RFC5234] in the <VERSION-value> production:

     VERSION-value = 1*DIGIT "." DIGIT

   where <DIGIT> is specified in RFC 5234 [RFC5234].  All subsequent
   versions of vCard MUST define VERSION property value syntax that is
   compatible with this document.

NEW
   Each of the aforementioned specifications defined a separate syntax
   for the VERSION property which is appropriate for use in vCard entities
   conformant to each specification, such as (from RFC 6350):

     VERSION-value = "4.0"

   for vCard 4.0.

   This document defines a simple generic syntax for VERSION property
   values, expressed using Augmented Backus-Naur Form (ABNF)
   [RFC5234] in the <VERSION-value> production:

     VERSION-value = 1*DIGIT "." 1*DIGIT

   where <DIGIT> is specified in RFC 5234.  All subsequent versions of
   vCard MUST define a VERSION property value syntax that is
   compatible with this document.  Further, a subsequent VERSION
   value MUST represent a larger number than any that are already
   registered.  For example, the next version after 4.0 might be 4.1 or
   5.0.

In section 2.2, we have a conflict with the SHOULDs here, and
corresponding MUSTs in the other specs.  How about this?:

OLD
   As VERSION property was first introduced in vCard 2.1 [VCARD21],
   vCard 2.0 and vCard 1.0 did not contain such facility.  However, this
   document set up the rule that any vCard entity, independent of the
   version, SHOULD contain VERSION property, with the value conformant
   to syntax described in Section 2.1, and such property, if present,
   SHOULD be put after the BEGIN property.

NEW
   The VERSION property was first introduced in vCard 2.1 [VCARD21].
   However, this document sets up the rule that any vCard entity,
   independent of its version, ought to contain a VERSION property.
   Therefore, a vCard conforming to version 2.1 or later MUST contain
   one, and a vCard conforming to version 2.0 or earlier SHOULD
   contain one.  The VERSION property value SHOULD conform to
   the syntax described in Section 2.1, and the property SHOULD
   immediately follow the BEGIN property (and MUST do so in version
   4.0, to conform with RFC 6350).

In section 2.3, I suggest a normative requirement for future vCard
versions, rather than a non-normative suggestion:

OLD
   Specifications of further versions of vCard are supposed to
   register their own version.

NEW
   Specifications of further versions of vCard MUST
   register their own versions.

> draft as WG item.

That works for me.

Barry

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 19 Sep 2011 16:38:30 +0300

Barry,

Thanks for your comments and careful reading.  My replies are in-line.

> citation (a particularly important point, and/or several document

I'll change this so that an only mention of ABNF appears in Section 1.1? 
"Terminology", that will be renamed into "Conventions":

>    This document makes use of Augmented Backus-Naur Form (ABNF), defined
>    in RFC 5234 [RFC5234], for defining formal syntax.

>     [RFC5234] in the<VERSION-value>  production:
>
>     where<DIGIT>  is specified in RFC 5234 [RFC5234].  All subsequent
>     [RFC5234] in the<VERSION-value>  production:
>
>     where<DIGIT>  is specified in RFC 5234.  All subsequent versions of

I'll adopt this text.

>     4.0, to conform with RFC 6350).

A good proposal.  I'll change the text, modulo "SHOULD conform to the 
syntax described in Section 2.1", where I'll put MUST, to conform to 
Section 2.1.

>     register their own versions.

OK.

>> I'd also like, if possible and if enough support appears, we adopted the

So if the document is adopted as WG item, I'll submit the draft as 
draft-ietf-vcarddav-version, otherwise, when and if I receive the denial 
from WG chairs, as Individual Submission.

Mykyta Yevstifeyev

---

From: Likepeng <[email-masked]>
Date: Tue, 20 Sep 2011 00:55:56 +0000

> So I've uploaded a draft to perform the registration: 
http://tools.ietf.org/html/draft-yevstifeyev-vcarddav-version-00
Comments are welcome.

The version seems to be quite clear as specified in the RFCs. It is quite obvious that if we have another  vCard spec in the future, it will use 4.X or 5.X. There will be no overlap with the previous versions. Also the version history information can be easily got from the "Obsoletes"/"Updates" part.

I am not convinced about the need to register the version, and the need for the draft. 

Kind Regards
Kepeng

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Sep 2011 21:08:52 -0400

> I am not convinced about the need to register the version, and the need for the draft.

The reasoning isn't so much for a need to specify the version syntax
and so on, though that's a side effect.  The main reason for
registering the versions is to have one place to put pointers to the
specifications for each version.  That should make it easier for
people to migrate, when they can more easily look up the differences
between the versions.  I think that's a good idea, especially since it
will take very little work to accomplish it.

Barry

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 19 Sep 2011 21:37:28 -0400

> will take very little work to accomplish it.

are we going to create a new registry for every IETF protocol that has versions?

Marc.

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

---

From: Likepeng <[email-masked]>
Date: Tue, 20 Sep 2011 01:47:05 +0000

> are we going to create a new registry for every IETF protocol that has versions?

I have the same issue. 

This is not the purpose of standard. Standard is not for something obvious and easily searched from the internet.

Kind Regards
Kepeng

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 19 Sep 2011 20:33:57 -0600

<hat type='individual'/>

> will take very little work to accomplish it.

I disagree with "very little work" -- WG review, AD management, IESG
review, IANA registration, RFC Editor processing, it all adds up.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Tantek Çelik <[email-masked]>
Date: Mon, 19 Sep 2011 22:39:15 -0700

On Mon, Sep 19, 2011 at 19:33, Peter Saint-Andre <[email-masked]> wrote:
> ...

> Collect the information and put it into the Wikipedia page.

I agree with Julian.

Since we've documented plenty about vCard on the microformats wiki,
I've edited the "vcard" wiki page there to now be a list of versions
rather than just a redirect to RFC 2426.

http://microformats.org/wiki/vcard

Please feel free to add more versions with links and dates of publication.

Thanks,

Tantek

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Sep 2011 09:10:04 -0400

Tantek quotes a bunch of us...
>> I am not convinced about the need to register the version, and the need for the draft.

For the record, I didn't say that.  You're attributing to me something
that Kepeng said.

>> Collect the information and put it into the Wikipedia page.

Tantek then goes on to say...
> rather than just a redirect to RFC 2426.

Lovely, as far as it goes.  But look at what we're asking implementors
to do: they need to go around and search for documentation of the
different versions.  They can find 4.0 and 3.0 in the IETF, but they
have to find others elsewhere, and who knows where they'll be?  Well,
there's an obscure wiki that lists them.  Do I trust it?  What does
Wikipedia say?  Do I trust that?  Maybe there's another wiki with
other information.  And, of course, this wiki just has the vCard
information, but for other protocols I have to look elsewhere.  Ah,
here's a wiki that has email header fields, and another with media
types.  Hmmmmm.....

We have IANA registries for a reason, and we should use them.  If our
answer to registering anything (in an existing registry, remember) is
going to be "let's just put it in a wiki somewhere," then why do we
need IANA registries?  Google (or Bing, or...) is the new IANA?

PSA says...
> review, IANA registration, RFC Editor processing, it all adds up.

It does, and I'm sorry to downplay it; I should have said,
"comparatively little work."  You know that I often cite the expense
of doing even a simple document, and you know that I'm quick enough to
push back on Mykyta when I think he's proposing something time-wasting
or otherwise unnecessary.  This time, I think it's the right thing to
do.

Unfortunately, we painted ourselves into this "unhappiana" corner when
we defined the rules for the registries in RFC 6350.  But there they
are, in 10.2.1, second paragraph:

   Registration of new vCard elements MUST be reviewed by the designated
   expert and published in an RFC.  A Standards Track RFC is REQUIRED
   for the registration of new value data types that modify existing
   properties.  A Standards Track RFC is also REQUIRED for registration
   of vCard elements that modify vCard elements previously documented in
   a Standards Track RFC.

That's the ONLY reason this document even needs to exist (rather than
just registering the values by posting a template to the mailing
list), and the only reason it needs to be Standards Track.  I think
we, collectively, need to think harder about the implications of
overly restrictive IANA registration requirements when we write RFCs.
But that's for future work; we're in this corner now, and we just need
to deal with it.

And I do NOT think the right way to deal with it is to say, "The
registration procedures we created are too cumbersome, so we should
just document this property's values in a wiki somewhere."  The right
thing to do is to follow the procedures and register these values in
the registry that we set up for that purpose.

I think there's value in saying that the VERSION value is NOT meant to
be just a text string.  I think there's value in having a central
place *that people know about* for finding pointers to the
documentation for the different vCard versions.  And I think there's
value in using our registry for what it was created for.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Sep 2011 15:58:33 +0200

> need IANA registries?  Google (or Bing, or...) is the new IANA?

Well.

(1) I *specifically* recommended Wikipedia, because that's the place *I* 
would start looking for information like that.

(2) What class of users do you think will be confused about vCard 
versions *and* realize that an IANA registry will help them?

> value in using our registry for what it was created for.

I was with you with the first two sentences.

So, seriously, how do you think people will find that registry?

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 20 Sep 2011 17:05:39 +0300

20.09.2011 4:08, Barry Leiba wrote:
> specifications for each version.

Yes, this was what I intended the document's purpose to be.

Mykyta

>   That should make it easier for

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 20 Sep 2011 17:07:47 +0300

> are we going to create a new registry for every IETF protocol that has versions?

If we have a protocol that makes use of IANA to register some values 
among which there is a version value, we are going to track the latter 
with IANA.  This is the case with vCard, and we have all means to 
perform such action.

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 20 Sep 2011 17:15:36 +0300

> here's a wiki that has email header fields, and another with media

Agreed here, as far as IANA is declared to track particular values 
(protocol elements, etc.) *formally*.  IANA registry should be the 
primary source of information, which Wikipedia and all similar projects 
should take the information from.

> need IANA registries?  Google (or Bing, or...) is the new IANA?

+1.

> or otherwise unnecessary.

That's actually what Barry often does :-).

>   This time, I think it's the right thing to
> do.
>
> list), and the only reason it needs to be Standards Track.

Yes, as the document tries to establish how VERSION values are used in 
vCard entities of less-than-2.1 versions, and Standards Track is 
required.  Otherwise, I could simply ask publication of Informational 
RFC, probably on Independent Submission stream, but that's the 
requirement of RFC 6350.

>    I think

I actually think that 'Expert Review' policy should have been used here 
and would be efficient if used.  I suppose we'll deal with this if and 
when RFC 6350 is revised.

Mykyta

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Sep 2011 10:16:26 -0400

Hi, Julian.

> would start looking for information like that.

I actually think someone should *also* put the information in W-pedia,
because it will be helpful.  BUT...
1. That's not an official IETF place for things.
2. People still have to wonder whether information in W-pedia is accurate.

The second point isn't much of a problem here, because someone can
just look at the cited reference and see whether it's right.  But
there is some concern, and there are people who don't go to Wikipedia
for this sort of stuff because of that.

> (2) What class of users do you think will be confused about vCard versions
> *and* realize that an IANA registry will help them?

See below.

> So, seriously, how do you think people will find that registry?

People will find the registry because it's the official vCard
registry.  I'm obviously not aiming this at people who don't know from
IANA registries.  But someone who goes to implement vCard, finds the
current version of the vCard RFC, and wants her code to accommodate
earlier versions, for example, could see this:
1. There's an "obsoletes" at the top of RFC 6350 that will get her to
the 3.0 spec.
2. There'd be an "updated by" at the top of RFC 6350 that will get her
to this registration spec.
3. There's a registry defined in RFC 6350 that she might look at
anyway, regardless of (2).

Again: Why do we have IANA registries if we don't mean to use them,
and expect others to find them and use them?

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Sep 2011 16:22:03 +0200

On 2011-09-20 16:07, Mykyta Yevstifeyev wrote:
> with IANA. This is the case with vCard, and we have all means to perform
> such action.
> ...

No problem with that.

I just seriously doubt that it will help anybody "outsider" to actually 
find out about vcard versions. Unless you can make the registry the #1 
search result for "vcard version".

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 20 Sep 2011 17:22:45 +0300

So why we have IANA if we have Wikipedia?  Should we therefore liquidate 
IANA and transform all the registries into Wikipedia articles?  Or 
should we leave maintaining protocol values to enthusiasts who are 
interested in particular protocols?  Or something else?..

Mykyta

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 20 Sep 2011 17:33:03 +0300

20.09.2011 17:22, Julian Reschke wrote:
> I just seriously doubt that it will help anybody "outsider" to 
> actually find out about vcard versions. Unless you can make the 
> registry the #1 search result for "vcard version".

Well, the draft we're discussing now is number 4 in search result for 
"vcard version" now (searched with Google), and it was uploaded only 3 
days ago.  Apart from Wikipedia, that has some narrative text on 
post-2.1 versions, I see no other source of information on vCard 
versions on the first page of Google search.

BTW, #1 result for "link relation types" is 
<http://www.iana.org/assignments/link-relations/link-relations.xml>, and 
iana.org has Google PR of 5; so please compare with Wikipedia's "6".

I don't think search ratings are going to be a problem.

Mykyta

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 20 Sep 2011 10:38:39 -0400

Hi Mykyta,

--On September 20, 2011 5:22:45 PM +0300 Mykyta Yevstifeyev 
<[email-masked]> wrote:

> IANA and transform all the registries into Wikipedia articles?  Or should
> we leave maintaining protocol values to enthusiasts who are interested in
> particular protocols?  Or something else?..

So I was about to send out an email saying I have no problem with the 
current draft, but then I thought about it some more and now I do.

The registry defined in 6350 is for vCard v4 (and above) properties, 
parameters and property values. VERSION:3.0 is NOT a valid v4 property 
value. Adding vcard elements from previous specifications into the current 
registry is wrong.

So at the very least, if we are going to consider this draft it should only 
list 4.0 as a valid VERSION value. Given that, I see no value in having 
this. If you want to post an errata for inclusion in a future update 
stating that 4.0 should be registered for VERSION, I think that is fine.

As for how others will find the older versions. Well if they read 6350 they 
will see references to v3 and v2.1 and can go look those up - that is 
sufficient from a technical standpoint. Anyone wanting to know the history 
of vcard can just do a web search.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 20 Sep 2011 15:40:38 -0400

> value. Adding vcard elements from previous specifications into the current

I strongly disagree that it's wrong.

6350, reasonably, doesn't define any values other than "4.0", but
there's nothing at all that prevents another document from defining
any values we want in there... subject to expert review.  If the
experts think that it's useful to register historic values for the
purpose of documentation (which this expert thinks is useful, but
which clearly doesn't have consensus at this point), we can absolutely
do that, and there's nothing "wrong" with doing so.

I suppose it would be nice if there were a "status" table column, and
we could put "historic" in there for the older values.  I'm not sure
why we don't routinely define registries with that option, since we
often seem to need to add it later.  But even lacking that, I think
it's reasonable to do this, and within the boundaries of why the
registry exists.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Sep 2011 10:19:28 -0400

Hi Barry,

--On September 20, 2011 3:40:38 PM -0400 Barry Leiba 
<[email-masked]> wrote:

>> value. Adding vcard elements from previous specifications into the
>> current registry is wrong.
>

This boils down to a question about how someone might use the registry. 
Someone might use it for "informational" purposes - i.e., finding out about 
old versions. However, it can also be used to build a schema validator. 
i.e., someone can take the XML registry data and use that to build a 
validator that checks properties, paramaters, values etc against the 
registry. In that case it is wrong to have the old version numbers present. 
Yes, you could argue that any good validator would probably validate 
version separately, but by allowing some old values in here, we are opening 
the door to the argument that old old values (e.g. various TYPE options we 
deprecated) should also go in.

So yes, we disagree. But at the end of the day there are more important 
things to worry about and spend time on than this, so I won't strongly 
object if this draft goes forward.

-- 
Cyrus Daboo

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Sep 2011 08:22:59 -0600

<hat type='AD'/>

On 9/21/11 8:19 AM, Cyrus Daboo wrote:

> at the end of the day there are more important

Isn't that a reason for not pushing this draft forward?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Sep 2011 10:29:12 -0400

> Isn't that a reason for not pushing this draft forward?

OK... if Mykyta and I are the only ones who want to register this,
then we clearly don't have consensus.  I'll stop arguing for it,
unless more support crops up.

I do think, though, that we should think about the exceedingly
heavyweight registration process we've set up.  It pretty much
guarantees that most suggestions for changes will be considered not
important enough to spend the time and effort on, and, therefore, that
there'll be a lot of unregistered tweaks that just wind up being used
ad hoc.  That's not good for interoperability.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Sep 2011 10:43:17 -0400

Hi Barry,

> ad hoc.  That's not good for interoperability.

The heavy weight aspect being to require an RFC? Note: a standards track 
RFC is only a requirement where a change to existing vcard v4 elements is 
being proposed - so the bar is lower for new properties. I think that is 
reasonable for internet wide interoperability use cases. For a lesser 
requirement we do have the vendor namespace that does not require an RFC or 
indeed any formal review. If interoperability is the goal of the vendor 
(and one would hope that were so) then the public review process is exactly 
what they should be willing to submit to - with the knowledge that could 
cause delays and revisions to their specification. That is the price of 
trying to guarantee some level of interoperability...

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Sep 2011 10:52:18 -0400

Hi Peter,

> Isn't that a reason for not pushing this draft forward?

Personally I don't think this specification adds much value to what we have 
now (and I am sorry Mykyta had to go through the trouble of writing up a 
draft for that to become obvious to me).

So yes, I think the IESG/IANA cost is not worth the value in this case.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Sep 2011 10:52:46 -0400

> The heavy weight aspect being to require an RFC? Note: a standards track RFC
> is only a requirement where a change to existing vcard v4 elements is being
> proposed - so the bar is lower for new properties. I think that is
> indeed any formal review. If interoperability is the goal of the vendor (and
> one would hope that were so) then the public review process is exactly what
> they should be willing to submit to - with the knowledge that could cause
> delays and revisions to their specification. That is the price of trying to
> guarantee some level of interoperability...

The problem is that we layer the requirements, and I think we don't
consider that some could be handled just as well without the layering.
 In this case, we have expert review AND RFC required AND
standards-track for adding to the base spec properties and parameters.

If someone should want to add a new "type=xxx" and register the value,
they'd have to do it with a standards-track RFC.  Expert review alone
should be entirely adequate for that.  Similarly with most other
changes: we could have stuck with expert review, and not required an
RFC at all, and certainly not a standards-track RFC.

Even in this case, the case of VERSION values, expert review would
have been fine.  Mykyta would have made his proposal, we would have
had the same discussion we've had, and the expert would have said no.
That's the outcome that reflects consensus.

But now consider someone from W3C or OASIS or OMA or wherever,
unfamiliar with IETF process and only dealing with it tentatively and
reluctantly.  We've put an unreasonably high barrier for her to get
her extension approved, and we've made it cost *us* a lot more than it
needs to.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Sep 2011 10:54:23 -0400

...
> her extension approved, and we've made it cost *us* a lot more than it

Maybe we should take further discussion of this to the happiana list?

Barry

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 21 Sep 2011 10:57:02 -0400

> Isn't that a reason for not pushing this draft forward?

I think the "more important things to worry about" reason that is often pushed in IETF is not a sufficient reason.  

I would argue that this request for registry is just not appropriate. A registry is there to register codepoints within a range in a protocol field or namespaces. It provides consistency between multiple protocols, multiple versions of a protocol, multiple implementations, etc...  I still don't see any value for this registry to register version numbers just for the whole purpose of helping developers to find all the versions of a protocol. I can't see it.  Again, are we going to create registries for all IETF protocols who have more than one version? http? smtp? imap? pop? mpls? ipsec? ...

Marc.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 21 Sep 2011 11:06:56 -0400

Hi Barry,

> her extension approved, and we've made it cost *us* a lot more than it

I think it is important that a stable specification for all registered 
elements. The question is whether such a specification has to be "hosted" 
by the IETF or whether other recognized bodies can do so.

So I think I would be OK with modifying our process to one where only 
expert review is required, provided the spec authors can point to a stable, 
freely available specification. If that cannot be achieved, then an RFC of 
some kind is required. Also, the question arises as to whether to allow one 
organization to modify registered elements of another. That is where the 
requirement for a standards track RFC to modify v4 elements seems 
reasonable to me - but how would that work with, say, OASIS wanting to 
modify something registered by W3C? What about potential IPR issues - we 
know where we stand there with the IETF.

Whilst the details of this are off-topic for the vCard WG, I do think we 
should monitor the situation as we start to see more registrations and 
decide whether we have a problem that needs addressing. Note that this 
situation is also true in the iCalendar space, and I know the smart grid 
work in OASIS, which is making heavy use of iCalendar for its scheduling 
data, is an area that could be impacted by this.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Wed, 21 Sep 2011 11:23:04 -0400

> So I think I would be OK with modifying our process to one where only expert
> review is required, provided the spec authors can point to a stable, freely
> available specification.

We have a registration procedure for that, called "Specification
Required" [see RFC 5226 section 4.1].  We chose not to use it here,
and I think the result is too restrictive.

> Also, the question arises as to whether to allow one
> requirement for a standards track RFC to modify v4 elements seems reasonable

1. Expert review can handle that situation.  The expert reviewer can
see that OASIS is trying to modify something originally registered by
W3C, and can question it, and verify whether it's OK or not.

2. Putting it in an RFC doesn't make this any better.  W3C could get a
PS RFC to register something, and OASIS could go for another PS RFC to
change it.  Someone in the process still has to make sure that's OK.
Why isn't that someone the expert reviewer?

b

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Sun, 25 Sep 2011 07:12:28 +0300

Cyrus, all,

I don't actually think this registry is for vCard 4 elements only - the 
title reads: "vCard Elements" - but as we have a disagreement, I won't 
begin a separate discussion on "what is this registry for" and so on.

Taking this into account, I think my first proposal for tracking vCard 
versions was better.  That proposal was to create a separate registry 
for vCard versions, and the only reason I've written the current draft 
was Simon's response proposing doing so.  And now could we please 
reconsider the first idea?

Mykyta Yevstifeyev

20.09.2011 17:38, Cyrus Daboo wrote:
>> should
> So at the very least, if we are going to consider this draft it should 
> only list 4.0 as a valid VERSION value. Given that, I see no value in 
> having this. If you want to post an errata for inclusion in a future 
> update stating that 4.0 should be registered for VERSION, I think that 
> is fine.
>
> As for how others will find the older versions. Well if they read 6350 
> they will see references to v3 and v2.1 and can go look those up - 
> that is sufficient from a technical standpoint. Anyone wanting to know 
> the history of vcard can just do a web search.
>