http://permalink.gmane.org/gmane.ietf.caldav hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.caldav/1186 <pre>Hi Calendar developers, I encountered an internal server error. Would like to listen to your suggestions. When i go to system manage page and then click manage calendar &amp; folders and then click "+" to add a calendar, error message shows up on the top of this page. Error message: "org.bedework.calfacade.exc. CalFacadeException: java.lang.RuntimeException: Error creating MBeanProxy: org.bedework:service=CalDAVSynchConnections =An exception occurred: *org.bedework.calfacade.exc.CalFacadeException: java.lang.RuntimeException: Error creating MBeanProxy: org.bedework:service=CalDAVSynchConnections"* Any thoughts? I appreciate your help. Thanks. Lei _______________________________________________ caldav mailing list caldav&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/caldav </pre> Lei Pan 2013-04-01T17:45:48 http://permalink.gmane.org/gmane.ietf.caldav/1185 <pre>Hi list, we are on Mac OSX Lion server ( 10.7.4 ) and here is a snippet from our logfile /var/log/caldavd/access.log. We would like to know why first time we get a entry with the correct username, but second time a empty string for the same user? It's a little bit confusing, because we run a wallboard for monitoring the usage on our server and the 'top ten' users, but the empty string is not so nice ;) I removed the ip address and the UUID, but both has the same values in the original logfile. Is there a way to get this corrected? 127.0.0.1 - username [18/Mar/2013:14:21:47 +0200] "PROPFIND /principals/__uids__/the_UUID_of_the_user/ HTTP/1.1" 207 1366 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=7 t=12.0 or=1 cached=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx 127.0.0.1 - - [18/Mar/2013:14:22:21 +0200] "PROPFIND /principals/__uids__/the_same_UUID_as_in_the_entry_before/ HTTP/1.1" 401 141 "-" "Mac OS X/10.8.2 (12C3012) CalendarAgent/55" i=6 t=14.6 or=1 xff=xx.xx.xx.xx fwd=xx.xx.xx.xx Thanks, Sirko_______________</pre> Sirko Mann 2013-03-20T11:03:51 http://permalink.gmane.org/gmane.ietf.caldav/1184 <pre> </pre> B. Aerts 2013-02-19T20:55:20 http://permalink.gmane.org/gmane.ietf.caldav/1183 <pre> Confirmation of list posting -- confirmation ID: 2dLWQVUSPdNg The ietf.org mailing-list server has received a list posting from gic-caldav&lt; at &gt;m.gmane.org to caldav&lt; at &gt;ietfa.amsl.com with the subject 'CalDAV PUT returns HTTP 301: wrong request ?' As the sender address isn't subscribed to the list, and has not been confirmed earlier, we have to request a confirmation of the address. To confirm the address, send a message to caldav&lt; at &gt;ietfa.amsl.com, with the same subject line as this message. (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form. The reply's additional "Re:" is ok.) If you do not wish your posting to the list to go through, simply disregard this message. Questions to postmaster&lt; at &gt;ietf.org. </pre> caldav< at >ietfa.amsl.com 2013-02-19T20:14:46 http://permalink.gmane.org/gmane.ietf.caldav/1182 <pre> Confirmation of list posting -- confirmation ID: trusgLUSE8kw The ietf.org mailing-list server has received a list posting from gic-caldav&lt; at &gt;m.gmane.org to caldav&lt; at &gt;ietfa.amsl.com with the subject 'CalDAV PUT returns HTTP 301: wrong request ?' As the sender address isn't subscribed to the list, and has not been confirmed earlier, we have to request a confirmation of the address. To confirm the address, send a message to caldav&lt; at &gt;ietfa.amsl.com, with the same subject line as this message. (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form. The reply's additional "Re:" is ok.) If you do not wish your posting to the list to go through, simply disregard this message. Questions to postmaster&lt; at &gt;ietf.org. </pre> caldav< at >ietfa.amsl.com 2013-02-17T20:24:51 http://permalink.gmane.org/gmane.ietf.caldav/1181 <pre>Hi, what is this one for? _______________________________________________ caldav mailing list caldav&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/caldav </pre> nora saad 2013-01-09T00:46:10 http://permalink.gmane.org/gmane.ietf.caldav/1180 <pre> Sent from my iPhone </pre> mehdi asadi 2013-01-08T15:41:10 http://permalink.gmane.org/gmane.ietf.caldav/1179 <pre> My read of 3.8.1.3 doesn't help me at all in defining the server behavior when this property is present. Should a proxy (iCal calls them delegates) of a user have access to only PUBLIC? I guess so, but this is not clearly specified in the RFC. And what does restricting that access entail? Do we hide the component entirely? Again, I guess so. In which case, this is not the same as X-CALENDARSERVER-ACCESS, which only restricts access to a subset of sub-components (4.2.2.4 in our spec[1]). The delegate should see that there is a meeting booked there for scheduling purposes, but not the title, description, etc. This behavior is distinct from CLASS, and is why a new property is used. Our spec for X-CALENDARSERVER-ACCESS also specifies that only the DAV:owner can edit this property. iCalendar wouldn't specific such a thing, as it doesn't reference WebDAV. I suppose CalDAV could, but it does not. Another reason is that our server will not remove the X-CALENDARSERVER-ACCESS property from an exi</pre> Wilfredo Sánchez Vega 2012-12-18T00:20:25 http://permalink.gmane.org/gmane.ietf.caldav/1178 <pre>This notification is going to several calendaring-related mailing lists, which means that you are quite likely to receive it more than once, our apologies for the duplications. Registration is now open for CalConnect XXVI, January 28 - February 1, 2013, hosted by Oracle in Santa Clara, California As usual, Monday and Tuesday all day and Wednesday morning will be the Interoperability Test Event; Wednesday afternoon, Thursday, and Friday will be the CalConnect Roundtable Technical Conference. About CalConnect: For more information about CalConnect, The Calendaring and Scheduling Consortium, please see http://www.calconnect.org. About CalConnect XXVI Logistics information for this event may be found at http://www.calconnect.org/calconnect26.shtml including travel, preliminary hotel, and other planning information. A general schedule is posted, but will be updated nearer to the event with the actual session schedule and with topical agendas for the schedule. The meeting venue is on the Oracle camp</pre> Dave Thewlis 2012-11-16T20:43:55 http://permalink.gmane.org/gmane.ietf.caldav/1177 <pre>RFC 5545 section 3.8.1.3 defines an iCalendar property, CLASS, which can, at least in theory, set a privacy level for an event or task. So I tried uploading an event with its CLASS property set to PRIVATE to a CalDAV server running OS X Server Calendar Server, and found that the event wasn't so private - delegates of the calendar could read the event just fine. So I searched around for information about private events, and I found this: &lt;http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk/doc/Extensions/caldav-privateevents.txt&gt; That document describes an X-CALENDARSERVER-ACCESS property that can also inform the server that an event or task is classified for the purposes of delegation and (I'm guessing) free/busy requests. My questions are: 1. Why are there apparently two different ways of setting the classification of an event or task? 2. Why does at least Apple's calendar server ignore the CLASS property server-side? 2a. Do any servers actually honor this property for delegati</pre> Nick Zitzmann 2012-11-01T21:25:28 http://permalink.gmane.org/gmane.ietf.caldav/1176 <pre> Sent from my iPhone </pre> mehdi asadi 2012-10-27T17:34:30 http://permalink.gmane.org/gmane.ietf.caldav/1175 <pre> Sent from my iPhone </pre> mehdi asadi 2012-10-24T16:35:14 http://permalink.gmane.org/gmane.ietf.caldav/1174 <pre>This e-mail is going to multiple calendaring-related lists; my apologies if you receive more than one copy but you probably will, as so many folks are on multiple lists. Dear Colleagues, CalConnect , The Calendaring and Scheduling Consortium, is delighted to announce that its next event, CalConnect XXV, will be hosted by Google in Zürich, Swttzerland, the week of October 1-5, 2012. We would like to invite everyone, especially our European colleagues, to join us. This will be the the second full CalConnect event in Europe, following our very successful first such event last October in Prague. The week will feature an Interoperability Test Event, a Technical Conference, plus additional workshops and seminars. We are offering a one-time, very reduced registration fee for non-members to participate in both the IOP Test Event and the Roundtable Technical Conference of only $350 per person. If you are interested in calendaring, would like to participate in the interoperability testing or the technical se</pre> Dave Thewlis 2012-08-24T17:50:10 http://permalink.gmane.org/gmane.ietf.caldav/1173 <pre>FYI -------- Original Message -------- Subject: Protocol Action: 'CalDAV Scheduling Extensions to WebDAV' to Proposed Standard (draft-desruisseaux-caldav-sched-12.txt) Date: Mon, 16 Apr 2012 10:10:10 -0700 From: The IESG &lt;iesg-secretary&lt; at &gt;ietf.org&gt; To: IETF-Announce &lt;ietf-announce&lt; at &gt;ietf.org&gt; CC: RFC Editor &lt;rfc-editor&lt; at &gt;rfc-editor.org&gt; The IESG has approved the following document: - 'CalDAV Scheduling Extensions to WebDAV' (draft-desruisseaux-caldav-sched-12.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-desruisseaux-caldav-sched/ Technical Summary Scheduling is a core function of a calendaring system and this extension defines the process by which CalDAV clients and servers can use iCalendar (RFC 5545) and iTIP (RFC 5546) to accomplish that in a manner that ensures data consistency between o</pre> Bernard Desruisseaux 2012-04-16T18:03:47 http://permalink.gmane.org/gmane.ietf.caldav/1172 <pre>Hi folks, The caldav-scheduling draft was just approved for publication as an RFC. It has taken longer than it should have to get to this point, but we managed it in the end! Thanks to all of those who have contributed to this specification over the years and to the many who have already implemented it. There is still a bunch of important stuff to work on in CalDAV, including calendar sharing, external/managed attachments, various minor extensions etc, and hopefully we will be progressing on those soon. ------------ Forwarded Message ----------- Date: April 16, 2012 10:10:10 AM -0700 From: IETF Secretariat &lt;ietf-secretariat-reply&lt; at &gt;ietf.org&gt; To: cyrus&lt; at &gt;daboo.name, bernard.desruisseaux&lt; at &gt;oracle.com, douglm&lt; at &gt;rpi.edu, draft-desruisseaux-caldav-sched&lt; at &gt;tools.ietf.org, julian.reschke&lt; at &gt;greenbytes.de, lisa.dusseault&lt; at &gt;gmail.com Subject: ID Tracker State Update Notice: &lt;draft-desruisseaux-caldav-sched-12.txt&gt; IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: htt</pre> Cyrus Daboo 2012-04-16T17:17:50 http://permalink.gmane.org/gmane.ietf.caldav/1170 <pre>Hi, please allow me to bring to your attention my just finished bachelor thesis on the subject of the design of a restful API to be useful for a Groupware or the person related informations of OpenSocial. I'd appreciate any feedback. The text will be available under a free license after I received the mark for it. Points that might be of special interest for (some of) you: - a modernized design of CalAtom/CardAtom[1] without the need for a new "feature" property - efficient synchronization of collections with restful HTTP - properties of vCard useful (or missing) for OpenSocial - use of OpenSearch for reports - use of nice small value objects replacing some functionality of Jersey (Java REST framework) - a "resource facade" framework to support multiple "views" or media types of the same data - a minimal implementation of an atom pub server on top of Jersey [1] http://robubu.com/?cat=2 http://github.com/thkoch2001/bachelor- thesis/blob/master/latex/restful_groupware.pdf Please </pre> Thomas Koch 2012-04-09T10:25:00 http://permalink.gmane.org/gmane.ietf.caldav/1169 <pre>Hi, I'm playing with the RELATED-TO attribute, and I found out that Zimbra 7.1.2 don't store this attribute while it stores the remaining VTODO content. I tested it with Calendar Server trunk, and it works just fine. From my understanding, a CalDAV server should store any valid attributes, so is this a "illegal" behavior? For the record, the attribute was set like this: RELATED-TO;RELTYPE=PARENT:&lt;20120328T155331Z-uidGen&lt; at &gt;mbp-pascal-robert-4.local&gt; 20120328T155331Z-uidGen&lt; at &gt;mbp-pascal-robert-4.local is a object that is already existing. _______________________________________________ ietf-caldav mailing list -- ietf-caldav&lt; at &gt;osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav </pre> Pascal Robert 2012-03-28T16:59:40 http://permalink.gmane.org/gmane.ietf.caldav/1168 <pre>This notice is going to the calendaring-related IETF lists. Our apologies if you receive multiple copies; many people are on the same lists. Registration is now open for CalConnect XXIV, May 21-25, 2012, hosted by Patricia Egen Consulting in Chattanooga, Tennessee As usual, Monday and Tuesday all day and Wednesday morning will be the Interoperability Test Event; Wednesday afternoon, Thursday, and Friday will be the CalConnect Roundtable Technical Conference. General Information: Logistics information for this event may be found at http://www.calconnect.org/calconnect24.shtml including travel, hotel, and other planning information. A general schedule is posted, but will be updated nearer to the event with the actual session schedule and with topical agendas for the schedule. The meeting venue and conference hotel is the Doubletree Hotel, 407 Chestnut Street, Chattanooga, TN. All meeting sessions and the Wednesday evening reception will be held at the Doubletree. The Doubletree is offering a</pre> Dave Thewlis 2012-03-19T18:45:46 http://permalink.gmane.org/gmane.ietf.caldav/1167 <pre>Looks good. Arnaud Q On 10/02/2012 20:35, Cyrus Daboo wrote: _______________________________________________ ietf-caldav mailing list -- ietf-caldav&lt; at &gt;osafoundation.org See http://ietf.webdav.org/caldav/ for more CalDAV resources http://lists.osafoundation.org/mailman/listinfo/ietf-caldav </pre> Arnaud Quillaud 2012-02-23T18:19:31 http://permalink.gmane.org/gmane.ietf.caldav/1166 <pre>Hi folks, Finally (!!!) we are progressing the scheduling spec through the publication process. The IETF-wide last call is now in effect. Please review and send comments as appropriate. -------- Original Message -------- Subject: Last Call: &lt;draft-desruisseaux-caldav-sched-10.txt&gt; (CalDAV Scheduling Extensions to WebDAV) to Proposed Standard Date: Thu, 09 Feb 2012 16:38:12 -0800 From: The IESG &lt;iesg-secretary&lt; at &gt;ietf.org&gt; Reply-To: ietf&lt; at &gt;ietf.org To: IETF-Announce &lt;ietf-announce&lt; at &gt;ietf.org&gt; The IESG has received a request from an individual submitter to consider the following document: - 'CalDAV Scheduling Extensions to WebDAV' &lt;draft-desruisseaux-caldav-sched-10.txt&gt; as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2012-03-08. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow a</pre> Cyrus Daboo 2012-02-10T19:35:29 http://permalink.gmane.org/gmane.ietf.caldav/1165 <pre> It seems to me that this issue was never addressed. As defined right now, the way REPORT is used doesn't seem to be compatible with the definition of REPORT in RFC 3253, and the definition of the Depth: header field in RFC 4918. Unless I'm missing something, this will be a problem for any implementation that tries to implement the sync report based on a generic WebDAV reporting framework. Best regards, Julian </pre> Julian Reschke 2011-12-13T21:50:54 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.caldav