Re: Status of the CALSCH working group

Thanks for the awesome feedback!

Nathaniel Borenstein wrote:

> On Tuesday, November 4, 2003, at 07:06 PM, Satya Vempati 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.
>
> ....
>
>
> 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. 


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.

> ....
>
> 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.

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.

>
> 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.

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 -- ...

>
> 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. 

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.

>
> 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.

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.

> 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? 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.

> Alarms/SEQUENCE -- I remain confused: Can there be two identical 
> 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.

> 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


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.

-- 

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

               We Do Standards - You Need Standards