Subject: W-23 OVERLAPPED-BOOKINGS proposal

From: Doug Royer <[email-masked]>
Date: Thu, 29 Jul 1999 12:54:07 -0700 (PDT)

PROPOSAL for calendar property:

OVERLAPPED-BOOKINGS     R/W     boolean

        If TRUE, components are allowed be added to the calendar
        that overlap other blocking (TRANSP=OPAQUE) components.

        If FALSE, no component may be added where any portion
        of OPAQUE time overlaps any other existing components
        OPAQUE time.

        CS MUST implemented at least a READ-ONLY
        OVERLAPPED-BOOKINGS calendar property.

        CS MAY implement a READ-WRITE OVERLAPPED-BOOKINGS
        calendar property.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: [email-masked]
Date: Thu, 29 Jul 1999 23:02:34 GMT

>PROPOSAL for calendar property:
Just a nit, but an important one...
This proposal should be in the RFC2445 specified format for a change 
request:

     To: [email-masked]

     Subject: Registration of text/calendar MIME property
              ALLOW-CONFLICTS

     Property name: ALLOW-CONFLICTS

     Property purpose: A calendar property that specifies whether
      overlapping events are permitted on the calendar.

     Property value type(s): BOOLEAN

     Property parameter (s): NONE

     Conformance: For an implementation conforming to [CAP], this
      property MUST be supported as a read-only property. In addition,
      an implementation conforming to [CAP] MAY permit this property
      to be settable.

     Description: If TRUE, events are allowed to be added to the
      calendar that overlap with other events. If FALSE, no event
      may be added where any interval between the start and end of
      the event overlaps any other existing event.

     Format definition:

        1. Change the RFC 2445 ABNF token "" to read:

            calprops   = 2*(
                ; 'prodid' and 'version' are both REQUIRED,
                ; but MUST NOT occur more than once
              prodid /version /

                ; 'calscale', 'method', 'allow-conflicts'
                ; are optional, but MUST NOT occur more than
                ; once
              calscale        /
              method          /
              allow-conflicts /

              x-prop)

           2. Add the following ABNF:

              allow-conflicts = "ALLOW-CONFLICTS" ":" boolean

     Examples: The following is an example of using this property to
      specify that no overlapping events are allowed on the calendar:

        ALLOW-CONFLICTS:FALSE

      The following is an example usage of this property to specify
      that overlapping event is allowed on the calendar:

        ALLOW-CONFLICTS:TRUE

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 Jul 1999 15:57:57 -0700 (PDT)

> From: [email-masked]
> Date: Thu, 29 Jul 1999 23:02:34 GMT
> 

> This proposal should be in the RFC2445 specified format for a change 

No - Its a CAP idea for a Calendar property. Not an RFC2445 property.
:-)

-Doug

---

From: [email-masked]
Date: Thu, 29 Jul 1999 23:33:35 GMT

>No - Its a CAP idea for a Calendar property. Not an RFC2445 property.

Hhmm. There is only one IETF standard form calendar data. Any CAP 
extensions to the iCalendar data model will involve change requests. The 
format for these change requests in the CAP specification SHOULD look like 
the change request form in RFC 2445.
We do want these to get registered in the IANA registration of iCalendar 
properties right?
-- Frank

---

From: Doug Royer <[email-masked]>
Date: Thu, 29 Jul 1999 16:32:43 -0700 (PDT)

> Date: Thu, 29 Jul 1999 23:33:35 GMT
>

I see your point.

However I was proposing it for the CAP draft.  Are you saying that if
CAP is accepted, then all of the new properties defined in CAP have to
be separately submitted to IANA?  Or is the fact that CAP was accepted
an acceptable form of registration?

-Doug

---

From: [email-masked]
Date: Fri, 30 Jul 1999 13:30:07 GMT

>I see your point.

Thanks.

>an acceptable form of registration?

If we put the iCalendar extensions in the CAP spec in the "change control" 
format, then when CAP is published as an RFC, it becomes the IANA 
registration. Your latter comment is what I was advocating.
So, as we make proposals that involve extensions/enhancement changes to 
the iCalendar data model, we might want to put these forward in this 
"change control" form so that it will be that much easier for the CAP 
editors to integrate the work into the CAP specification.