> B.1 Changes in -05
> a
> Removed property promotion/demotion requirements

Remove the most interesting part, why don't you ;).

Thanks for the link. I'll update my TODO. Any idea how many more changes
until you reach the final draft?

-James

On Thu, 2005-01-20 at 09:23 -0800, Lisa Dusseault wrote:
> The -05 version of calDAV, which Cyrus and Bernard and I are working  
> on, should be quite implementable and interoperable: several clients  
> and servers were tested against each other at last week's CalConnect  
> consortium test event.
> 
> You can find the draft in-progress at http://ietf.webdav.org/caldav.   
> The XML version is the one we edit, and you can upload it to  
> http://xml.resource.org/ to turn it into text or HTML.
> 
> lisa
> 
> On Jan 19, 2005, at 10:20 PM, [EMAIL PROTECTED] wrote:
> 
> > masonjm     2005/01/19 22:20:30
> >
> >   Modified:    proposals/caldav TODO
> >   Log:
> >   Clarification of requirements for some tasks
> >
> >   Revision  Changes    Path
> >   1.2       +18 -6     jakarta-slide/proposals/caldav/TODO
> >
> >   Index: TODO
> >   ===================================================================
> >   RCS file: /home/cvs/jakarta-slide/proposals/caldav/TODO,v
> >   retrieving revision 1.1
> >   retrieving revision 1.2
> >   diff -u -r1.1 -r1.2
> >   --- TODO  27 Oct 2004 06:13:42 -0000      1.1
> >   +++ TODO  20 Jan 2005 06:20:30 -0000      1.2
> >   @@ -2,24 +2,36 @@
> >
> >     - view-free-busy privilege
> >     
> >     http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> > -02.html#PRIVILEGE_view-free-busy
> >   - This will probably require a custom Security implementation.
> >   + This will probably require:
> >   +         a custom Content implementation (override ContentImpl) to 
> > handle  
> > the new privilege
> >   +         a custom Structure implementation (override StructureImpl) to  
> > handle the new privilege
> >   + This will probably NOT require a custom Security implementation
> >
> >     - calendar-bind privilege for calendar resources
> >     
> >     http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> > -02.html#PRIVILEGE_calendar-bind
> >   - This will probably require a custom Security implementation.
> >   + This will probably require:
> >   +         a custom Content implementation (override ContentImpl) to 
> > handle  
> > the new privilege
> >   +         a custom Structure implementation (override StructureImpl) to  
> > handle the new privilege
> >   + This will probably NOT require a custom Security implementation
> >
> >     - supported-privilege set
> >     
> >     http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> > -02.html#rfc.section.14.4
> >   - I don't know if Slide implements this. If not, it will require a  
> > patch to the core. Either
> >   - way the output will need to include CalDAV elements.
> >   + We may get this for free. Modification of  
> > SupportedPrivilegeSetProperty may be required if CalDAV
> >   + privileges should only show up for Calendar resources. Talk with  
> > Stefan Lutzkendorf if modifications
> >   + are required. He'll know best how to make them.
> >
> >     - Property Promotion and Demotion
> >     
> >     http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> > -02.html#promotion
> >   - Either using the extractor framework or the event framework (or  
> > both). The extractor
> >   - framework probably won't allow for modifing the content on  
> > propatch.
> >   + Will require:
> >   +         A PropertyExtractor implementation to set properties when a  
> > resource is uploaded
> >   +         An event listener to modify the content when a PROPPATCH is  
> > received
> >   +         An iCal library (possibly http://ical4j.sourceforge.net/)
> >   + May require:
> >   +         An event listener to handle deleted properties. This depends on 
> >  
> > how the extractor framework handles these.
> >
> >     - Calendaring REPORTs
> >     
> >     http://greenbytes.de/tech/webdav/draft-dusseault-caldav 
> > -02.html#reports
> >   + ???
> >
> >     - Administration App
> >             There are structural requirements in the spec ("Each Calendar  
> > MUST have a collection containing events")
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to