Re: different calendar systems - i18n

Nathaniel Borenstein wrote:

>
> No dispute there, only the question (posed to the list as a whole):  
> Does everyone agree that the current extension mechanisms (VERSION, 
> CALSCALE, CAP-VERSION) suffice to ensure that the desired extensions 
> can be done correctly, i.e. without ever creating situations like the 
> one I describe above, in which an older server accepts calendar data 
> that it really doesn't know how to handle because of the unsupported 
> CALSCALE.  My guess/hope is that the answer is yes, but I would feel 
> better knowing that wiser heads than mine have thought seriously about 
> the problem and come to the same conclusion.  -- Nathaniel

There is no way that an older server will know how to process new 
extensions. A properly implemented
server would look at CALSCALE, VERSION, ... (and what ever) and know 
that it does not know how to handle it.
If your server gets CALSCALE:foo and it does not know what to do with 
'foo'  then it better send back
an error.

CAP would not care when RECUR-EXPAND is false what the CALSCALE value 
was set to as such a CS
would never be trying to do anything with recurrence rules. If 
RECUR-EXPAND is true, then yes
the CS should reject the data if it does not understand CALSCALE:foo . 
Do you think we need to
say that in CAP?

VERSION is the iCal format version, not the version of the data that it 
contains. So VCARD works
as a valid iCAL data because it conforms to version 2.0 of the iCAL 
format. Such a CS would only
need to add VCARD to its COMPONENT capability list. So I think that 
VERSION will never
be effected by the CALSCALE value as VERSION does not change when new 
components, properties
or parameters are added.

CAP-VERSION is intended to tell the CUA which RFC's the CS supports. It 
would not
imply that CALSCALE:foo is or is not supported.

Do you think that we can say that RFC -XXX (CAP) supports GREGORIAN and only
after a new CALSCALE value is published we could then add a new 
CAPABILITY to CAP
that tells the CS what CALSCALEs the CS supports. Or do you feel we need 
to have
a CALSCALE capability now? Or as CAP-VERSION is a comma separated list
could such a CALSCALE:foo CS just add RFC-foo to its list?

-- 

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

                We Do Standards - You Need Standards