[Ietf-calsify] List issues so far.

[Doug at Royer.com (Doug Royer)]

[e-mail] wrote:

>
> As for synchronization, none of the RFCs nor CAP name that as a 
> purpose, and I think we ought not to get into synchronizing endpoints 
> too much - not only for simplification reasons, but because many have 
> adopted SyncML as a standard and we don't need another one.

It was in the CAP requirements, original copy at:

    http://INET-Consulting.com/draft-ietf-calsch-capreq-04.txt

And it is on the calsch.org web site (at least it used to be).

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/755f8d31/smime.bin
From Doug at Royer.com  Tue Sep 14 06:59:25 2004
From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 06:59:40 2004
Subject: [Ietf-calsify] Multiple or single BEGIN/END VCALENDAR?
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-ID: <[e-mail]>



Cameron Stillion wrote:

>I agree with the question...
>
>  
>
>>The question we need to ask is:
>>
>>   Do we want to be able to transfer 'sync' an entire calendar in one
>>    
>>
>pass?
>  
>
>>If yes, then we have to allow multiple BEGIN/END per transfer.
>>    
>>
>
>But I disagree with your reasoning.
>
>Transferring an entire calendar in one pass - does not seem to require
>more than one METHOD. If I am publishing an entire calendar, then I have
>one VCALENDAR with METHOD=PUBLISH.  If I am sending a request for you to
>attend a whole calendar's worth of meetings, then I presume I have one
>VCALENDAR with METHOD=REQUEST. 
>
That is one mode of using calendars.

The other is that the data transfer -into- the calendar is automatic.
And the CUA reads from the calendar. For example it is possible
for iTIP REQUESTS to be stored in the CS until processed by the CUA.

Those are client/server CUA/CS's. They must transfer all iTIP methods
objects to/from the CS.  So if you send me a REQUEST, it will be stored
in my calendar, even when my CUA is not running. Later when I start
my CUA it will load my calendar (PUBLISH/REQUEST/ADD/whatever).

Those are the requirements for client/server implementations.

This is not an issue for  iMIP-CUA's as iMIP only allows one METHOD
per object anyway..  For non-iMIP CUAs this will be an issue. Both
models exists. CalDav looks to be a client/server model also.

Ether way it still does not solve the problem that some (1?) 
implementation(s)
split each VEVENT into a separate VCALENDAR objects, even when
all of the METHOD values are the same.

Or is it that only one implementation can not handle multiple BEGIN/END
VCALENDAR even when all have the same METHOD value ?

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[e-mail]                 | Office: [phone]
http://Royer.com/People/Doug   | Fax:    [phone]
                               | Cell:   [phone]

              We Do Standards - You Need Standards


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/236322b4/smime.bin
From Chris_Stoner at notesdev.ibm.com  Tue Sep 14 07:23:36 2004
From: Chris_Stoner at notesdev.ibm.com ([e-mail])
Date: Tue Sep 14 07:32:12 2004
Subject: [Ietf-calsify] sending new RRULE/RDATES should not be allowed
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>





Got to disagree with you Doug.  Unfortunately, the "replace all" set does
not work with our product and interoperability testing (both external and
internal) has shown that.

We're trying to find a middle ground so that we can consume this if we
receive it and it may or may not be an issue about the standard per se, but
what concerns me is that our implementation is vastly different (when
talking recurring reschedules) from other vendors, yet we all believe that
we follow the ical standard in our products.  So there's probably something
amiss with recurring reschedules in the proposed icalendar standard.

I think we should discuss this further in an open manner.  Does anyone else
have issues with recurring reschedules?
-CS


[e-mail] wrote on 09/13/2004 08:20:20 PM:

>
> So far only Robert seem to think that the method he
> proposes is documented, standardized, or compatible with
> many others.
>
> He did the same thing on the other mailing list and caused
> months of delay. I have found over 40 ical products that
> can not use that method. Fortunately this mailing list is
> not "how can it be done", its "how do people do it".
>
> And currently the vast majority of products simply
> replace the objects during an update keeping the same UID.
>
> I do not think that the issue is stalled. I think
> that it is fairly clear - replacing the objects
> with an entire updated set with the same UID
> works with all vendors (including the one that Roberts
> company ships) I can find. Robert does not seem to
> dispute this, he simply wants everyone to also do
> it the 2nd way - and they do not.
>
>
> >I would like to know what the process is for moving forward on issues
like
> >this. I received a description of this mailing list's purpose but that's

> >about it. If a more detailed description of how conflicts are to
beresolved
> >and how decisions are actually going to be made is available pleasepoint
me
> >to it. (Surely not the same process as the previous ietf-calendar
mailing
> >list?)
> >
> >Thank you.
> >
> >
> >
>
> --
>
> Doug Royer                     |   http://INET-Consulting.com
> -------------------------------|-----------------------------
> [e-mail]                 | Office: [phone]
> http://Royer.com/People/Doug   | Fax:    [phone]
>                                | Cell:   [phone]
>
>               We Do Standards - You Need Standards
>
>
> [attachment "smime.p7s" deleted by Chris Stoner/Westford/IBM]
> _______________________________________________
> Ietf-calsify mailing list
> [e-mail]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify