[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CAP: RELATED-TO property in VAGENDA.



  This mail summarizes the suggested changes yielded by the 
removal of calendar hierarchies and the introduction of the 
RELATED-TO property in VAGENDA.

1) Section 1.3

   In definition of Calendar, replace the sentence:

      In addition, a calendar might be hierarchically related to
      other sub-calendars.

   with:      
      
      In addition, a calendar might be related to other calendars
      by using the RELATED-TO calendar property.

   see: http://www.imc.org/ietf-calendar/mail-archive/msg02776.html
      
2) Section 1.3

   Remove definition of Hierarchical Calendars, and
   add:

       Related Calendars

        A CS feature where a calendar may have relationships to other
        calendars. Relationships are specified in the calendar with
        the RELATED-TO calendar property. The relationships have no
        predefined meaning to CAP. They are a convenience for the 
	CUA, CU, or CS administrator so that calendars may be 
	organized and marked as relating to each other as specified 
	in the implementation or administrative configuration of the 
	CS or CUA. Any CUA with sufficient access permission may 
	view these RELATED-TO properties.

   see: http://www.imc.org/ietf-calendar/mail-archive/msg02779.html


3) Section 1.3

   Remove the definition of "Sub-calendars".

   see: http://www.imc.org/ietf-calendar/mail-archive/msg02781.html

4) Section 2.2 Calendar Store Object Model.
   Remove VAGENDAs nested in VAGENDA.

   see: http://www.imc.org/ietf-calendar/mail-archive/msg03000.html
   
5) Remove Section 2.4.3 Inheritance
   
6) Remove Section 5.1 VCAR Inheritance

7) Section 6.2.4.4 "move" Command

   In the section:

     The "move" command is used to move components within the CS's
     hierarchy of calendars.  The access control on the VAGENDA after
     it has been moved to its new location in the calstore hierarchy
     MUST be at least as secure as it was prior to the move.  One way 
     to accomplish this is to build a list of VCARs that apply to 
     the VAGENDA in its old hierarchy and and write them into the
     VAGENDA before moving it to its new location.

   Without VCAR inheritance, the comments about access control 
   doesn't seem to be relevant anymore. The paragraph could probably 
   be rewritten as:

     The "move" command is used to move components within the CS's
     containers (VCALSTORE or VAGENDAs).  
        
8) Changes to section 10 (Properties), were already posted
   by George.

   see: http://www.imc.org/ietf-calendar/mail-archive/msg04246.html

--
Patrice