headers
Craig Johnson | 1 Nov 2003 01:54
Picon

Re: When to publish -12 - VFREEBUSY

Bruce Wrote on 10/31/03 13:19:
> Craig wrote on 10/02/2003 07:35:54 AM:
> > The example uses the SEARCH command with a VFREEBUSY to make
> > the request. The advantages/benefits are:
> > * It creates consistency and continuity between the WG standards for
> > making a free-busy requests.
>
> Umm, I have to disagree with a couple of your points here.  iTIP currently defines how to do
> busytime lookups and > thats with METHOD:REQUEST (iTIP, Section 3.3.2 REQUEST). 
> As such, CAP is not consistant nor continuous from the existing standards since its using
> CMD:SEARCH and no METHOD property.
 
Respectfully, that misses the KEY point ... but gives me an opportunity to restate it: 
!!! The WG standard for making a request for free-busy time is with the VFREEBUSY object. !!! 
RFC 2445, p. 58:
 
   Component Name: VFREEBUSY
 
   Purpose: Provide a grouping of component properties that describe
   ... a request for free/busy time
 
(I shall refer to such an object as a "VFREEBUSY request".  It is a VFREEBUSY object containing,
at least, a DTSTART and DTEND property defining the period of interest.)
 
iTIP simply defines how iTIP 'wrappers' a "VFREEBUSY request" (which uses METHOD:REQUEST). 
In CAP, the presence of the METHOD property is what distinguishes an iTIP message (and iTIP handling)
from regular CAP.  It should not be expected that a strictly CAP implementation of a
"VFREEBUSY request" would have a METHOD property. 
 
Which brings up the next point:
 
CAP does not (and with CAP-12e still does not) support this working group's own standard
for obtaining free-busy information: a "VFREEBUSY request".  This was discussed and
acknowledged in a previous thread.  That discussion concluded that using a "VFREEBUSY
request" would be more appropriate and consistent with existing standards.  It facilitates
a CUA needing free-busy information for several attendees, some accessible via CAP and
others via iMIP (or any future mechanism), to form a single "VFREEBUSY request" and to
issue that same request to all attendees.
 
Once again, my proposal is that CAP conform to and support the WG standard by defining
the use of a "VFREEBUSY request" to obtain free-busy information.  It makes little difference
whether we give it's own command, or overload the SEARCH command.  A CAP
"VFREEBUSY request" would simply be:
 
C: BEGIN:VCALENDAR
C: VERSION:2.0
C: PRODID:-//Prodid
C: CMD:SEARCH (or GET-FREEBUSY)
C: TARGET:usera
C: TARGET:userb
C: BEGIN:VFREEBUSY       (start of "VFREEBUSY request")
C: DTSTART:startrange
C: DTEND:endrange
C: ORGANIZER:...
C: ATTENDEE:...
C: ATTENDEE:...
C: DTSTAMP:...
C: UID:...
C: END:VFREEBUSY         (end of "VFREEBUSY request")
C: END:VCALENDAR
 
C. Johnson
Permalink | Reply | 1 comment |
headers
Doug Royer | 1 Nov 2003 02:39

Re: When to publish -12 - VFREEBUSY


Craig Johnson wrote:

> Bruce Wrote on 10/31/03 13:19:
> > Craig wrote on 10/02/2003 07:35:54 AM:
> > > The example uses the SEARCH command with a VFREEBUSY to make
> > > the request. The advantages/benefits are:
> > > * It creates consistency and continuity between the WG standards for
> > > making a free-busy requests.
> >
> > Umm, I have to disagree with a couple of your points here.  iTIP 
> currently defines how to do
> > busytime lookups and > thats with METHOD:REQUEST (iTIP, Section 
> 3.3.2 REQUEST). 
> > As such, CAP is not consistant nor continuous from the existing 
> standards since its using
> > CMD:SEARCH and no METHOD property.
>  
> Respectfully, that misses the KEY point ... but gives me an 
> opportunity to restate it: 
> !!! The WG standard for making a request for free-busy time is with 
> the VFREEBUSY object. !!! 
> RFC 2445, p. 58:

It does and in -exactlyt- the same way - by the CUA and we added by the CS.

>  

--

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug <at> Royer.com                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
Permalink | Reply | 0 comments |
headers
Bruce_Kahn | 3 Nov 2003 20:11
Picon

Re: CAP-12-e: Alarms and SEQUENCE


Doug wrote on 10/31/2003 05:16:09 PM:
> Better yet, an example of when MODIFY breaks.
>
> Take TWO VLARMS that are identical in one component.
> Withou a unique identifier  - you can not uniquly identify  the 2nd
> instance.

I claim that this is a non-sensical / practical case to use.  (Plus its the only one I could think of too.)

We dont allow multiple VDAYLIGHTs or VSTANDARDs with the exact same data to be a single VTIMEZONE and yet consider the defintions to be different.  We do not allow 2 VEVENTs in the same calendar to have the exact same set of properties and subcomponents yet call them different VEVENTs.  We even said in iCalendar that repeat instances for the same date/time are to be treated a single instance.  So why would we now invent this different consideration for VALARMs?

Taking a practical look I have to chuckle at the suggestion (not at you personally Doug) that a CU would want or actually use 2 identical VALARMs yet consider them separate.  In all my C&S time Ive yet to hear of any shipping product that allowed the user to create 2 identical alarms that were separate nor have I heard of users actually asking for it.

After all, what exactly is the practical use for 2 simultaneous & identical AUDIO VALARMs that play the same sound at the same time? Does it play louder?  Or is it in Stero vs Mono?

Is there any actual use for having 2 PROCEDURAL alarms that run the exact same code at the exact same time?  

What about sending off 2 identical email notices to the exact same set of ATTENDEEs at the exact same time?

I dont see how having 2 DISPLAY VALARMs triggering at the same time with the same information is really a big ticket item on any users wish list.  

Since we have autorepeating VALARMs (which means the VALARM could repeat, say, 1 second later for 15 times if I really really wanted it to) and we can have multiple VALARMs on any given entry, I see no real need to have multiple identical copies of VALARMs and to change iCalendar.  

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Permalink | Reply | 3 comments |
headers
Bruce_Kahn | 3 Nov 2003 20:16
Picon

Re: When to publish -12 - SCOPING


Doug said on 10/31/2003 03:23:09 PM:
> > Go check the archives for Presons posting on 04/03/2003 02:36:12 PM
> > MST under the subject "How do you get the METHOD property on a
> > SEARCH".   There was a brief WG flurry about it but no actual
> > resolution on it
>
> Now go read the rest of the archives. you will find there was
> a solution sent to the list.

I dont see any solution in my archives.  The last I saw was some discussion between you, me and Andrea about scoping and you were going to (from 04/07/2003 11:57:58 AM CST):

I will update the text! from "an iCalendar" to "one or more iCalendar".
And add text about grouped by METHOD (or any IANA property ... blurb...).

But the text in 12-e under Section 6.1.1 CAL-QUERY looks nearly the same as in it did back then.  I will go search the IMC archives and see if I missed the postings where there was a proposal and agreement on resolving this.

> Do you have another proposal?

I havent seen your proposal so Ill go see if I can find it before I write another.  Why reinvent if I dont have to...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Permalink | Reply | 0 comments |
headers
Bruce_Kahn | 3 Nov 2003 20:46
Picon

Re: vzic Olson->iCalendar timezone converter update


Damon wrote on 10/25/2003 01:17:10 PM:
> Yes, you can drop the BEGIN/END VCALENDARs, and just leave 1 pair.

Dont forget to trim out the other duplicate VCALENDAR level properties like PRODID, VERSION, etc too...

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Permalink | Reply | 0 comments |
headers
Bruce_Kahn | 3 Nov 2003 20:33
Picon

Re: CAP-12-e: Alarms and SEQUENCE


Mark wrote on 10/22/2003 02:53:09 PM:
> You still propse to break MODIFY wihout any solution. No one
> wants to break modify.

Not true.  Go see last weeks followup to Doug regarding this.

> I do not know which version if any draft or published text you
> have been reading, but I can not find ANY other unique identifier
> for VALARMS. What is it?

You must have missed the threads from ~Oct/Nov 2001 that was again touched on in Jan/Feb 2002.  Go check out http://www.imc.org/ietf-calendar/mail-archive/msg02442.html for the WG decision regarding the creation of ALARMID (not SEQUENCE).  In fact, as part of the revisit in 2002 under the subject "VALARM: UID VS ALARMID" Doug wrote:

I prefer ALARMID.

and so did ~all the others that I can see.  Yet somehow, without any WG discussion I can find, the ALARMID property was replaced by SEQUENCE.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...
Permalink | Reply | 0 comments |
headers
Bruce_Kahn | 3 Nov 2003 21:19
Picon

CAP-12-e: CAP-VERSION Property


In looking at Tims proposal I noticed that CAP-VERSION is not properly described/defined.  12-e says:

   Description: This specifies the version of CAP that the endpoint
  supports. The list is a comma separated list of RFC numbers
  supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE
  REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT).

   Formal Definition: The property is defined by the following notation:

  cap-version   = "CAP-VERSION" other-params ":" text CRLF

  Example: The following are examples of this property:

  CAP-VERSION:XXXX

1: Is there a reason CAP-VERSION is not defined like VERSION is in iCalendar?  That is, why it is not a numeric value or formatted like a numeric value?  It used to be last I checked on it back in CAP-09:

     CAP-VERSION        1     Version of CAP. It MUST include at least "1.0"
                             for this version of CAP. Like the "VERSION"
                             property, it may have a range. Uses the exact
                             same syntax as the "VERSION" property value.
                             The default is "1.0".

2: When did we say CAP-VERSION was to be the RFC number?  Is there any real use for that over using the numeric scheme like we did in iCalendar?  If we do opt to stay with "text" then the last line there needs to have the same "(NOTE 'XXXX' WILL BE REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT)." added to it to ensure the change is uniform.

3: In later examples we use numeric values ala VERSION.  For example, page 112 has:

      L: CAP-VERSION:1.0

If we are avoiding using numeric values and go with RFC numbers then this example needs to be changed and flagged too for update on RFC number assignment.

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.
Permalink | Reply | 6 comments |
headers
Bruce_Kahn | 3 Nov 2003 21:33
Picon

Re: different calendar scales


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: Bruce_Kahn <at> notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.
Permalink | Reply | 504 comments |
headers
John Stracke | 3 Nov 2003 22:17

Re: different calendar scales


Bruce_Kahn <at> notesdev.ibm.com wrote:

> 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!) 

Yeah, but that'd be the case either way; putting scales into the 
capabilities just means you *know* it sucks to be you.

I think, if we ever get non-Gregorian scales, we'll have to mandate that 
all iCalendar implementations support Gregorian, for interop with 
existing implementations.  As I understand it, the only place where this 
would be sticky is in RRULE.  Individual dates can always be translated; 
but people who use a lunar calendar, say, may want to schedule recurring 
events according to patterns that have no equivalent in a solar 
calendar.  If so, then the RRULEs from a lunar scale simply could not be 
translated into Gregorian.  But there really isn't any good solution for 
that; people who want to schedule events based on phase of the moon will 
not be able to do so when communicating with people whose CUs don't 
support it.

"Oh, hell, let's leave the problem for future generations."  "Good 
idea.  It'll make them feel more involved." -- Doonesbury (two of the 
authors of the US Constitution, discussing slavery)

--

-- 
/===============================================================\
|John Stracke      |jstracke <at> centive.com                        |
|Principal Engineer|http://www.centive.com                      |
|Centive           |My opinions are my own.                     |
|===============================================================|
|"There will be no more there. We will all be here."--networkMCI|
|ad                                                             |
\===============================================================/
Permalink | Reply | 504 comments |
headers
Doug Royer | 3 Nov 2003 22:42

Re: CAP-12-e: CAP-VERSION Property


Bruce_Kahn <at> notesdev.ibm.com wrote:

>
> In looking at Tims proposal I noticed that CAP-VERSION is not properly 
> described/defined.  12-e says:
>
>    Description: This specifies the version of CAP that the endpoint
>   supports. The list is a comma separated list of RFC numbers
>   supported. The list MUST contain at least XXXX (NOTE 'XXXX' WILL BE
>   REPLACED WITH THE RFC NUMBER OF THIS DOCUMENT).
>
>    Formal Definition: The property is defined by the following notation:
>
>   cap-version   = "CAP-VERSION" other-params ":" text CRLF
>
>   Example: The following are examples of this property:
>
>   CAP-VERSION:XXXX
>
> 1: Is there a reason CAP-VERSION is not defined like VERSION is in 
> iCalendar? 

It is a multivalued field unlike VERSION. So you could say you are RFC 
X, and Z compatible
skipping Y if needed.

>  That is, why it is not a numeric value or formatted like a numeric 
> value?  It used to be last I checked on it back in CAP-09:
>
>      CAP-VERSION        1     Version of CAP. It MUST include at least 
> "1.0"
>                              for this version of CAP. Like the "VERSION"
>                              property, it may have a range. Uses the exact
>                              same syntax as the "VERSION" property value.
>                              The default is "1.0".
>
> 2: When did we say CAP-VERSION was to be the RFC number? 

As you pointed out about it must have been -10

--

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
Doug <at> Royer.com                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards
Attachment (smime.p7s): application/x-pkcs7-signature, 4696 bytes
Permalink | Reply | 5 comments |

Gmane