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.
...
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.
....
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 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.
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.
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
I wish I could make it, I had planned on it, too much work,.. I'll be on Jabber.
Doug Royer | http://INET-Consulting.com
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)520-4044
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature