Subject: Re: different calendar scales

From: Tim Hare <[email-masked]>
Date: Mon, 03 Nov 2003 20:57:23 -0500

I had in mind more the Hebrew CUA asking the CS if it could use the Hebrew 
calendar when storing items; but your examples work as well. I am still in 
favor of this small addition to the GET-CAPABILITY return, since anything 
that makes things fail more gracefully in my book is a good thing.

Tim Hare
Interested Bystander, Non-Inc.

At 03:33 PM 11/3/03 -0500, [email-masked] wrote:

>Tim suggested on 09/23/2003 02:24:11 AM:
> > I propose that CAP 10.7 be revised so that calscale-props is included as a
> > required response to the GET-CAPABILITY command, and that any
> > examples for GET-
> > CAPABILITY be modified to show CALSCALE: GREGORIAN, HEBREW, JALALIL
> > CRLF (or a
> > similar list of calendar scales) being returned.
>
>Hmm, Mark didn't hop up and down on you for trying to make a change but 
>then again noone seems to have responded (or Im missing WG traffic).   The 
>suggestion has merit in that it would make adding support for 
>non-GREGORIAN scales easy however adding to CAP is against the editors 
>mantra.
>
>I like the idea but since there are currently no other calendar scales out 
>there nor are there any proposals for any Im not sure there is sufficent 
>need at this time.  Of course putting it in after the fact can be harder 
>(imagine a CAP 1.0 client trying to use CAP to a HEBREW only CS...  Sucks 
>to be that CU!)
>
>There are 2 ways to approach this and neither cause any big delays in CAP.
>
>1: Simply add some text to Section 10.7 GET-CAPABILITY Command that says 
>something like:
>
>     For this version of CAP, both sides are assumed to support only the 
> GREGORIAN calendar scale entries.  Entries in other calendar scales MUST 
> NOT be sent to this version of a CAP implementation.
>
>2: We can update CAP to actually return CALSCALE in the ABNF:
>
>    cap-vreply     = "BEGIN" ":" "VCALENDAR" CRLF
>                   ; The following properties may be in any order.
>                   ;
>                    prodid
>                    version
>                    reply-cmd
>                    other-props
>                    "BEGIN" ":" "VREPLY" CRLF
>                    ; The following properties may be in any order.
>                    ;
>                    cap-version
>                     calscale
>                    car-level
>                    components
>                    stores-expanded
>                    maxdate
>                    mindate
>                    itip-version
>                    max-comp-size
>                    multipart
>                    query-level
>                    recur-accepted
>                    recur-expand
>                    recur-limit
>                    other-props
>                    "END" ":" "VREPLY" CRLF
>                   "END" ":" "VCALENDAR" CRLF
>
>and then add some text to the command that says something like:
>
>     The "GET-CAPABILITY" reply MUST include a CALSCALE property.  This 
> indicates all the calendar scales which the sender understands.  Data 
> that is not in one of those calendar scales MUST NOT be sent.
>
>This would make the issue of a CAP 1.0 CUA talking to a HEBREW-only CS 
>more easily detected and thus fail nicer ("The CS you are connecting only 
>supports calendars in a scale I do not understand so I am unable to work 
>with it.  Please upgrade me or use a different server.")
>
>Bruce
>===========================================================================
>Bruce Kahn                                INet: [email-masked]
>Messaging & Collaboration                 Phone: 978.399.6496
>IBM Software Group                         FAX: and nothing but the FAX...
>Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Tue, 04 Nov 2003 12:14:20 -0700

Tim Hare wrote:

>
> I had in mind more the Hebrew CUA asking the CS if it could use the 
> Hebrew calendar when storing items; but your examples work as well. I 
> am still in favor of this small addition to the GET-CAPABILITY return, 
> since anything that makes things fail more gracefully in my book is a 
> good thing.
>
> Tim Hare

I do agree with you. However we are trying to get CAP out and additions 
or deletions
at this point will require (per the AD in S.F.) a huge consensus. It 
does not look like there
has been one for this.

I have submitted a couple of CAP add-on (separate) drafts, Adding what 
you request as an add on
may be the way to get it done.

-- 

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