Re: Status of the CALSCH working group (CALSCALE)

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...