Subject: [Ietf-calsify] sending new RRULE/RDATES should not be allowed

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 13:14:37 2004

This is equivalent to sending a cancel on all the events and then 
resetting the RID values with new dates.
Thus you should send a cancel and sent the new RULE with a new UID.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 14:14:37 2004

That make no sense at all. You effetely have declared
that no one can ever make changes.

I know of no product that does this, why would we want to
change to this method you propose? The idea of this mailing
list is to simplify and make compatible objects. This would make
a huge percentage of products incompatible with the current object
methods.

You would force two sets of objects - the cancel objets followed
by exactly what I said - a replacement set - except
the end CU/CUA would not know they are a replacement set.
What is the advantage over just sending a replacement set?

[email-masked] wrote:

>------------------------------------------------------------------------
>
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>  
>

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              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/20040913/05690352/smime.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 14:33:09 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/0a5953df/smime-0001.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 14:43:14 2004

[email-masked] wrote:

>You can make changes using the standard RID method.
>  
>
First - that methid is not documented in 244[567], and it is not 'standard'.

Second - Almost ALL implementation do not do it that way.

So why should we bother considering it?

-- 

-------------- 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/20040913/7ab1b6a3/smime.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 14:45:55 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/6882d9a7/smime.obj

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 14:56:40 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/6737bc02/smime.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 14:56:47 2004

[email-masked] wrote:

>by sending a NEW rule you are telling me everything I have is invalid. 
>Throw it away.
>Most of the time what we really want to do is just change a single 
>instance or maybe move the entire meeting set.  In either of these cases 
>we probably do not want to throw out any description changes that already 
>exist on individual instances. 
>  
>

>>Thus you should send a cancel and sent the new RULE with a new UID.
Which throws away the description among ALL other things ?

-- 

-------------- 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/20040913/07b30a17/smime-0001.bin

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Mon Sep 13 15:17:45 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040913/12135465/smime.obj

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 15:43:04 2004

At his point I am going to consider your posts as trolling.

Does any one (else) have any input on this topic?

-- 

-------------- 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/20040913/db69b932/smime.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Mon Sep 13 17:08:57 2004

> At his point I am going to consider your posts as trolling.

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 be resolved 
and how decisions are actually going to be made is available please point me 
to it. (Surely not the same process as the previous ietf-calendar mailing 
list?)

Thank you.

-- 
Free SyncML-capable replacement for Exchange and Outlook
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 17:20:38 2004

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.

-- 

-------------- 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/20040913/1ac5ca47/smime.bin

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Mon Sep 13 18:16:28 2004

Thanks for the response.

However, I really am wondering what the process is. For example, in the 
simplest case where we want to fix a 2445 typo and we all agree. Is there a 
person or group that will maintain _the_ fix list that will be accepted by 
the IETF. Or is the list simply to be maintained ad-hoc by the people on the 
mailing list. Or, what... ? I seem to have missed the memo.

Thanks.

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Sep 13 18:29:32 2004

So far this is no WG - this is just a mailing list.

The IETF has an ISSUE page/tool , I think that we should use that.

People will need to write drafts, submit them, and get feedback. That
is the process. Until there is a draft, there is nothing do decide.

A simple typo will be noteworthy, but not that relevant as there
will be new drafts written that may take some of the existing text.
A typo list can be used to verify the same mistakes are not taken again.

Another problem is that the compatibly testing has been very limited
so far. A small handful of vendor that could afford to pay the price
to attend is far from an exhaustive compatibility testing.

 I would propose that we (I'll volunteer) to setup some free testing.
Not sure what we need yet.  The results of the commercial testing
have not yet been provided.

-- 

-------------- 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/20040913/8354ff47/smime.bin

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Tue Sep 14 07:32:12 2004

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

> >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
> [attachment "smime.p7s" deleted by Chris Stoner/Westford/IBM]

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Tue Sep 14 07:44:30 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/a305fd67/smime.obj

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Tue Sep 14 08:00:33 2004

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/octet-stream
Size: 4696 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20040914/43ae86db/smime-0001.obj

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Tue Sep 14 10:28:40 2004

On Sep 13, 2004, at 5:14 PM, Doug Royer wrote:

> That make no sense at all.

If one can't make sense of something, it is imprudent to assume that's 
necessarily because it makes no sense.  The problem can be on either 
end.

> Does any one (else) have any input on this topic?

Yes, I do.  While I have no opinion either way about the details of 
this disagreement, I want to say that I consider it completely 
unacceptable to dismiss someone else's politely-expressed opinions with 
a pejorative -- especially one that seems to make no sense in context.  
What on earth would Tom [Ramsdell] be "trolling" for?  Arguments for 
the sake of arguments?

On Sep 13, 2004, at 8:08 PM, Mark Swanson wrote:

> this.... (Surely not the same process as the previous ietf-calendar 
> mailing
> list?)

I think the very first deliverable of this list, which we/I have 
neglected so far, should be a proposed charter for a new working group. 
  Once that is established, we will get working group chairs, who will 
be responsible for such disputatious-issue resolution.  Until then, I 
don't really expect controversial issues to be *resolved*, and I see 
the purpose of the current preliminary discussion as exploring the 
issues and discussing which ones we should *try* to resolve -- which, 
coincidentally, involves basically the same questions as drafting a 
charter.

> proposes is documented, standardized, or compatible with

The fact that only one person (or a few) speaks out about either side 
of an issue does NOT mean that whoever is most aggressive gets to 
declare a consensus.  For my part, I haven't expressed an opinion 
because I don't yet consider myself well-informed enough to have one, 
and was looking forward to clarification, explanation, and persuasion.  
If I had to take sides in the absence of these, I would be 
instinctively inclined to take the side that's being most polite.   My 
preference, however, would be to see the issues sufficiently well 
thought-out and clearly spelled-out that I could confidently reach my 
own conclusion.

More philosophically, this attitude isn't just because I hate conflict 
(although I do).  It's because I believe that when issues are really 
well explored, they are much less likely to end up in flat-out 
disagreements that *require* voting.  Although I didn't participate in 
much of the long history of the calsch group, the resulting documents 
certainly look to me like too many arguments were somehow settled 
before they were well-enough understood, perhaps by a "tyranny of the 
loudest."  I would really like to make sure that doesn't happen here.

> He did the same thing on the other mailing list and caused months of 
> delay.

If you are conjecturing that delay is his motive, I can tell you, as 
his coworker, that this is just incorrect.  So either one of you is 
simply flat-out wrong -- in which case you should eventually be able to 
persuade people like me -- or there are subtleties that are not being 
properly addressed or elucidated in this discussion.

> Fortunately this mailing list is not "how can it be done", its "how do 
> people do it".

This shows again why we need a clear charter -- for my part, I don't 
think *either* of those characterize our goal very well, but I'm closer 
to the former than the latter.

> I do not think that the issue is stalled. I think that it is fairly 
> clear

The debate is *obviously* stalled, however clear the issues may be to 
you -- "stalled" and "clear to you" are not antonyms.

On Sep 14, 2004, at 10:45 AM, [email-masked] wrote:

> You just are too stubborn to admit it.

Sigh.  Can we please try to keep this list free of ad hominem attacks 
on *both* sides?  -- Nathaniel

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 12:30:08 2004

>internal) has shown that.
Odd. My testing with your product shows that it does work. Maybe we are not
talking the same thing.

(1) I send a REQUEST - you accept.
(2) I send another REQUES with updated information - you accept.

(1) has a UID of 'xxx', SEQ of 0
(2) Has a UID of 'xxx;  SEQ of 1

It works with your product - what does not work?

-- 

-------------- 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/ce52af81/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Sep 14 13:32:52 2004

>> Fortunately this mailing list is not "how can it be done", its "how 
>> do people do it".
>
>
> think *either* of those characterize our goal very well, but I'm 
> closer to the former than the latter.

It was my understanding that the goal was interoperability. For that I read
(in the simple case) if a HUGE number of venders do SOMETHING
and SOMETHING is working. it would seem to me to be easier
to make the smaller number of vendors change to the SOMETHING method.
Of course things are never that simple.

And the 2nd point is that if we do not know what the vendors are doing
then how can we declare anything interoperable? We only have a small
number of vendors that could afford the commercial testing.

Which is why it seems to me to be "how do people do it".

There seems to be 3 basic types of iCAL usage:

  (1) iMIP

  (2) The HTTP/WEBDAV POST/GET of objects - or WEB calendars
         that import/export iCAL.

  (3) PDA's and synchronization (And the 3 CAP vendors).

What vendors put in each has some overlap.

VALARMS go into (2) and (3) and almost never in (1)

Several common custom properties go into (2) and (3) and a different
set of common custom properties tend to go into (1).

I think we need to figure out the MINIMUM set that works for everyone
(as in how they do it now) and that needs to go into the 'basic' ical draft.
And I think we need to recognize that some large vendors did not do
it as documented. And have failed to document how they do it. These
need to be weeded out as noise as no one can be compatible with
undocumented procedures.

Same with scheduling. We need to figure out the basic minimum for
scheduling and that needs to be in 'basic-scheduling draft'.

Everything else I think need to be in add-on drafts.

If this is an iCAL-next, I think we are opening up the scope to years
of debate - which is how I read "how can it be done".

-- 

-------------- 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/f2d36852/smime.bin

---

From: Dave.Thewlis at calconnect.org (David C. Thewlis)
Date: Tue Sep 14 13:53:54 2004

>number of vendors that could afford the commercial testing.

I presume by "commercial testing" you are referring to the Calconnect
Interops that The Calendaring and Scheduling Consortium was in part created
to conduct?  FYI we set the fee at $1500 for members and $2500 for
nonmembers, which is intended to be a revenue-neutral fee at the size we
expect an Interop to be.  Granted that's not *cheap* but it's not horribly
expensive either.

We have talked about doing virtual interops in the future (although I
gather the consensus from the last virtual interop was that overall the
in-person sessions are more productive), but don't have any current plans
for one.  

We'll be happy to start planning for the next one either virtual or real,
as soon as there's a need for one.  It hasn't been clear to me that we
would need further Interops on the current RFCs as opposed to what may come
of these discussions, but there's absolutely no reason we go ahead with one
now folks see a need.

Dave thewlis
Executive Director
The Calendaring and Scheduling Consortium

---

From: Dave.Thewlis at calconnect.org (David C. Thewlis)
Date: Tue Sep 14 14:05:14 2004

Pat Egen posted to this list that she was waiting for the last of the
results from the testers before completing her detailed report on the
Interop at UCB.  The final results were sent to her late last week, but Pat
had just left on vacation trip.  I believe she returns around the 25th, so
we can hope for her final report shortly after that.  

Our apologies for the delay, but as Pat said she wanted to make the report
as complete as possible and clearly the results from all of the testers
were important.

Dave Thewlis
Executive Director

---

From: TimHare at comcast.net ([email-masked])
Date: Tue Sep 21 20:35:01 2004

Back on the 14th, there was some discussion about coming up with a charter, 
along with some discussion about "How it can be done" versus "How it is 
being done now".  I haven't seen much discussion since, though I have seen 
some more discussion attempting to summarized list issues so far.

Here's my proposal for a mission statement: "to find a set of iCalendar 
objects, and iTip verbs which can be used between any two calendaring 
products/tools and which will provide interoperability between any two 
calendaring products/tools".

To add to the  "How it ... " discussion,  and in conformance with my 
mission statement above, I would propose that even if a particular piece of 
software supports lots of complex interaction between its own clients and 
servers there exists the need to use a simplified interaction with other 
implementations.

Here are the cases I've thought of so far:

A:  Publishing (METHOD: PUBLISH) a file to be picked up by others, 
implementations unknown.
B: Using iTIP methods to interact with others,  in domains other than the 
current one,  implementations unknown.
C: Using iTIP methods to interact with others in the same domain, 
implementation can possibly be assumed.

In case A I would propose all dates be either UTC or floating, and that 
recurrence sets be expanded before publishing into many VEVENTS.

In case B I would propose all dates be UTC,  but the simplest forms of 
RRULEs be used (or not at all).

In case C use whatever features are implemented.

The implementation can determine what to do for each 
attendee/organizer/whatever based on whether the host name of that person 
matches the domain of the implementation - i.e., if I'm scheduling a 
meeting in Lotus Notes and all the attendees have the same host and domain 
name, I can assume they are also using Lotus Notes. If they have the same 
domain name but different host names, I can't make that assumption because 
many companies might have multiple different implementations such as 
Groupwise and Exchange.

Our simplification and interoperability problems come primarily from case 
B. Therefore, the simplest course to me would be to find the "greatest 
common factors" or "least common denominators" between implementations , 
then in a draft document specify that as the interoperability 
specification. We would have a document that described one way to 
interoperate, while we could continue to debate what to include/exclude to 
simplify things. Since, to interoperate, we would probably be describing 
mostly the simpler parts of the current RFCs we'd be unlikely to eliminate 
many of those parts as we reworked things.

When the first Interop report from the Calendaring & Scheduling Consortium 
comes out, we will have another data point to work from, also.

Tim Hare
Interested Bystander, Non-Inc.