Re: Status of the CALSCH working group (CALSCALE)

Doug wrote on 11/07/2003 04:14:11 PM:
> > 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.

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

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

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
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...