Subject: Status of the CALSCH working group

From: [email-masked]
Date: Tue, 4 Nov 2003 17:02:24 -0500

I have been, like I am sure everyone else, trying to keep up with the 
deluge of mail, particularly from Doug.  I think the approach of flooding 
inbaskets with emails challenging comments regarding the CAP draft has 
proven to be a bad one. 

I pulled over 48,000 emails into a tool to try to glean out where we 
reached consensus (the few times that we did).  I also did this to come up 
with an issues list.  In the past, this was either kept by the chair or by 
the editor.  Since this has not been done by either, I felt I needed to 
come up with something.

However, it has turned into a much bigger problem that I first 
anticipated.  The subject line of the note is not enough to determine the 
bodies of the emails.  Some of the emails have reached "epic" proportions 
and have as many as 10 subjects embedded in the note.  It's no wonder that 
we can't get consensus or even determine if we have reached a point where 
we are close.

Several months ago I attempted to put a last call out on CAP.  At that 
point, enough noise was generated on the list to prove to me that CAP in 
it's current status is not ready for prime time.  And, based on what I am 
seeing on the list, when someone makes a point that a section or item is 
wrong on the list, we don't get closure or a different solution.  We get 
instead a rash of emails that make it impossible to keep up with the 
thread or topic.  We then also start to see the derogatory remarks instead 
of constructive criticism.

That being said, I know I don't have the time to manage this nor does 
anyone else.  If we were getting constructive dialogs then I would say 
yes.  At this juncture, all we are doing is spinning our wheels.

Our deadlines for CAP are all overdue.  CAP as it stands is not ready for 
prime time.

So, at the Minneapolis meeting I am going to propose that we close down 
the working group and put it on hiatus until such time as we have 
something that can be submitted that meets everyone's needs - and not just 
those of a few people.  There are changes that need to be made to 
iCalendar, iTIP and iMIP to match what we have found in interop testing. 
All of these can be put into new drafts and submitted privately to the 
IETF.  Most of the changes are areas that simply do not work - when 
submitted, they will not break interoperability, they will ensure it.  It 
will then become the responsibility of the Method Reviewer to validate 
that the changes are done.  This does not require a working group to 
submit these changes.

If anyone feels I am wrong in closing the group, they are welcome to 
discuss it with the Area Directors at the Minneapolis meeting.

---

From: Satya Vempati <[email-masked]>
Date: Tue, 04 Nov 2003 16:06:30 -0800

Would it be possible to get someone like Nathaniel Borenstein to take
the role of a co-editor (if he is interested)? It would help to have a
seasoned veteran of the IETF process to help move things forward.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, November 04, 2003 2:02 PM
To: [email-masked]
Subject: Status of the CALSCH working group

I have been, like I am sure everyone else, trying to keep up with the
deluge of mail, particularly from Doug.  I think the approach of
flooding inbaskets with emails challenging comments regarding the CAP
draft has proven to be a bad one. 

I pulled over 48,000 emails into a tool to try to glean out where we
reached consensus (the few times that we did).  I also did this to come
up with an issues list.  In the past, this was either kept by the chair
or by the editor.  Since this has not been done by either, I felt I
needed to come up with something. 

However, it has turned into a much bigger problem that I first
anticipated.  The subject line of the note is not enough to determine
the bodies of the emails.  Some of the emails have reached "epic"
proportions and have as many as 10 subjects embedded in the note.  It's
no wonder that we can't get consensus or even determine if we have
reached a point where we are close. 

Several months ago I attempted to put a last call out on CAP.  At that
point, enough noise was generated on the list to prove to me that CAP in
it's current status is not ready for prime time.  And, based on what I
am seeing on the list, when someone makes a point that a section or item
is wrong on the list, we don't get closure or a different solution.  We
get instead a rash of emails that make it impossible to keep up with the
thread or topic.  We then also start to see the derogatory remarks
instead of constructive criticism. 

Our deadlines for CAP are all overdue.  CAP as it stands is not ready
for prime time. 

So, at the Minneapolis meeting I am going to propose that we close down
the working group and put it on hiatus until such time as we have
something that can be submitted that meets everyone's needs - and not
just those of a few people.  There are changes that need to be made to
iCalendar, iTIP and iMIP to match what we have found in interop testing.
All of these can be put into new drafts and submitted privately to the
IETF.  Most of the changes are areas that simply do not work - when
submitted, they will not break interoperability, they will ensure it.
It will then become the responsibility of the Method Reviewer to
validate that the changes are done.  This does not require a working
group to submit these changes.

---

From: [email-masked]
Date: Tue, 4 Nov 2003 19:25:24 -0500

Hm, interesting idea.

Satya Vempati <[email-masked]> 
11/04/2003 19:06

To
[email-masked], [email-masked]
cc

Subject
RE: Status of the CALSCH working group

Would it be possible to get someone like Nathaniel Borenstein to take the 
role of a co-editor (if he is interested)? It would help to have a 
seasoned veteran of the IETF process to help move things forward.

---

From: Doug Royer <[email-masked]>
Date: Tue, 04 Nov 2003 18:59:57 -0700

> I have been, like I am sure everyone else, trying to keep up with the 
deluge of mail,
 > particularly from Doug.  I think the approach of flooding inbaskets 
with emails
 > challenging comments regarding the CAP draft has proven to be a bad 
one. 
 
In the S.F. meeting YOU and Ned endorsed that method and indicated you 
would stand by
me to get CAP out without changes unless they were OVERWHELMINGLY requested
by the working group. I posted that once before and you did not 
challenge or dispute it. If you
or the AD's are changing you mind that is fine, but please do not put 
the load onto me.
 
In fact Ned directed you to not allow changes unless they were OVERWHELMING
in a pre-CALSCH meeting that you, Ned, and I participated in at S.F. 
Then Ned told me
in front of you not to change things unless you called consensus (except 
the items discussed
in the calsch meeting). You have not, they have not changed (+/- typo's 
and such).
I can not find the S.F. meeting notes ,but I seem to recall that you 
made that statement
about no changes unless they are OVERWHELMINGLY requested by the WG
in the meeting itself.

As to me challenging the comments made - I am confused as to who you
think would comment on those posts?

You have ignored ALL of my private emails to you requesting help on this
topic which is why this one is posted publicly.

I have declared several times privately and publicly that my issue list 
went to zero items,
and yet you post:

> I pulled over 48,000 emails into a tool to try to glean out
> where we reached consensus (the few times that we did). I
> also did this to come up with an issues list.  In the past,
> this was either kept by the chair or by the editor. 
> Since this has not been done by either, I felt I needed
> to come up with something.
 
I did and again my list is at ZERO technical items (+/- some typos).
Why? - Because YOU and Ned told me NOT to add to change things without
you calling a consensus. And you have not, so there is NOTHING
for me to do except typo's and such.

The latest posts from those wanting changes have little or negligible 
impact on the protocol and seem more to be disputing if something
should have been changed years ago. I can not find a single
item that was not discussed on the WG list prior to the
changes - can you? And those posts that want new items (GET-CAPABILITY
+ CALSCALE for example) are NOT on the item list in SF, so per
your and Ned's instructions to me -  I and not add them.
 
On IMC.ORG there are 12,213 total emails in the archives.
(I simply counted the number of lines that started
with 'Subject:') so it can't be that far off. I looked
in 'current archive' and 'old archive', are there more?
 
Where are the other 35,787 WG emails you talked about above?
Perhaps those are the source of confusion? I remember using
Bruce's archive in the past and noticed that non-WG calendaring
email was in his archive (which is why I stopped using it) - but
there were just a few so I do not see that as accounting for
the the 35 thousand extra emails.

-- 

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

---

From: Doug Royer <[email-masked]>
Date: Tue, 04 Nov 2003 19:37:01 -0700

> seasoned veteran of the IETF process to help move things forward.
I would have no problem working with someone. Until my recent post 
(should precede this
one on the list from me). I have not commented on the chairs 
participation - or lack of.
I have been directed by  Pat and Ned not to change things, yet Pat does not
even comment on posts requesting new action items be opened or on old 
closed items
be reopened.

Pat - I have sent you private email in the past and asked that you 
remind people
that I can not change things and that old items are closed for this 
version of CAP
and my emails have not been responded to in any way. Plus you have not 
returned
ANY of my phone calls on creating a new action item list.  And the same with
Bruce  (email only), I have reached out trying to find ways of trying
to resolve issues, you (and others) did not respond. at all. Please do 
not lay
the blame on me or this list, if you have action items, post the action 
item, and Pat you are
going to need to reply to those posts and say "no new items" or "yes 
this one
needs to be added". Letting people think that I can unilaterally 
add/delete/change
things is causing some people to get stressed out.

There was an action item list. And items were closed and the list went 
to zero items, and
yet some think that if they keep re-posting their objection to debates 
that they lost,
did not participate in (most of the time this one hits the mark), or 
misunderstood, they they can
get their way. No one can respond to all of  the requests for history to 
research each and
every item. And even if they did have the time - so what? They seem to 
NOT be comments
on the usability of CAP as written. They seem to be complaints about the 
process (legitimate but
not a CAP stopper). *I* will not open closed items - Pat you can if you 
want as that
is part of your role, but you have to do it, and declare it on the list, 
or declare items as closed.

It will not matter who the editors are, if the chairs can not call consensus
when ever there is even one objection, no draft will ever get published.

I really am doing my best, but without the chairs calling consensus on 
*any* CAP
items, and without the chairs declaring any CAP debate or CAP action 
item *ever* as
closed in the last year (or more) the only way CAP will ship is when 
100% of the list agrees.
Simply saying 'I can not find where this was discussed' is not 
sanctioned reason
for me to change/edit/delete an item. And I am not the one that carries 
the burden
do disprove all claims.

--

---

From: [email-masked]
Date: Wed, 5 Nov 2003 10:31:49 -0500

Doug claimed on 11/04/2003 09:37:01 PM:
>                                                         And the same 
with
> to resolve issues, you (and others) did not respond. at all. 

This is patently false with respect to me.

I have responded privately to each and every email you have sent privately 
since Ive been on the WG with you (with the exception of some jokes you've 
sent).  There has not been a single message I did not receive that I did 
not respond to.  This is equally true for any private mail from other WG 
members.

While we may not see eye to eye at times, I do not slight anyone by 
ignoring them.  I at least have the courtesy to send back a response of 
some kind because I would expect the same treatement.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Wed, 5 Nov 2003 11:54:27 -0500

I appreciate your comments Doug.  However, Ned nor I ever stated it was ok 
to flood inbaskets with email in order to stop people from raising 
objections to items on the draft.  I admit fully that I should have 
stepped in much earlier and put a stop to it.  I know I did send out an 
email a while ago stating that we needed to keep the emails short and 
germaine to the issues.   Go to 
http://www.ietf.org/proceedings/03mar/index.html for a copy of the minutes 
from that meeting.  You will note that one of the things we talked about 
was closing the working group.  It's been kept open to try to update RFC 
2445, 2446 and 2447.  I've failed at getting an editor to work on these 
items.

In addition, I failed to do a good job at keeping the emails to a 
reasonable number.  I realize this now after trying to get through 48,000 
to look for concensus.  I have sent out emails pleading for a reduction in 
the amount of emails and the deluge.  I will formulate a note showing 
dates and times.  However, you bring up a valid point.  I did fail to stop 
the traffic.  Yet another good reason to get another chair.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
11/04/2003 20:59
Please respond to
[email-masked]

To
[email-masked]
cc

Subject
Re: Status of the CALSCH working group

deluge of mail,
with emails
one. 
 
me to get CAP out without changes unless they were OVERWHELMINGLY 
requested
 
In fact Ned directed you to not allow changes unless they were 
OVERWHELMING

 

 

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 05 Nov 2003 11:00:14 -0700

Then I have your permission to send the private email to this list?

--

---

From: Doug Royer <[email-masked]>
Date: Wed, 05 Nov 2003 11:15:10 -0700

[email-masked] wrote:

>
> I appreciate your comments Doug.  However, Ned nor I ever stated it 
> was ok to flood inbaskets with email in order to stop people from 
> raising objections to items on the draft. 

The word FLOOD was not used. The topic of answering each and every email 
was discussed
so that we did not keep getting those posts about questions not answered 
years earlier even
when the questions were not well researched. When no one answers those 
questions then
there is always someone saying 'hay this was not addressed' and we did 
discuss that
the only way to close those issues. Review the non-RECURRENCE-ID questions
since SF meeting. The vast majority were alreay in the draft when the email
was sent claiming the issue was not resolved.

Aside from the RECURRENCE-ID issue which went astray, who was going to
answer those questions posted?  And I have never sent email in order to 
stop anyone.
I have sent email in order to get people to research their questions 
first as it takes
time to research each question. And as you have observed on this list 
unanswered questions
can start a debate to solve an issue that was ether already covered in 
the draft or
never in the requirements.

We also discussed how you would declare old issues closed so that we 
could move on.
And then only reopen them if there was an overwhelming consensus. Please 
do so.

--

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 7 Nov 2003 11:48:18 -0500

> seasoned veteran of the IETF process to help move things forward.

Well, I guess this is my clue to stop lurking....  so I'll apologize in 
advance for the length of this message.

As many of you know, I have been coming up to speed on the CALSCH 
working group for several months now, and have expressed a willingness 
to try to help.  However, in the spirit of the Hippocratic oath -- 
"First, do no harm" -- I have been slow to volunteer for a particular 
role, but I am definitely ready to do so now.  However, I'd like to 
take a step back and point out where we are in the larger picture and 
where we need to go.

The current debates all center around one particular document, the CAP 
document, which Doug is struggling manfully to complete.  Completing 
the CAP draft would be a great thing, but let's not kid ourselves about 
where it leaves us:  the absolute best thing that can result from the 
current efforts is the publication of an RFC that *might* be approved 
as a Proposed Standard, thereby catching up to most of the rest of the 
calendaring-related documents, none of which, I believe, have gotten 
past that "first step" in the standardizations process.

There's still a long, long way to go, and I know that many of you are 
rather discouraged, given how long this project has been under way.  
Standards take a long time, and progress in calendaring and scheduling 
at the IETF has been particularly tortuous.  I know that some good 
people have simply burnt out along the way, and I'm not (deliberately) 
volunteering to be the next one.  I don't want to jump in without a 
path and plan to success, so I'm going to be a tad brutal in the next 
paragraph, though I intend no offense or disrespect to anyone who has 
been working on this challenging process.

It is my opinion that ALL of the CALSCH documents -- not just CAP -- 
need a lot of work.  A successful standard needs to be completely free 
of ambiguity.  You don't get there simply by tending to the most 
urgently yelled-about issues, you get there by comprehensively looking 
for ambiguities and using extremely clear, consistent, and conscious 
language for all of the specifications, especially with regard to the 
MUST/SHOULD/MAY kinds of language and the existence of a complete 
authoritative ABNF grammar of which the text is really only an 
elucidation.

If I'm right, getting CAP out the door could be a pyrrhic victory.  If 
it were up to me -- and I've been nominated to join the IAB, for 
whatever that's worth -- I don't think I could support advancing CAP to 
proposed standard as it stands, but I'm notoriously picky and wouldn't 
have supported moving several of the other documents to that stage, 
either, had I been involved at the time.  I want a lot more clarity and 
a lot less ambiguity, or we're going to start having proposed standards 
with incompatible implementations.  In any event, even if my 
requirements are too demanding for "Proposed" status, I predict that my 
concerns will be major problems later in moving the documents to Draft 
and Full standard status.  (For reference, it took us a long time to 
get MIME to Proposed status, but the process was *relatively* painless 
and mechanical from then on because there really weren't that many 
ambiguities left.)

Given this perspective, there's an argument to be made that the logical 
thing to do is to "finish" the CAP document (for some careful 
definition of "finish") and then open a whole new round of revisions to 
the CALSCH documents, including CAP.  I would be willing to serve as a 
document editor for such a round of revisions.  But in the meantime, we 
have to either put CAP to bed or put it on hold for a whole new round.  
One of the reasons I've been lurking quietly is that I had hoped to 
postpone my more active involvement until CAP was finished, but I now 
think that putting our recent discussion in the context of the larger 
needs of CALSCH might actually help us figure out how to finish CAP.

To put it in perspective:  The CAP document describes an early stage 
protocol with no functionally interoperating implementations (that I 
know of).  This means that it WILL have mistakes in it -- there's no 
substitute for building interoperable code for fleshing out those 
mistakes.  So we don't have to believe that CAP is perfect for us to 
sign off on it, because we know that it will simply provide a basis for 
further experiments toward the goal of a fully interoperable protocol.  
Remembering that perfection is not a requirement should be helpful.  
Instead of perfection, I think we should be pursuing a somewhat more 
modest goal, which is to identify and correct any deficiencies in the 
current CAP spec that can be reasonably anticipated to cause major 
headaches for that next round of standardization efforts.  It is my 
preference to confine my own comments on CAP to that category of 
problems that could significantly complicate the efforts that I am 
volunteering to help lead  for the next round of CALSCH document 
revisions.

Thus, with that ridiculous amount of prologue -- and with gratitude to 
anyone who has read this far -- I now offer my own opinions about what 
we need to fix to put this version of CAP to bed.  There are three 
things that I regard as *potential* showstoppers, though not difficult 
ones to fix:

Versioning:  The CAP-VERSION property as currently defined is simply 
not adequate to allow us the possibility of gracefully introducing 
incompatible changes in future versions.  As I contemplate an 
involvement in such future refinements, I can't imagine a more 
"showstopping" problem than this one.  FWIW, I speak from bitter 
experience:  for those of you who don't realize it, "MIME-Version" has 
an inadequate definition that almost certainly precludes *any* future 
values other than 1.0.  I would like to see CAP avoid the same mistake, 
as I think the cost would be much greater for CAP than it was for MIME.

CALSCALE -- I would like to either see us add a capability 
specification for calendar scales and a special error code for 
unsupported calendar scales, or I would like someone to convince me 
that the absence of such scales isn't really a problem for future 
extensions.  What we have right now tells us that there might be other 
calendar scales, but doesn't really tell an implementation how to 
behave if it encounters one.

ABNF -- There simply must be a complete ABNF for a standards-track 
protocol, in my opinion.  However, I'm also not convinced that 
releasing CAP as an Experimental RFC without such an ABNF would in any 
way impede CAP's progress in the market.  In fact, publication as an 
Experimental RFC might well be the smartest, fastest track for closure 
on the current document.  I could support publication as an 
experimental RFC if only my first two issues (CAP-VERSION and handling 
of unrecognized CALSCALE values) are resolved.

There are a couple of more things I would really like to see cleaned 
up, though I can imagine publication (especially as Experimental) 
without fixing them:

"SCOPING" -- The issue discussed as "SCOPING" on the list concerns me, 
but only as an easily-clarified ambiguity.  It seems that sometimes 
when you say "SELECT VALARM"  (or SELECT whatever), you want only the 
VALARM (or whatever), and sometimes you want the whole enclosing ical 
body, including the time zone, product-id, method, cal-scale, the whole 
kit and kaboodle.  I can understand -- barely -- why you might 
sometimes NOT want the enclosing stuff, but surely you often do want 
it, so either we need to be crystal clear that "everything" (properly 
defined) is to be returned, or we need to provide two forms of the 
request to get the two kinds of return.

VFREEBUSY -- I'm not sure that I'm up on all the details, but it seems 
to me that there are several ambiguities here.  I think that we must be 
clear about a requirement that servers MUST provide "currently 
accurate" freebusy information in response to an appropriate request.  
And I'm definitely confused about why one would want to permit the use 
of CREATE to create a VFREEBUSY entry, or why CAP doesn't just use the 
ITIP syntax for requesting this information.

Finally, there are a couple of things that I am still confused about 
after months on the list.  This doesn't necessarily mean there's a 
problem, but it certainly makes me nervous -- at the risk of sounding 
arrogant, if I haven't figured it out yet, I'm not optimistic that all 
implementors will "figure it out" in a compatible way:

EXPAND and QUERYID -- I am having a hard time understanding how stored 
queries can be useful without search wildcards.  Can anyone explain 
this to me?

Alarms/SEQUENCE -- I remain confused: Can there be two identical 
objects in the same calendar?  If not, we should clearly say so.

Anyway, I apologize for the length of this message and for its 
appearance at such a late pre-Minneapolis moment, but since Satya has 
honored me with the suggestion that I might be of help, I thought I 
should try to lay out my current thinking as clearly as possible.  I 
look forward to seeing as many as possible of you in Minneapolis!  -- 
Nathaniel

---

From: Doug Royer <[email-masked]>
Date: Fri, 07 Nov 2003 14:14:11 -0700

Thanks for the awesome feedback!

Nathaniel Borenstein wrote:

>     Would it be possible to get someone like Nathaniel Borenstein to
>     take the role of a co-editor (if he is interested)? It would help
>     to have a seasoned veteran of the IETF process to help move things
>     forward.
>
> ....
>
>

Yes. I agree.

> ...

>
> Given this perspective, there's an argument to be made that the 
> logical thing to do is to "finish" the CAP document (for some careful 
> definition of "finish") and then open a whole new round of revisions 
> to the CALSCH documents, including CAP. I would be willing to serve as 
> a document editor for such a round of revisions. But in the meantime, 
> we have to either put CAP to bed or put it on hold for a whole new 
> round. One of the reasons I've been lurking quietly is that I had 
> hoped to postpone my more active involvement until CAP was finished, 
> but I now think that putting our recent discussion in the context of 
> the larger needs of CALSCH might actually help us figure out how to 
> finish CAP. 

If CAP were to re-start (I would say not something to do), I think that 
the way to make progress
would be to break it up into (off of the top of my head);  general 
CMD/REPLY doc,
each specific CMD doc, and allow them ALL to be transported via iTIP so 
that the
transport (BEEP, TCP, HTTP,  iMIP, or whatever) can be independent of 
the overall design.

> ....

Currently the iCAL 'VERSION' property of iCAL has the same problem as 
MIME-Version.

However the  CAP-VERSION is more ~like~ the telnet capability in that 
you can list the specific
CAP-ish things. It is not a VERSION as much as a list of docs the CS (or 
CUA) supports.

So I do not think it has the same problem as the MIME-Version and iCAL 
VERSION properties.
If we were to change it to be like the iCAL VERSION property (as some 
have recently
almost proposed) - then it would have the same problem as the 
MIME-Version issue.

> behave if it encounters one.

iCAL can do a 'REQUEST-STATUS:3.1;Invalid property value;CALSCALE:foo' 
now and
seems the correct choice for an unknown CALSCALE.

Until someone proposes a new CALSCALE I do not think we can pre-specify 
any behavior.

Currently there is no way to specify in a request the desired CALSCALE. Easy
to add, but not something that can break existing CUA's. We could add 
text that
says something like 'if you get a CALSCALE that you can not handle in 
the CAPABILITY
reply, drop the connection as you can not do anything anyway...' . 
However that
is true of (and the point of) the CAPABILITY reply, to find out if you can
interoperate.

> ABNF -- ...

> body, including the time zone, product-id, method, cal-scale, the 
> whole kit and kaboodle. I can understand -- barely -- why you might 

Thanks for the succinct explanation. As no one has proposed any 
solutions, I'll see
if I can send some ideas to the list to clarify the text.

> ITIP syntax for requesting this information.

Because some want and expect the CU (user) VFREEBUSY and others want the
CALID (calendar) VFREEBUSY. Currently the iTIP method gets the CU VFREEBUSY
that just might be the same as the CALID VFREEBUSY.

> this to me? We dropped the ability to auto execute stored queries.

There is NO restriction that the results of fetching a stored query 
return static results (the
 same is true for all components) . So I could define (using unspecified 
admin tools) a stored
query called 'TODAY' that returns a dynamically returns a VQUERY when
run returns the results of todays events from several calendars.

When we had auto-execute, then you could run them without fetching
them. Now you have to fetch them and then run them (I still do not see 
why that is better).
All of my requests for such an explanation have been ignored by those 
that do not want
the CS to be able to have builtin, stored, or dynamically created 
queries. PDAs and
devices on low bandwidth or high latency connections need this feature.

> objects in the same calendar? If not, we should clearly say so.

You can and iCAL has no such restriction on any component including VALARMs.
Currently all components have a unique identifier within their context 
of usage.
Some want no unique identifier, and their stated reasons specifically 
ignores the
identical components issue.

> look forward to seeing as many as possible of you in Minneapolis! -- 

I wish I could make it, I had planned on it, too much work,..
I'll be on Jabber.

Thanks again for your succinct questions.

--

---

From: John Stracke <[email-masked]>
Date: Fri, 07 Nov 2003 16:30:39 -0500

Doug Royer wrote:

>> EXPAND and QUERYID -- I am having a hard time understanding how 
>> stored queries can be useful without search wildcards. Can anyone 
>> explain this to me? We dropped the ability to auto execute stored 
>> queries.
>
>
> same is true for all components) . So I could define (using 
> unspecified admin tools) a stored

It basically democratizes the process of developing noninteroperable 
extensions: if your CS has these unspecified tools, then any admin can 
add new verbs to the protocol, and a CUA has to hope that the user knows 
what the stored query's name means.

-- 
/===============================================================\
|John Stracke      [email-masked]                        |
|Principal Engineer|http://www.centive.com                      |
|Centive           |My opinions are my own.                     |
|===============================================================|
|Any sufficiently rigged demo is indistinguishable from advanced|
|technology.                                                    |
\===============================================================/

---

From: Doug Royer <[email-masked]>
Date: Fri, 07 Nov 2003 17:18:20 -0700

John Stracke wrote:

> add new verbs to the protocol, and a CUA has to hope that the user 
> knows what the stored query's name means. 

By admin I did not mean that the user is not the admin of their own 
calendar. I just
meant non-cap unspecified tool, much like we allow for a non-cap unspecified
tool to create immutable vcars.

And by your same logic a non-owner admin could change all of the VEVENT 
UID's
in your calendar breaking you -- and just as unlikely.

--

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 7 Nov 2003 20:27:34 -0500

On Friday, November 7, 2003, at 04:14  PM, Doug Royer wrote:

> CAP-ish things. It is not a VERSION as much as a list of docs the CS 
> (or CUA) supports.
>

I remain confused as to the purpose of CAP-VERSION, and will take the 
liberty of asking a dumb question or two.

First, as far as I can tell, the only example of its use is in a CUA's 
response to a GET-CAPABILITY command issued by a CS.  Is there any 
other scenario where it is used?  If so, what is it?  If not, how does 
a CUA find out what CAP-VERSION is supported by the CS?  How do the 
values for CAP-Version relate to the ical Version?  Moreover, what does 
it mean for a CUA to say that it supports multiple CAP-VERSION values?  
  For example, if in the fullness of time we have defined cap-versions 
"1.0" and "2.0", is it reasonable to imagine that a CUA returns

CAP-VERSION:  1.0; 2.0 (alpha); 2.0 (beta)

In this case, first please pardon my semicolon -- although Doug 
referred to CAP-VERSION as multivalued, I couldn't find any indication 
of what the separator should be so I made that up.  Second, does this 
mean that the CUA is prepared to take data in a form labelled simply 
"2.0" or not?   What if 1.0 and 2.0 actually have incompatible 
semantics for identical syntax -- how is the CUA supposed to know what 
it is seeing?   Finally, why are we using version numbers like 1.0 -- 
is there an intended implication about how an implementation should 
handle unrecognized version numbers, such as "ignore minor version 
differences but insist on major version compatibility"?  If so, we 
should spell it out, and if not, we should dispense with the frivolity 
of using "1.0" when "1" would carry no less information.

I'm sure some of these are stupid questions, but I suspect at least 
some of them are meaningful.

I know that it would be nice if I now made a proposal for how things 
*should* work, but I'm reluctant to do so before I understand the 
purpose of CAP-VERSION.  Here are several possible purposes:

-- Allowing the CUA to find out what version of the CAP protocol the CS 
supports.
-- Allowing the CS to find out what version of the CAP protocol the CUA 
supports.
-- Allowing the CUA to find out what iCal "Version" fields the CS 
supports.
-- Allowing the CS to find out what iCal "Version" fields the CUA 
supports.

Even if I did understand the purpose of CAP-VERSION, I'd still want to 
be sure that there's a way to tell which of the supported CAP-VERSIONs 
is actually being used.  If I tell you I support 1.0 and 2.0, and you 
come back at me with a verb that has different meanings in the two 
versions, how do I know which you're using?

This is the kind of stuff I most want to see us fix before we declare 
the document finished, because getting this wrong will make it much 
harder to fix anything else later.  One of the reasons that 
MIME-Version didn't turn out to be a major problem is that document 
formats are relatively stable and rarely require negotiation.  
Information exchange protocols, however, often involve version 
negotiation, so the costs of screwing this up could be significant.  -- 
Nathaniel

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 7 Nov 2003 20:57:13 -0500

> identical components issue.

But what does this mean?  If you store two identical items in your 
database without any unique identifiers, how can a client ever choose 
one over the other?  I'm having a hard time seeing how this is a good 
idea.  -- Nathaniel

---

From: Doug Royer <[email-masked]>
Date: Fri, 07 Nov 2003 22:30:46 -0700

Nathaniel Borenstein wrote:

>         Alarms/SEQUENCE -- I remain confused: Can there be two
>         identical objects in the same calendar? If not, we should
>         clearly say so.
>
>
>     Currently all components have a unique identifier within their
>     context of usage.
>     Some want no unique identifier, and their stated reasons
>     specifically ignores the
I agree, they need unique id's.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 07 Nov 2003 22:27:54 -0700

Nathaniel Borenstein wrote:

>> So I do not think it has the same problem as the MIME-Version and 
>> iCAL VERSION properties.
> other scenario where it is used?

Correct, that is the only time it is used.

> If so, what is it?  If not, how does a CUA find out what CAP-VERSION 
> is supported by the CS?  How do the values for CAP-Version relate to 
> the ical Version?

They do not relate to the iCal VERSION directly. It just happens that 
CAP uses iCal
file format '2.0' (iCAL VERSION).

> Moreover, what does it mean for a CUA to say that it supports multiple 
> CAP-VERSION values?   For example, if in the fullness of time we have 
> defined cap-versions "1.0" and "2.0", is it reasonable to imagine that 
> a CUA returns
>
> referred to CAP-VERSION as multivalued,

iCAL VERSION 2.0 separates multivalued property text items with a COMMA.
See RFC 2445.

> I couldn't find any indication of what the separator should be so I 
> made that up.  Second, does this mean that the CUA is prepared to take 
> data in a form labelled simply "2.0" or not?   What if 1.0 and 2.0 
> actually have incompatible semantics for identical syntax -- how is 
> the CUA supposed to know what it is seeing?

Per cap the value(s) is(are) the RFC number of the CAP protocol that the 
endpoint
that sent the reply supports. If CS advertised incompatible versions of 
something then
it would be hosing itself.

> -- Allowing the CUA to find out what version of the CAP protocol the 
> CS supports. 

Look at the values the CS sends to the CUA in the CAP-VERSION property
in the GET-CAPABILITY reply.

> -- Allowing the CS to find out what version of the CAP protocol the 
> CUA supports. 

Look at the values the CUA sends to the CS in the CAP-VERSION property
in the GET-CAPABILITY reply.

Each end sends a GET-CAPABILITY to the other endpoint and
gets back a set of properties (with values).

> -- Allowing the CS to find out what iCal "Version" fields the CUA 

So far only iCAL version 2.0 exists and RFC's 2446, 2447, and CAP specify
iCAL as in 2445 (which means 2.0).

If CAP-other-version were to come out, it would need to specify the iCAL 
version.
Plus the iCal objects themselves are tagged with the iCAL VERSION.

> versions, how do I know which you're using? 

Given:
   
    CAP-VERSION:1234,5678

Then it means the sending endpoint supports CAP as defined in RFC-1234 
and RFC-5678

> negotiation, so the costs of screwing this up could be significant.  
> -- Nathaniel

--

---

From: [email-masked]
Date: Mon, 10 Nov 2003 09:53:57 -0500

> Currently the iCAL 'VERSION' property of iCAL has the same problem as 

I dont recall seeing any previous WG postings regarding problems with 
iCalendars versioning design.  In any case the topic is CAPs CAP-VERSION 
and its current design.

> CUA) supports.

CAP defines CAP-VERSION as:

   Purpose: This property specifies the version of CAP supported.

and iCalendar defined VERSION as:

   Purpose: This property specifies the identifier corresponding to the
   highest version number or the minimum and maximum range of the
   iCalendar specification that is required in order to interpret the
   iCalendar object.

Unfortunately CAP does not say much more on the topic of using versions 
which means there is no clearly defined behaviour or expectations for CAP 
1.0 implementations to follow in a consistant manner.

Currently it is not a list of supported versions of CAP, it is a single 
valued property with no clearly defined behaviour for going forward.  The 
issue of the "1.0" (pre-July 2003) vs "XXXX" RFC number (~July 2003) value 
change is secondary to the funcational questions of it.

> So I do not think it has the same problem as the MIME-Version and iCAL 

The problem is compound:

1: The property is currently single valued, not multivalued.
2: The property has no clear definition of dealing with multiple values 
(ie: what is the expected or recommended behaviour if multiple values are 
found).
3: Is there any priority assumed by the ordering of multiple values.
4: If there is a disjoin between each sides supported version, what then?

I think I had one other but thats enough to get some discussion going (I 
hope).

iCalendars VERSION does not share these problems nor is it relevant to 
this CAP discussion.

> almost proposed) - then it would have the same problem as the 

You misread/misunderstood the 1st question on that topic that I asked even 
after I rephrased it.  Please go reread it and see if its clearer...  (The 
point about "numeric" formatting was due to the previous CAP versions 
using "1.0" vs the apparently undiscussed recent change to "XXXX", NOT a 
proposal of any kind.)

Bruce

---

From: [email-masked]
Date: Mon, 10 Nov 2003 10:41:18 -0500

> seems the correct choice for an unknown CALSCALE.

That is the incorrect value to return for REQUEST-STATUS.  CALSCALE is NOT 
invalid!  The property is 100% legal on nearly all messages or components 
where a new calendar would use it (ie: for VCARs "Invalid Property" would 
be correct but on new VEVENTS is is _valid_).  The real 'error' is that 
the property _value_ is not supported by the recipient.  There is a big 
difference!

Unfortunately the new REQUEST-STATUS codes (Section 10.15 Response Codes) 
are not well organized so its hard to tell exactly what should be sent 
back.  Section 10.15 should define a class of "5.xx" values generically 
and then fill in as needed.  Unfortunately CAP defines some 6.x examples 
without clearly defining what the 6.xx class actually is (iTIP added the 
5.xx class but we didnt define it in iCalendar).  The same goes for 7.xx 
thru 10.xx classes.  Heck, CAP decided 10.xx was so important that it 
skipped 10.0 thru 10.3 and started off with 10.4. 

A while back the issue of defining the classes was raised and Doug took 
the task of reorganziing the REQUEST-STATUS values to be more hierarchical 
rather than flat.  After all why do we need 5 new root level classes of 
errors when we havent even defined them. 

In response to a CALSCALE:Foo property I would think the CS would send 
back a:

REQUEST-STATUS:3.13;Unsupported component or property found;CALSCALE\:Foo 
is unknown

3.13 is defined in iTIP and since iCalendar defined CALSCALE as:

     calscale   = "CALSCALE" calparam ":" calvalue CRLF

     calparam   = *(";" xparam)

     calvalue   = "GREGORIAN" / iana-token

the CALSCALE:Foo example _IS_ valid since Foo would be classed as an 
iana-token.  It may not be a known token but it is one so "Foo" is NOT 
invalid, its UNKNOWN.  There is a distinct difference.

> Until someone proposes a new CALSCALE I do not think we can pre-specify 

Specifying no behaiviour is likely to get us into the same predicament as 
we found ourselves in with multiplart MIME in iCalendar.  iCalendar didnt 
directly address it nor did iTIP or iMIP so some CUAs do not support 
iCalendar/iTIP if its NOT the sole MIME body part in a message.  Playing 
osterich is never good; expectations should be clearly descirbed so the 
path going forward is not left to the imagination.

> Currently there is no way to specify in a request the desired CALSCALE. 

Um, unless you removed CALSCALE from the payload there certainly is.  Any 
CUA can put in CALSCALE:JAILAI in a REQUEST is sends; thats part of 
iCalendar & iTIP and thus it better be in CAP too.

> Easy
> to add, but not something that can break existing CUA's. 

We are talking about how CAP CUAs should be built.  Currently since CAP is 
not done there are no CAP CUAs or CSs out there to worry about breaking. 
Currently iCalendar/iTIP have a defined mechanism for conveying CALSCALE. 
CAP has it too but its NOT clear how each side in the CS / CUA model 
should behave in some cases when determining supported abilities.  Thats 
the ponit of this discussion I think; to codify the behaviour so that 
future changes or updates will have a predictable outcome with older 
implementations.

>                                                            We could add 

If you find the other side supports no CALSCALE values that you do, what 
can you do?  Do you ignore it and try to send stuff in an unsupported 
CALSCALE?  Or do you fail gracefully and notify the CU?  Or something 
else?  What should a CAP implementation do when someone ignores CALSCALE 
settings and tries to send something it may not be able to support?  We 
have no defined course of action or value for REQUEST-STATUS.

CAP currently says NOTHING on the subject and I think that is a mistake. 
Sure, there are no current proposals for any new scales now but that is no 
reason to not take a few minutes to precisely define the expected 
behaviour going forward.  Tim suggestion has merit even if we have nothing 
on the table now.  The blanks in CAP regarding this should be filled in so 
its not left to future debate over the correct course of action when faced 
with an unknown CALSCALE will be necessary.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Sun, 09 Nov 2003 13:57:53 -0700

Nathaniel Borenstein wrote:
>           Alarms/SEQUENCE -- I remain confused: Can there be two identical objects in the same calendar? If not, we should clearly say so.
> 
>      Currently all components have a unique identifier within their context of usage.
>      Some want no unique identifier, and their stated reasons specifically ignores the
> But what does this mean? If you store two identical items in your database
> without any unique identifiers, how can a client ever choose one over
> the other? I'm having a hard time seeing how this is a good idea. -- Nathaniel

On my PDA the default entry is audio alarm. I have often accidentally
created two audio alarms when I really wanted one audio and one pager
(email) alarm. Then had to go back and fix them later when the
two alarms go off which when I notice that I made the mistake.

If CAP did not allow me to fixed them I have to throw away
the entire VEVENT and start over? I hope not.

VALARMS need a unique identifier. Think about it, the topic is
why would you need to uniquely identify a VALARM in a MODIFY command.
One answer is to fix a problem.

---

From: [email-masked]
Date: Mon, 10 Nov 2003 12:02:28 -0500

> that just might be the same as the CALID VFREEBUSY.

We have never drawn a distinction between a CUs availability or a 
calendars before.  Are you saying you have some proposal in mind for 
drawing a distinction?  Something like hierarchical calendars with 
busytime / content rollup or "calendar bundling"?  Please say no...

CUs like to schedule with other CUs, not with an abstract 'calendar'; I 
want to meet with Bob, not with a calendar that Bob is an owner or 
co-owner of or one that Bob has no actual association with but he gave me 
the RelCALID for.  iTIP defined busytime in terms of user interactions 
because that's how people work.  In CAP, the behavior should be the same. 
To this end CUs are more likely to be targeting the either a particular CU 
by name or the calFBURL (RFC 2739) for that CU rather than any arbitrary 
calendar that may be associated somehow to the CU. 

Early on we had the implicit assumption that each CU had a default 
calendar where they did their C&S and so a busytime check of that calendar 
would reflect that users availability; we did not model things such that 
the users availability was spread out across potentially dozens of 
calendars.  Just like a user does not keep their 'calendar' in separated 
out across a paper Dayrunner (TM) , a PDA calendar, Voice Mail messages 
(phone tag arranging) and other non-interlinked sources simply because its 
not convenient and its easy to miss entries.  Trying to draw distinctions 
beyond how people work in ill-fitting ways is a recipe for disaster and 
confusion.  (RFC 2739 provides calOtherFBURLs for those users who want to 
have multiple sources but they are not the 'primary' source that calFBURL 
defines...)

Also, busytime should be reflective of the contents of the particular 
target.   A CUA should not be allowed to arbitrary monkey with the 
VFREEBUSY data that the CS would return so that it is not reflective of 
the calendar it is associated with.  Otherwise when someone does a 
busytime lookup they see that the target is available from 10AM-11AM today 
when in fact they are in a meeting which has TRANSP:OPAQUE which defeats 
the usefulness of busytime AND violates the definition of TRANSP 
(iCalendar, Section 4.8.2.7 Time Transparency).

Bruce

---

From: [email-masked]
Date: Mon, 10 Nov 2003 13:16:54 -0500

> run returns the results of todays events from several calendars.

A: There were several questions regarding the usefulness and behaviour of 
stored queries so the WG (except for Doug) decided to defer the entire 
concept to post CAP 1.0 so they could be adequately addressed.

B: The original intent was to make it easier for 'thin' clients to do 
normal queries and save them bandwidth and memory footprints.  However we 
never actually had wildcarding in the language (or we lost it at some 
point) so we failed to fulfil the original intent.

C: Anyone can provide a stored VQUERY on their implementation (as an 
extension to CAP 1.0).  Any CUA should be able to retrieve it using CAP 
1.0 by simply SEARCHing for the QUERYID:TODAY and the CS should return it. 
 Unfortunately there is nothing in the CAP 1.0 spec that would be able to 
do this since "today" is a concept that is not encodable using the current 
query linga.  As such doing what Doug suggested results in a VQUERY that 
exists in the CS that can be referenced by using QUERYID but that is NOT 
retrievable by the CUA.  This means that the user has NO way to know what 
query "TODAY" is (and its worse if the CS is in a different TZ than the 
user so they can be in different days when the query is run!).  Plus, it 
is not safe for CUAs to assume or use canned 'special' queries that are 
not retrievable.  Product A's "TODAY" query may be different from Product 
B's "TODAY" so mixing CUAs and CSs could have incorrect results.

> them. Now you have to fetch them and then run them (I still do not see 

You dont have to fetch them and then send them back, you simply craft them 
locally and send them.  Its also been demonstrated that the savings in 
octets is minimal (~50-60 I think) so making ALL CS's implement stored 
queries is something I find questionable.  Also, just how would someone 
using your CUA that wants to use the stored "TODAY" query work when 
talking with someone elses CS that does not support stored queries?  It 
would have to construct the query itself and the just send it to the CS.

Given the CAP 1.0 query language we have, the CUA must rewrite nearly all 
queries related to frequently performed operations (ie: What alarms 
trigger in the next 15 minutes? What entries are on my calendar for Today? 
etc) so what benefit there may be to stored queries is offset to the 
degree that the CUA has to rewrite the query and resave it.

> devices on low bandwidth or high latency connections need this feature.

Unless all CUAs (thin and fat) have the same fixed list of stored queries 
that do things that are NOT representable in CAP-Query Language, there is 
little if any demonstratable savings in keeping stored queries for CAP 1.0 
as they were defined. 

You also neglect to factor in the need of the thin clients to have to 
rewrite stored queries to keep them accurate (ie: rewrite the bounds of 
the alarm TRIGGER check every 15 minutes). 

In addition I see no benefit in relying on remotely stored queries that 
are not currently encodable in our query language thus unrepresentable in 
response to this simple SEARCH:

      C: Content-Type: text/calendar
      C:
      C: BEGIN:VCALENDAR
      C: VERSION:2.0
      C: PRODID:-//someone's prodid
      C: CMD:SEARCH
      C: TARGET:relcal1
      C: BEGIN:VQUERY
      C: QUERY:SELECT * FROM VQUERY
      C:  WHERE QUERYID >= 'TODAY'
      C: END:VQUERY
      C: END:VCALENDAR

that are ~product specific and thus non-interoperable (or even in 
conflict).

Bruce

---

From: [email-masked]
Date: Mon, 10 Nov 2003 13:21:37 -0500

> devices on low bandwidth or high latency connections need this feature.

To date I have not heard a response from Doug or anyone who can answer my 
question about EXPAND.  It was a simple question but there seems to be 
reluctance to answer it.  So Ill ask again...

With regards to EXPAND, is the CS supposed to return literally all 
instances of a repeating entry even if they fall outside the bounds of the 
parameters in the VQUERY or is the stated intention of EXPAND incorrectly 
/ poorly phrase?

Bruce

---

From: [email-masked]
Date: Mon, 10 Nov 2003 13:43:13 -0500

> You can and iCAL has no such restriction on any component including 
VALARMs.

Sorry, iCalendar does state that multiple repeat instances at the same 
date/time are to be considered one:

                                                          Where
   duplicate instances are generated by the "RRULE" and "RDATE"
   properties, only one recurrence is considered. Duplicate instances
   are ignored.

at least 4 times.  There is also :

   4.  When the combination of the "RRULE" and "RDATE" properties on an
       iCalendar object produces multiple instances having the same
       start date/time, they should be collapsed to, and considered as,
       a single instance.

in case you missed the other occurances. 

You also expliclty restrictions in CAP with:

   There MUST NOT BE more than one "BOOKED" state object in a calendar
   for the same "UID". The "ADD" method value may create multiple
   objects all in the "BOOKED" state for the same UID, however for the
   purpose of this memo, they are the same object that simply have
   multiple "VCALENDAR" components.

Essentially this says that there can not be any identical VEVENTS with the 
same identifier that are BOOKD.  Its interesting to note that CAP 
disallows it with "MUST NOT" but then goes on to say "may".   The first 
line was correct, the later text removes the restriction of sorts and is 
bad.

I have yet to hear any good justification for allowing "identical but 
separate" VALARMs that match any practical view of things.  Despite Dougs 
and Marks claim, the only reason to have SEQUENCE (or ALARMID) on VALARMs 
is for this rare usage case that currently noone actually has nor models 
anyones actual behaviour or needs.  Id like to apply KISS to this and move 
CAP along...  (Just like we disallow multiple copies of the same booked 
entry, the same should go for alarms).

> Currently all components have a unique identifier within their context 

Not totally true.  An example of this is VDAYLIGHTs and VSTANDARDs in a 
VTIMEZONE.  The TZID of the VTIMEZONE is unique but the TZNAME (akin to 
its identifier) is not unique.  In fact the correct VDAYLIGHT/VSTANDARD is 
found by selecting the subcomponent criteria that meet the requestors 
needs (ie: when its in effect).

The ONLY case that seems to be demonstratable for SEQUENCE (nay, ALARMID) 
is the case where there are multiple, identical VALARMs whose existance is 
somewhat questionable, at least for me.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Nov 2003 12:44:10 -0700

[email-masked] wrote:

> stored
> A: There were several questions regarding the usefulness and behaviour 
> of stored queries so the WG (except for Doug) decided to defer the 
> entire concept to post CAP 1.0 so they could be adequately addressed. 

And they were.

> normal queries and save them bandwidth and memory footprints.  However 
> we never actually had wildcarding in the language (or we lost it at 
> some point) so we failed to fulfil the original intent. 

As pointed out on the list bandwidth limiting is not nessasasarly tied 
to wildcards.

--

---

From: [email-masked]
Date: Mon, 10 Nov 2003 14:44:03 -0500

> the entire VEVENT and start over? I hope not.

Unless they are exactly the same then identifying the one you want to 
remove is trivial.  Also, if VALARMs were treated like VEVENTs:

   for the same "UID".

and later:

                                                    If a duplicate
   [iTIP] object is deposited into the CS and there exists identical
   marked for delete objects, then a CUA acting on behalf of the "OWNER"
   can silently drop those duplicate entries.

then you'd never have this problem since the duplicate AUDIO alarm would 
not be created to begin with.  Im assuming its duplicate even though you 
did not actually say this.

> One answer is to fix a problem.

The ONLY reason a VALARM would need to have a unique identifier is if we 
allowed exact duplicate VALARMs (a questionable decision given the other 
prohibitions in iCalendar and CAP and the usage scenarios for it).  I have 
already shown that the MODIFY command does NOT need to include any 
identifier in order to modify a particular VALARM; the CUA simply needs to 
send enough VALARM properties to uniquely identify the VALARM in question.

If we do decide that we want to allow duplicate VALARMs per component then 
more questions arise.  Other related questions related to addition to 
iCalendar include:

1: If there is no ALARMID / SEQUENCE property on a VALARM, does the CUA 
need to assign one?  An example of this is an entry that is created 
outside of CAP and delivered to the CU.

2: If the ALARMID / SEQUENCE property can be locally assigned for entries 
that originate elsewhere then are they preserved when the entry is sent to 
someone else (ie: The CU delegates the VEVENT)? 

3: Just how is the fact that the VALARM is NOT "local" to the CU (ie: it 
came with the REQUEST) but the ALARMID / SEQUENCE value IS "local" 
tracked?  Do we now have to add a new property parameter to ALARMID / 
SEQUENCE to track this too?

4: If exact duplicate VALARMs are 'legal' then how do we resolve the case 
where the sender included multiple exact duplicates with no ALARMID / 
SEQUENCE?  There is no way to initially distinguish between the two so a 
MODIFY command MUST fail by:

                                                                  If
   the CS can not find a component that matches the QUERY and does not
   have at least all of the OLD-VALUES, then a 6.1 error is returned.

because there was no unique match on all the old-values.  Catch-22.  The 
simpler solution is to prohibit exact duplicate VALARMs on any particular 
component and all the problems or questions can go away.

Bruce

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:07:21 -0700

[email-masked] wrote:

> instances of a repeating entry even if they fall outside the bounds of
> the parameters in the VQUERY or is the stated intention of EXPAND
> incorrectly / poorly phrase?

Yes - return unlimited instances until you servers crashe.
Did you really need an answer?

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:06:05 -0700

> entire concept to post CAP 1.0 so they could be adequately addressed.

No, you simply bullied the list into droping auto executed queries.
Re-read the archives.

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:03:58 -0700

> busytime / content rollup or "calendar bundling"?  Please say no...

So what - what he said is still true. Currently MANY systems
PUBLISH freebusy, including the big vendor - please say you
do not want to break them!!!

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:09:48 -0700

> date/time are to be considered one:

What does that have to do with the topic or the email asked or answered?
Nothing at all.

Do you even follow the topics before posting?

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:11:06 -0700

> remove is trivial.  Also, if VALARMs were treated like VEVENTs:

Again - did you read the topic and email before posting?
That WAS the topic - them being the same.

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 13:01:17 -0700

[email-masked] wrote:

> 
> Unfortunately CAP does not say much more on the topic of using
> versions which means there is no clearly defined behaviour or
> expectations for CAP 1.0 implementations to follow in a consistant
> manner.

Again you must be reading a version of CAP with text missing.
Try re-downloading the version that explains it.

> Currently it is not a list of supported versions of CAP, it is a
> single valued property with no clearly defined behaviour for going
> forward.  The issue of the "1.0" (pre-July 2003) vs "XXXX" RFC number
> (~July 2003) value change is secondary to the funcational questions of
> it.

Again you must have missed the text that calles it multivalued.
> iCAL

Not true == please read CAP before posting.

> 2: The property has no clear definition of dealing with multiple
> values (ie: what is the expected or recommended behaviour if multiple
> values are found).

Not true == please read CAP before posting.

---

From: Satya Vempati <[email-masked]>
Date: Mon, 10 Nov 2003 12:52:47 -0800

I would like to suggest that everyone should make a conscious effort to
keep the discussion productive and not give way to acrimony. We need to
keep in mind that these archives have to be of some use to people who,
in future, browse them for information and answers.

Most of the recent posts are nothing but invective and as such should
not posted to a technical public forum such as this one.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Monday, November 10, 2003 12:10 PM
To: [email-masked]
Subject: Re: Status of the CALSCH working group (Alarms/SEQUENCE)

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 14:26:21 -0700

>    There MUST NOT BE more than one "BOOKED" state object in a calendar

Do you bother reading this email? The topic is multiple VALARMS
in one VEVENT, not multiple VEVENTS.

---

From: [email-masked]
Date: Mon, 10 Nov 2003 16:32:59 -0500

> do not want to break them!!!

In case you've never actually used their product, the model is that the 
entire process is user centric, not some abstract calendar that can be 
linked but to someone but not necessarily the contents of that calendar. 
They use a single calendar model and their CUA pushes the busytime out as 
necessary to a configured place.  The "contacts" have a URL where the 
client can go get busytime data for a particular contact w/o doing any 
actual iTIP REQUEST/REPLY.  So are you are proposing we change CAP and 
iTIP to follow their direct access model of busytime?

Busytime is UPN or CU focused and in RFC 2739 we defined a couple URI to 
use in protocols like CAP for doing busytime query for users.  Doug 
sounded like he had a different model of busytime but didnt quite say so 
(nor has he clarified yet).  In any case, the format of the query can 
still be iTIP but query is done via the capFBURL rather than a email 
address in an iMIP message.  Thats why Frank defined those properties in 
2739 for us...

Are you suggesting we make busytime relcalid focused and not user 
focused??

Bruce

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 14:53:57 -0700

> not posted to a technical public forum such as this one.

I would like to suggest that whoever has control of this list
some how suspend Bruce and what I believe to be his intentional
misleading posts to this list. He repeatatly attempts to insite
debate by posting false statements, inaccurate inforamtion and
general trolling for trouble.

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 14:55:53 -0700

[email-masked] wrote:
> In case you've never actually used their product, the model is that
> the entire process is user centric, not some abstract calendar that
> can be linked but to someone but not necessarily the contents of that
> calendar.  They use a single calendar model and their CUA pushes the
> busytime out as necessary to a configured place.  The "contacts" have
> a URL where the client can go get busytime data for a particular
> contact w/o doing any actual iTIP REQUEST/REPLY.  So are you are
> proposing we change CAP and iTIP to follow their direct access model
> of busytime?

I have see no text in CAP that stops auto create and auto
reply of vfreebysy from working.

And I have not seen even you dispute that the user busytime is
not always the same as the calender busy time. Can you
explain why you insist that all implementations that publish
a user vfreebusy that is different that the calendar vfreebusy
must break so that CAP fits your desired model?

No I am repeating that it is the user busytime and not the calendar
busytime has he has pointed out. And case you have not actuall used
their product you may notice that the user can block out time
that is not in the calender. Thus user busytime is not always the same
as calendar busy time.

In fact making the CS always auto create vfreebusy times is what
changes the model. The existing CAP text allows the existing
implementations and models that publish vfreebusy to continute
to work. And CAP-12-newest does allow auto create to work and
it does not break implementations that use publish to manually
set the users vfreebusy time.

Why do you keep insisting that if someone disagrees with you they
do not understand? Looking through the archives I have found many
instances of people talking about wanting to block out time that
is not in the calendar. Example: There was (a long time ago) in the
archives a debate to include include work schedules, which
seems to have been droped specificaly because the vfreebusy time
does not have to equal the calendar vfreebusy time. The work
schedule components were ruled redundent as you could simply
publish busy time that was not in your calendar. This is true of ITIP
why do you insist that it can not be true in CAP?

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Nov 2003 14:59:56 -0700

I have updated my internet connection. Somehow I seem to be missing posts.
They are in the archive, yet my server shows no record of them being sent
to my SMTP server. Some posts are making it, others are not. Perhaps
some are Cc'ing or Bcc'ing me and others are not.

I may have to be copy/paste from the IMC server until I find the problem...

--

---

From: [email-masked]
Date: Mon, 10 Nov 2003 17:09:04 -0500

At the risk of incurring yet more grief, I'm going to second the comments 
of Satya.  He said it well - we need to keep the comments to the issues. 

I think Bruce tries hard to read the emails and post accordingly.  I 
believe he is not trying to "incite" debate - he's trying to get people to 
see the real issue.  That's his speciality - knawing at an issue until we 
all see how it should be.  And he is the first to say he understands an 
issue if he has been viewing it incorrectly or differently.

And while my note may appear like I am endorsing Bruce,  in reading back 
over his comments, it does indeed appear he is reading the posts.  What, 
in fact, is surfacing, though, is that whenever he does choose to post, 
you go out of your way to comment on his statements.  So, rather than 
asking Bruce to "suspend" his actions, it is rather better for the list to 
ask you to stay focused on the topic, and read the emails yourself. Please 
stop making the accusations and comments regarding Bruce's posts.  The 
fact that Bruce is able to continue posting in spite of your comments is a 
point in his favor.

Mark Smith <[email-masked]> 
Sent by: [email-masked]
11/10/2003 16:53

To
[email-masked]
cc

Subject
Re: Status of the CALSCH working group (Alarms/SEQUENCE)

---

From: [email-masked]
Date: Mon, 10 Nov 2003 17:13:00 -0500

> Do you even follow the topics before posting?

Normally I would not respond to this kind of trolling but Ill give you the 
benefit of the doubt and chalk this up to ignorance rather than malice. 
Nathaniel wrote:

to which Doug replied:

You can and iCAL has no such restriction on any component including 
VALARMs.

to which I pointed out that he was incorrect.  iCalendar has at least 5 
places where it says duplicates are to be treated as a single instance.  I 
then pointed out that CAP also has text to this effect.  So my reply was 
on topic just like the last time you said it wasnt.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 10 Nov 2003 15:23:01 -0700

(copy from archive)
------------------------------------------------------------------------

    * To: "ietf-calendar@xxxxxxx <mailto:[email-masked]>"
      <ietf-calendar@xxxxxxx <mailto:[email-masked]>>
    * Subject: Re: Status of the CALSCH working group (CALSCALE)
    * From: Bruce_Kahn@xxxxxxxxxxxxxxxx <mailto:[email-masked]>
    * Date: Mon, 10 Nov 2003 10:41:18 -0500
    * In-reply-to: <>
    * List-archive: <http://www.imc.org/ietf-calendar/mail-archive/>
    * List-id: <ietf-calendar.imc.org>
    * List-unsubscribe:
      <mailto:[email-masked]?body=unsubscribe>
    * Sender: owner-ietf-calendar@xxxxxxxxxxxx
      <mailto:[email-masked]>

------------------------------------------------------------------------

...

 > In response to a CALSCALE:Foo property I would think the CS would 
send back a:
 >  ...REQUEST-STATUS:3.13;Unsupported component or property 
found;CALSCALE\:Foo is unknown.

 > ...Unfortunately the new REQUEST-STATUS codes (Section 10.15 Response 
Codes) are
 > not well organized so its hard to tell exactly what should be sent 
back.  ...

(1) REQUEST-STATUS values '3.1' and '3.13'  are defined in 2446  and not 
in CAP.

(2) You have them backwards:

 In 2446 they are defined in section (3.6 Status Replies):

   3.1 Invalid property value. Property name and value MAY be specified.

   3.13 Unsupported component or property found.

  So, no not 3.13 as you state, but 3.1 (incorrect value) as
  sent in the original email is in fact correct.

(3) The topic was do we add CALSCALE as a GET-CAPABILITY reply.
    I say it can wait until someone comes up with a new CALSCALE.

--

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 15:45:05 -0700

[email-masked] wrote:
> Normally I would not respond to this kind of trolling but Ill give you
> the benefit of the doubt and chalk this up to ignorance rather than
> malice.  Nathaniel wrote:
> 
> to which I pointed out that he was incorrect.  iCalendar has at least
> 5 places where it says duplicates are to be treated as a single
> instance.  I then pointed out that CAP also has text to this effect.
>  So my reply was on topic just like the last time you said it wasnt.

Bull, a valarm is not the same thing as a vevent instance,
and criplling the comments posted to imply they mean instances 
of a vevent is just more trolling.

And you still refues to stick to the point. How do you fix
one?

---

From: "G. Barnes" <[email-masked]>
Date: Mon, 10 Nov 2003 16:58:43 -0800 (PST)

> entry, the same should go for alarms).

Two responses:

1) To move CAP along, I think we have to concede that the question of
unique ids for VALARMs was already considered, and unique ids were
considered good by almost everyone.  From the archive, it appears this
was most heavily discussed November 2001-January 2002, and everyone
seemed to agree that alarmids of some sort were useful.  For example, from:

<http://www.imc.org/ietf-calendar/mail-archive/msg02317.html>

Steve Mansour wrote:
}I agree.  I think it is far simpler to just always add the alarmid.
}I'll make the update. If anyone has any objections let's go through it
}on the list.  (we can always pull it out later if someone comes up with
}a good reason for NOT having an alarm id).

[Needless to say, no one had any objections and no one came up with
such a reason that I could see.]

2) As for what's the use of duplicate alarms, what if I want to send
myself 20 e-mail messages to make sure I get the hint?  Or have 5 windows
opening with blinking text?  Who are we to say what a user might think is
useful?

                        Greg Barnes
                        Computing and Communications, University of Washington
                        [email-masked]
                        (206) 685-3295

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Nov 2003 18:46:22 -0700

> > entry, the same should go for alarms).

ICAL disallows two identical vevents because the uid distinguishes
them. And ICAL defines if they have the same uid, then they are the same
object in a possible different state or time.

ICAL does not disallow vevents that would be identical except for the 
unique identifier.

> opening with blinking text?  Who are we to say what a user might think is

Again the only thing I see is the fix the oops alarms which I have
done more than once.

---

From: [email-masked]
Date: Tue, 11 Nov 2003 12:44:28 -0500

> object in a possible different state or time.

Actually the prohibition is on concurrent repeat instances which are 
actually identified using both UID and RECURRENCE-ID but in a nutshell 
this is basically it.

> ICAL does not disallow vevents that would be identical except for the 

Yep.  (See, Mark and I dont always disagree.)

Lets not forget that CAP currently has a prohibition on creating duplicate 
BOOKED instances (CAP-12-e, p19):

Bruce

---

From: [email-masked]
Date: Tue, 11 Nov 2003 12:34:10 -0500

> <http://www.imc.org/ietf-calendar/mail-archive/msg02317.html>

While we did discuss its addition back then, we did not cover all the 
bases (nor was the actual need discussed that I can see but thats a 
different topic).  Undiscussed or answered bits that come to mind are:

1: The addition is NOT optional (see ABNF) so if someone creates a VEVENT 
with a VALARM without SEQUENCE (aka ALARMID) then its considered an 
illegal VALARM.  This means that any iTIP gatewayd content without the 
required property is considered 'invalid'.  This is not goodness.

2: CAP says:

                                      These local alarms are not to be
   forwarded to other CUs, CUAs, or CSs as are the "SEQUENCE" property
   and the "ENABLE" parameter.

That is, when someone sends a VEVENT with a VALARM on it, local alarms and 
the SEQUENCE and ENABLE bits are NOT sent.  This is in direct conflict 
w/the ABNF of '1' which is what was previously decided on in that 
discussion you found:

> I think we should declare that this is a '1' and not
> a '0 or 1'. [Snip, snip]

I agree. 

which would say tthat any and all VALARMs MUST have an identifier added no 
matter what.  It seems the intent was to coerce CUAs into creating 
SEQUENCE (ALARMID) for those entries they are dealing with locally BUT it 
is NOT to be sent on the wire to others (at least thats how I read the CAP 
text above).  If thats the case then the ABNF for this change MUST be '0' 
or '1', not '1' since the invites, reschedules, etc sent would have to 
strip off the new stuff (or the local stuff).  Otherwise those items sent 
would have to have SEQUENCE (ALARMID) on them (to conform to the ABNF) and 
thats contrary to the current text (and I suspect the intent from that 
early work).

3: If we opt to make the SEQUENCE (ALARMID) property truely a '1' in the 
ABNF then some adjustments will need to happen to allow for legacy data 
that does NOT contain it.  That is, if an invitation arrives via iMIP then 
in order for it to be put into the CS someone has to coerce the missing 
property onto it.  However, is this identifier on alarms truely necessary 
when the entry is NOT "BOOKED"?  I suspect not but Im open to discussion 
otherwise.   (After all, whom ever assigned that new property value was 
NOT the Organzier so it should be considered a local change and thus not 
propigated to others.)

4: If we say that SEQUENCE (ALARMID) is to be used on all VALARMs in CAP, 
BOOKED or not, then we need to invent a new property parameter for 
SEQUENCE (ALARMID) to indicate if the property was created locally for 
legacy data or not and the property should not be propigated further.  For 
example, if an iTIP invitation arrives without a SEQUENCE (ALARMID) 
property on it, the recipient is mandated to create one.  However since it 
was locally created and not assigned by the Organzier it should not be 
propigated on a delegation notice that the CUA creates.  Otherwise it 
violates the iTIP text on delegation since the delegation info has been 
modified from its original info (beyond what iTIP says to do for 
delegation tracking).

Before we can move on, these undiscussed issues need to be resolved or 
they risk being indeterminate in CAP 1.0 and thus become interop issues.

> opening with blinking text?  Who are we to say what a user might think 
is

We already have prohibitions on duplicate repeat instances in iCalendar 
and we have duplicate BOOKED entry prohibitions in CAP so its not as if a 
duplicate, identical alarm prohibition would be that extraordinary.  These 
existing prohibitions are despite that some folks may consider concurrent 
repeat instances useful.

In any case, all of what you suggest can be done with autorepeating 
alarms:

     BEGIN:VALARM
     ACTION:EMAIL
     TRIGGER:-P1D
     REPEAT:20
     DURATION:PT1S
     ATTENDEE:MAILTO:[email-masked]
     SUMMARY:*** REMINDER\: SEND AGENDA FOR IETF MEETING ***
     DESCRIPTION:Send out the draft agenda for the IETF WG Meeting 
tomorrow.  Attached is a
       pointer the document template for the agenda file.
 ATTACH;FMTTYPE=application/binary:http://host.com/templates/agenda.doc
     END:VALARM

     BEGIN:VALARM
     ACTION:EMAIL
     TRIGGER:-PT15M
     REPEAT:20
     DURATION:PT1S
     ATTENDEE:MAILTO:[email-masked]
     SUMMARY:*** ANOTHER REMINDER\: SEND AGENDA FOR IETF MEETING ***
     DESCRIPTION:Send out the final agenda for the IETF WG Meeting today.
     END:VALARM

     BEGIN:VALARM
     TRIGGER:-PT10M
     REPEAT:5
     DURATION:PT1S
     ACTION:DISPLAY
     DESCRIPTION:IETF WG Meeting in Jabber 10:00 AM EST today!
     END:VALARM

Bruce

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Nov 2003 11:53:07 -0700

> different topic).  Undiscussed or answered bits that come to mind are: 

Give it up, you claimed it was not discussed, it was.

You *always* claim that something you do not want is undiscussed.

--

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Nov 2003 11:56:56 -0700

[email-masked] wrote:
> Lets not forget that CAP currently has a prohibition on creating
> duplicate BOOKED instances (CAP-12-e, p19):
> 

Which is completely unrelated to the topic of should valarms
have a unique identifier. Whats your point?

---

From: Doug Royer <[email-masked]>
Date: Tue, 11 Nov 2003 11:55:06 -0700

>    There MUST NOT BE more than one "BOOKED" state object in a calendar

The SUBJECT is Alarms/SEQUENCE ???

No one disputes that VEVENTS must  have a unique ID.

--

---

From: Dan Winship <[email-masked]>
Date: Tue, 11 Nov 2003 15:20:37 -0500

Go away or I will replace you with a very small procmail script[1]

        :0
        * ^From.*Bruce_Kahn
        | (formail -kr; echo "No, you're wrong! Neener neener neener!) | sendmail -t

[1] http://www.thinkgeek.com/tshirts/frustrations/374d/

---

From: "G. Barnes" <[email-masked]>
Date: Tue, 11 Nov 2003 14:28:10 -0800 (PST)

> > opening with blinking text?  Who are we to say what a user might think

[...]

> In any case, all of what you suggest can be done with autorepeating
[...]

I've mostly said what I wanted to say, and don't want to repeat myself
too much, but here, I must emphasize that you seem to be assuming too much.

What if
a) The CUA doesn't allow repeats?
b) Or doesn't allow repeats with a duration anywhere as short as 1 second?
c) Or allows them, but to get them you have to use some advanced function
   that the user doesn't know or doesn't want to know?

I fail to see the harm in duplicate alarms, and judging from the discussions
I've read in the archive, I think the matter was considered by many other
people, and unique ids for alarms were considered a good thing.  Yeah, sure,
we can reconsider it, but if you're interested in doing the simplest thing,
reopening old issues isn't what you want to be doing.

                        Greg Barnes

---

From: [email-masked]
Date: Wed, 12 Nov 2003 10:18:35 -0500

>    that the user doesn't know or doesn't want to know?

All interesting questions / scenarios.  I would think that any CUA capable 
of distinguishing between 20 identical duplicate alarms would allow 
something like repeats but perhaps not.  Still though they are valid 
questions...

> reopening old issues isn't what you want to be doing.

The only thing that I question regarding the original discussion was the 
practicality of multiple exact duplicates considering its not something 
available in any shipping product now that Im aware of.

In any case, I do question the undiscussed change of ALARMID to SEQUENCE 
(including the misreuse of SEQUENCE as an identifier instead of a change 
tracker).  In evaluating the actual application I also came up with the 4 
questions I posted before. 

Contrary to WG discussion before, I think the ABNF for this change needs 
to be '0' or '1', not '1' for technical reasons previously mentioned. 
Doing this and making it clear that the identifer is ONLY for BOOKED 
entries and is never sent as part of workflow should resolve 'em I think. 
However Im interested to hear if there are alternate ideas.

Bruce