Subject: [VCARDDAV] Synchronization: experimental RFC?

From: Simon Perreault <[email-masked]>
Date: Tue, 06 Apr 2010 09:17:02 -0400

WG,

Is the section on synchronization (section 7) experimental? Should it be 
moved to a separate RFC with experimental status? It has never been 
implemented. See section 7.2.5 in particular...

It would be easy for me to do so if that is the working group's 
consensus, so I don't care. (Actually, it would potentially result in a 
higher RFC count for me, so I do care!)

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Kepeng Li <[email-masked]>
Date: Tue, 06 Apr 2010 21:56:06 +0800

Hi Simon and all,

I would prefer that it stays in the current draft. If we separate it into an
independent draft, there are some uncertainty, for example, delayed,
disagreed etc.  

Currently when we use vCard 2.1 for synchronization, we have identified a
lot of issues in the current deployment.

We had a lot of discussions in OMA Data Synchronization group, and for us,
it is quite useful to have this section in vCard v4.0. 

It can give some guidance for us to perform the vCard synchronization.

Thanks,

Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Simon Perreault
发送时间: 2010年4月6日 21:17
收件人: [email-masked]
主题: [VCARDDAV] Synchronization: experimental RFC?

WG,

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 06 Apr 2010 15:52:00 +0200

> higher RFC count for me, so I do care!)

Personally, I think it's worth splitting. The topic of Section 7 and the
rest of the RFC is very different and it would be nice to be able to
change one without affecting the other. The section also seems (as I
have not worked on this I don't feel qualified to make any other
statement) more experimental and vague than the rest of the document to me.

As a side note, I think that everything that is in 7.2 as an example
should also be explained/defined in 7.1 (referring to section 7.2.5 in
particular).

Florian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2010 16:03:03 +0200

On 06.04.2010 15:56, Kepeng Li wrote:
> ...

That sounds like a feature, not a bug. It could mean that both parts
could progress at different speed through the approval process...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Apr 2010 16:06:52 +0200

> could progress at different speed through the approval process...

That being said: splitting it from the base spec doesn't mean it needs 
to be "experimental".

"Proposed Standards" doesn't require implementations, "Draft Standard" does.

Best regards, Julian

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 06 Apr 2010 10:51:21 -0400

To me, the question is not the number of RFCs. One of the key issues 
that has been reported when we started working on vcard4 was about 
synchronisation. We did spent a lot of wg time trying to come to a 
solution. So to me, if we don't deliver any text on synch, then we are 
missing an important piece.

Moreover, our charter specifically talks about sync.:
") A revision of the vCard specification (RFC2426) at proposed
standard status. This revision shall include other vCard standardized
extensions (RFC 2739, 4770) and extensions assisting synchronization
technologies (for example, a per-entry UUID or per-attribute sequence
number). Other extensions shall be considered either in the base
specification or in additional documents."

Therefore, we must have sync section.

About 7.2.5, it might be not fully informative, but I would suggest that 
we should not try to be perfect for this version of vcard4, as intended 
to be Proposed Standard RFC. When more experience with implementations 
and synchronisation will be in the field, we could revisit this section 
7 and add more clues about what we found and move it to Draft Standard.

short summary: leave it as is, unless text is flawed.

Marc, as individual.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Kepeng Li <[email-masked]>
Date: Wed, 07 Apr 2010 09:40:39 +0800

>short summary: leave it as is, unless text is flawed.
+1

Another thing is, separating it into another draft will require extra work
on both drafts. We could put this kind of effort to identify potential bugs,
and fix them.

Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Marc Blanchet
发送时间: 2010年4月6日 22:51
收件人: Simon Perreault
抄送: [email-masked]
主题: Re: [VCARDDAV] Synchronization: experimental RFC?

Marc, as individual.

---

From: Robins George <[email-masked]>
Date: Wed, 07 Apr 2010 10:36:14 +0800

> statement) more experimental and vague than the rest of the document to me.
+ 1

I do believe that the synchronization engine is a separate entity and 
should be separated from this document.

- robins.