From fr@skyrix.com Mon Dec 27 14:52:31 2004 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 89BF13CE75A for ; Mon, 27 Dec 2004 14:52:31 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 16713-02 for ; Mon, 27 Dec 2004 14:52:31 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 54C223CE66F for ; Mon, 27 Dec 2004 14:52:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id D9D012B67F1 for ; Mon, 27 Dec 2004 14:51:38 +0100 (CET) Received: from mail.in.skyrix.com (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id A6D482B67E5 for ; Mon, 27 Dec 2004 14:51:38 +0100 (CET) Received: from localhost (mail.in.skyrix.com [192.168.0.53]) by mail.in.skyrix.com (mail) with ESMTP id 9D2A5940017 for ; Mon, 27 Dec 2004 14:52:30 +0100 (CET) Received: from mail.in.skyrix.com ([192.168.0.53]) by localhost (mail [192.168.0.53]) (amavisd-new, port 10024) with ESMTP id 20022-03 for ; Mon, 27 Dec 2004 14:52:29 +0100 (CET) Received: from [192.168.0.103] (iguana.in.skyrix.com [192.168.0.103]) by mail.in.skyrix.com (mail) with ESMTP id AF1C3940015 for ; Mon, 27 Dec 2004 14:52:29 +0100 (CET) Message-ID: <41D013F0.6090009@skyrix.com> Date: Mon, 27 Dec 2004 14:53:52 +0100 From: Frank Reppin User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: groupdav@opengroupware.org X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at skyrix.com X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00, UPPERCASE_25_50 X-Spam-Level: Subject: [Groupdav] List maintenance... Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... please ignore! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB0BPw9Atrv5KxwOwRAulCAKCaSJY2VacSg73CfbvOn7/dHBorlwCfSs0Z cwxhPvXCkv86k5HJ4rE6R38= =fMrz -----END PGP SIGNATURE----- From helge.hess@opengroupware.org Wed Jan 12 16:31:07 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id EA0323CE27A for ; Wed, 12 Jan 2005 16:31:06 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 06867-07 for ; Wed, 12 Jan 2005 16:30:57 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 94DDB3CE1A5 for ; Wed, 12 Jan 2005 16:30:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 052582CA20A for ; Wed, 12 Jan 2005 16:29:28 +0100 (CET) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 70C122CA1FF for ; Wed, 12 Jan 2005 16:29:27 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: groupdav@opengroupware.org From: Helge Hess Date: Wed, 12 Jan 2005 16:31:06 +0100 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Subject: [Groupdav] KDE-PIM Meeting Results Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Hi, just wanted to give a small update on GroupDAV. If I manage I'm going to update the draft to a -02 this week using the results from the discussion at the KDE-PIM meeting last week. I hope that we can resolve all open issues for ZideStore and Kontact this month. Below a loose listing of issues we discussed. # are the Bugzilla IDs, please check the bugreports for details. Note that some issues are Kontact specific. KDE #96753 - folder tree instead of pre-traversed list Unlike Evolution, Kontact doesn't have a folder tree which is expanded/collapsed on demand. This was done using a flat tableview which contained the "pre traversed" folders. This isn't possible because the WebDAV hierarchy can be (and in the case of ZideStore *is*) very deep. => KDE issue, Reinhold will fix it GroupDAV #1100 / KDE #96754 - folder-query WebDAV itself doesn't provide a query which just returns the subcollections of any given collection. We agreed to use a specific DASL query for this (Note: clients nor servers are NOT supposed to implement full DASL, just some very specific XML queries which are compatible to a full DASL server) GroupDAV #1096 - query DAV:getcontenttype together with etag The folder "content scan etag query" needs to be enhanced to include the MIME type of the content object. That way the client can filter out content it won't be able to understand (like a PDF). NOTE: the client then needs to be careful when comparing object sets to sync a cache. (not that it deletes all non-iCal objects because they are not available "anymore" in the local cache) GroupDAV #1163 / KDE #96755 - recurrences First: we found a way to represent non-iCal recurrences in GroupDAV. ZideStore already does deliver a related-to property for "connected" events (pre calculated recurrences in OGo). Second: we discussed an approach on the deletion of such items. Whether the event is a "set event" the client knows from the 'related-to' property. In this case the client should give the user the option to either "delete-all" or to "delete". For delete-all it would then perform a DELETE for each of the connected events. GroupDAV #1097 - location header Related to the issue above. It discusses the handling of new recurring events. GroupDAV servers are allowed to return a 'location' header after the PUT to redirect the client to the new object (living at a new URL). We had the issue that a create of a recurrence might result in multiple events being created, yet we can only signal one. This was found to be a non-issue. The client has the ID of one new event, needs to perform a sync after the update and can then traverse its event set for the 'related-to' property. GroupDAV #1099 / KDE #96756 - read only permission support Representing just this fact (read only) is easy with WebDAV ACL's, so we are going to specify that instead of inventing a new "read only" WebDAV property. Note: this has to be added to the "content scan etag query". This query MUST query the permission property. TODO: do we need to tell the server that we only support exactly this tag? GroupDAV #1114 / KDE #96757 - signal unsupported entities The server needs to be able to signal the client that it can't process a given entity. The client should prompt the user and ask him what to do: a) save and risk loosing some data b) save somewhere else (eg in a local storage) c) go back to editor to remove superflous data GroupDAV #1155 / KDE #96758 - HTML extensions to the client UI I'm not sure whether we should actually put this into the GroupDAV draft, its more like an extension for HTTP based servers. (maybe an own mini draft?) OK, the idea is that its trivial in almost all environment to embed an HTML viewer inside arbitary applications (KParts in KDE, IE on Windows, Moz on GNOME). So it would be quite useful if the server could provide some HTML pages which show extended server features to the native client. This would give immediate access to most features in an HTTP based server able to provide HTML output without the requirement to build a client tightly bound to the server. OK, thats it. Discussion and comments are welcome. Greets, Helge PS: I'm going to FOSDEM. Anyone else? -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From room_groupdav@uncensored.citadel.org Thu Jan 13 18:23:31 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id C54EB3CE33A for ; Thu, 13 Jan 2005 18:23:31 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 27920-06 for ; Thu, 13 Jan 2005 18:23:31 +0100 (CET) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by mail.opengroupware.org (mail) with SMTP id 3941C3CE275 for ; Thu, 13 Jan 2005 18:23:09 +0100 (CET) From: Art Cancro To: Date: Thu Jan 13 12:08:03 EST 2005 Message-Id: <20050113172309.3941C3CE275@mail.opengroupware.org> X-Virus-Scanned: by a leet scanner. X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'Date' ^ X-Spam-Status: No, hits=-1.7 tagged_above=-999.0 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_SHORT X-Spam-Level: Subject: [Groupdav] GroupDAV implementations Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Hello everyone. I'm sure that those of you who know me were expecting I'd show up on this list eventually. :) For those of you that don't, an introduction ... I am Art Cancro, lead developer for the Citadel project (web site at http://www.citadel.org for more info) -- we have been building and maintaining an open source groupware server since 1998, and its BBS roots go all the way back to 1981). Our biggest problem has always been getting some good client software interoperating with the Citadel system for more than just email, and have wanted the open source community to agree on a standard set of protocols and data formats for open source groupware clients to talk to open source groupware servers. About a year ago we thought that the Kolab spec was going to fit that bill, and we eagerly provided Kolab compatibility in the Citadel system. Unfortunately, the Kolab people were quite uncooperative, and they eventually abandoned their original design in favor of a big new XML-based mess which I don't think is ever going to work. Eventually, we hooked up with the Aethera people, who were very pleasant to work with, and Aethera 1.2.0 works nicely with Citadel. Now that I'm seeing the GroupDAV draft, I'm very excited that this could potentially be the avenue that provides compatibility with Kontact, Evolution, and hopefully other clients such as Thunderbird+Sunbird at a later date. We are definitely going to provide GroupDAV compatibility in the Citadel system. I had a brief email conversation with Helge about this, and we agreed that it would be beneficial for everyone to have a second server implementation available, to show issues with the current draft and the current client implementations. Towards that end, I have a couple of suggestions: 1. I noticed that the draft shows both "text/calendar" and "text/vcalendar" in different places as the MIME type for calendar objects. The correct type is "text/calendar" so that should be corrected. (If I'm not mistaken, it has probably already been corrected.) 2. In the interest of making GroupDAV a vendor-neutral spec, let's try to take the hard-coded "/zidestore" out of the path. Perhaps it could be made "/groupdav" instead? Or better yet, clients could be configured to point to an arbitrary path, allowing for alternate port numbers, https, etc. to be used. 3. Can we please make it a requirement that clients honor HTTP cookies? This will allow server implementations that are maintaining a session state to keep track of which session is which. By the way, I see from reading the draft-01 that there's currently no provision for email. I would like to see that as an option in the future. The Citadel server implementation already has a unified message store for email, calendar, contacts, tasks, etc. so it would be nice to expose them through a single protocol. All I'm asking is that we provide a roadmap for getting there -- I will volunteer to write that part of the spec at a later date if necessary. We look forward to working with you! Art Cancro From helge.hess@opengroupware.org Thu Jan 13 19:43:48 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id DBA183CE24B for ; Thu, 13 Jan 2005 19:43:47 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 13220-06 for ; Thu, 13 Jan 2005 19:43:46 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 3613A3CE277 for ; Thu, 13 Jan 2005 19:43:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id C3FFB2CAC21 for ; Thu, 13 Jan 2005 19:42:15 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 174042CAC36 for ; Thu, 13 Jan 2005 19:42:15 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050113172309.3941C3CE275@mail.opengroupware.org> References: <20050113172309.3941C3CE275@mail.opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0D130E25-6593-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] GroupDAV implementations Date: Thu, 13 Jan 2005 19:43:43 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Hi Art, welcome! :-) On 13. Jan 2005, at 18:08 Uhr, Art Cancro wrote: > Eventually, we hooked up with the Aethera people, who were very > pleasant to > work with, and Aethera 1.2.0 works nicely with Citadel. In case you have a connection it would be nice if Aethera would use GroupDAV to accomplish that in the next version ;-) > Now that I'm seeing the GroupDAV draft, I'm very excited that this > could > potentially be the avenue that provides compatibility with Kontact, > Evolution, > and hopefully other clients such as Thunderbird+Sunbird at a later > date. We > are definitely going to provide GroupDAV compatibility in the Citadel > system. Excellent! > I had a brief email conversation with Helge about this, and we agreed > that it > would be beneficial for everyone to have a second server implementation > available, to show issues with the current draft and the current client > implementations. Definitely. Just to explain our motivation: we at OpenGroupware.org do not want to write clients or enhance clients like KDE or Evolution on our own, we see our focus on the server. As a result we depend on getting client vendors to support our server. Fortunately OGo is quite popular so that we finally got the client support we wished for several years (Kontact + Evolution). Nevertheless we still feel that those implementations are more likely to get maintained and improved constantly if they are useful for more developers than just OpenGroupware.org. Problem: interest is too low for client vendors to write a connector for a single OpenSource server Solution: GroupDAV ;-) As a result GroupDAV puts interoperability at the very very TOP. The goal is to make the protocol simple enough so that server developers can easily implement it. This is a bit in contrast to CalDAV which (besides supporting only calendaring) is much more difficult to implement properly requiring full compliance with a whole lot of standards (DASL, WebDAV, WebDAV ACLs, iCalendar, XMPP?...). Note that we do not want to compete with CalDAV, I just see it as a more complex solution which should be usable on top of GroupDAV. > 1. I noticed that the draft shows both "text/calendar" and > "text/vcalendar" > in different places as the MIME type for calendar objects. The > correct > type is "text/calendar" so that should be corrected. (If I'm not > mistaken, > it has probably already been corrected.) This has been fixed already. If not, please let us know. > 2. In the interest of making GroupDAV a vendor-neutral spec, let's try > to > take the hard-coded "/zidestore" out of the path. Perhaps it could > be > made "/groupdav" instead? Or better yet, clients could be > configured to > point to an arbitrary path, allowing for alternate port numbers, > https, > etc. to be used. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1172 As mentioned in the bug, the spec only uses those URLs in examples, the spec does not enforce the locations at all. But, yes, I can do this. And yes, the client needs to allow configuration of arbitary entry points. > 3. Can we please make it a requirement that clients honor HTTP > cookies? This > will allow server implementations that are maintaining a session > state to > keep track of which session is which. http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1171 I'm against that because few clients (especially WebDAV ones) properly support that and I do not want to setup a complicate protocol, but an easy one. I'm not even sure whether this is required by WebDAV in the way you want to use it. Please elaborate what exactly you use cookies for and why we must support that. Maybe we can suggest workarounds (and document such in the draft!) > By the way, I see from reading the draft-01 that there's currently no > provision > for email. Correct. IMHO email is something entirely different than GroupDAV because its inherently single user and about generic unstructured data stores while the reverse is true for groupware. Besides the world really doesn't need yet-another-email-protocol, IMAP4 is established and just works (oh yes, it doesn't really - only by years of effort ;-). I wonder whether it would be possible to "mount" an IMAP4 email folder into WebDAV simply by using a different URL, eg: ---snip-- PROPFIND /myroot .. HTTP/1.0 207 Multi-Status ... http://localhost/myroot/Calendar/ HTTP/1.1 200 OK imap://localhost:143/helge/INBOX/ HTTP/1.1 200 OK ---snap--- Recorded as: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1173 I'm not sure whether this is allowed in WebDAV, but would provide the functionality to have a single folder hierarchy managed by WebDAV while still using the proper protocol for email access (IMAP4). > I would like to see that as an option in the future. Well, there is the HTTPMail draft for email. Personally I also like the idea of doing email over HTTP, but its somewhat utopic that clients will actually do that? > The Citadel server implementation already has a unified message store > for email, calendar, > contacts, tasks, etc. so it would be nice to expose them through a > single > protocol. As mentioned the focus is not to provide a protocol which exposes every feature any given groupware server provides. The functionality should be sufficient but very well defined. Email is a _very_ _very_ complex topic. > All I'm asking is that we provide a roadmap for getting there -- I > will volunteer to write that part of the spec at a later date if > necessary. As mentioned I would rather like to find ways to marry IMAP4 and HTTP/WebDAV here. Please let me know what you think and whether you follow my reasoning. > We look forward to working with you! :-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From awilliam@whitemice.org Fri Jan 14 04:44:45 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 66A1B3CE1A5 for ; Fri, 14 Jan 2005 04:44:45 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 01593-02 for ; Fri, 14 Jan 2005 04:44:44 +0100 (CET) Received: from estate1.whitemice.org (adsl-68-79-189-145.dsl.klmzmi.ameritech.net [68.79.189.145]) by mail.opengroupware.org (mail) with ESMTP id 2EE503CE19E for ; Fri, 14 Jan 2005 04:44:44 +0100 (CET) Received: from 192.168.3.196 ([192.168.3.196]) (authenticated bits=0) by estate1.whitemice.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j0E3igDJ021176 for ; Thu, 13 Jan 2005 22:44:42 -0500 Subject: Re: [Groupdav] GroupDAV implementations From: Adam Tauno Williams To: groupdav@opengroupware.org In-Reply-To: <0D130E25-6593-11D9-B499-000D936E5072@opengroupware.org> References: <20050113172309.3941C3CE275@mail.opengroupware.org> <0D130E25-6593-11D9-B499-000D936E5072@opengroupware.org> Content-Type: text/plain Organization: BOTWM Date: Thu, 13 Jan 2005 22:46:29 -0500 Message-Id: <1105674389.5531.8.camel@laptop01.whitemice.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.4 (estate1.whitemice.org [192.168.3.1]); Thu, 13 Jan 2005 22:44:42 -0500 (EST) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org X-Reply-To: awilliam@whitemice.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: > > By the way, I see from reading the draft-01 that there's currently no > > provision for email. > Correct. IMHO email is something entirely different than GroupDAV > because its inherently single user and about generic unstructured data > stores while the reverse is true for groupware. Besides the world > really doesn't need yet-another-email-protocol, IMAP4 is established > and just works (oh yes, it doesn't really - only by years of effort > ;-). Agree, and I think very many shops already have huge IMAP based systems in place. Any making an extremely stable and robust mail store/server is really really hard. > I'm not sure whether this is allowed in WebDAV, but would provide the > functionality to have a single folder hierarchy managed by WebDAV while > still using the proper protocol for email access (IMAP4). Agree, I'd be very interested in a DAV<-->IMAP proxy. > > All I'm asking is that we provide a roadmap for getting there -- I > > will volunteer to write that part of the spec at a later date if > > necessary. > As mentioned I would rather like to find ways to marry IMAP4 and > HTTP/WebDAV here. Yep. From helge.hess@opengroupware.org Fri Jan 14 05:38:56 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id DFA7A3CE242 for ; Fri, 14 Jan 2005 05:38:55 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 06228-09 for ; Fri, 14 Jan 2005 05:38:55 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 67AC93CE23C for ; Fri, 14 Jan 2005 05:38:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id B16C32CA88D for ; Fri, 14 Jan 2005 05:37:18 +0100 (CET) Received: from [192.168.1.126] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 409222CA88C for ; Fri, 14 Jan 2005 05:37:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1105674389.5531.8.camel@laptop01.whitemice.org> References: <20050113172309.3941C3CE275@mail.opengroupware.org> <0D130E25-6593-11D9-B499-000D936E5072@opengroupware.org> <1105674389.5531.8.camel@laptop01.whitemice.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3369F42A-65E6-11D9-B113-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] GroupDAV implementations Date: Fri, 14 Jan 2005 05:38:56 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On Jan 14, 2005, at 4:46, Adam Tauno Williams wrote: >> I'm not sure whether this is allowed in WebDAV, but would provide the >> functionality to have a single folder hierarchy managed by WebDAV >> while >> still using the proper protocol for email access (IMAP4). > Agree, I'd be very interested in a DAV<-->IMAP proxy. I'm not so interested in a proxy (BTW: ZideStore will soon have that). See my example, I just want to be able to refer to an existing IMAP4 server/folder using an imap:// URL, so that IMAP4 is used directly by the client against the mailbox. The client would be responsible to either process the folder contents using IMAP4 in case it can or otherwise open the local mail client using the IMAP4 URL. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From room_groupdav@uncensored.citadel.org Fri Jan 14 06:12:33 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id B12C13CE24B for ; Fri, 14 Jan 2005 06:12:33 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 10755-06 for ; Fri, 14 Jan 2005 06:12:32 +0100 (CET) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by mail.opengroupware.org (mail) with SMTP id BE6283CE242 for ; Fri, 14 Jan 2005 06:12:11 +0100 (CET) From: Art Cancro To: Date: Fri Jan 14 00:02:10 EST 2005 Message-Id: <20050114051211.BE6283CE242@mail.opengroupware.org> X-Virus-Scanned: by a leet scanner. X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'Date' ... ^ X-Spam-Status: No, hits=-1.7 tagged_above=-999.0 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_SHORT X-Spam-Level: Subject: [Groupdav] mail in GroupDAV Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Thanks for the warm welcome. :) I do agree that IMAP, as ugly as it is, is a protocol that all mail server vendors have already implemented. (We did ... and it was painful. It really is an over-engineered protocol.) So if it is a given that IMAP is definitely going to be there for mail then this raises the question: why use DAV at all? Why not just use IMAP for all groupware items? I know, it's too late in the game to change gears now, but that is how we currently expose groupware objects to clients like Aethera. Unlike OGo, the Citadel server is more like Groupwise and Exchange in that it uses a single, unified store for mail, public folders, calendars, contacts, tasks, etc. It is all just a bunch of MIME. I guess we have different perspectives on this because your server is an adjunct which requires an external IMAP server for mail, while our server is a unified mail/groupware engine. I do, however, respect (and ADMIRE) the goal of designing a protocol that is intended to be easy to implement. I wish Mark Crispin had pursued that goal. :( In the end we'll go along with whatever is in the final spec. If that means using separate protocols for mail and groupware, so be it. What I would like to see, though, is some way of telling the client that certain folders are going to be exposed through GroupDAV so they ought to omit them when enumerating the IMAP folders. Art Cancro From helge.hess@opengroupware.org Fri Jan 14 18:04:26 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 0F0283CE19E for ; Fri, 14 Jan 2005 18:04:26 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 28431-02 for ; Fri, 14 Jan 2005 18:04:23 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id A7EAB3CE242 for ; Fri, 14 Jan 2005 18:04:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id A101C2A8559 for ; Fri, 14 Jan 2005 18:02:50 +0100 (CET) Received: from [192.168.0.126] (gw.skyrix.com [213.211.192.97]) by mail.mdlink.net (Postfix) with ESMTP id 5D8CA2A82D9 for ; Fri, 14 Jan 2005 18:02:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050114051211.BE6283CE242@mail.opengroupware.org> References: <20050114051211.BE6283CE242@mail.opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Fri, 14 Jan 2005 18:04:35 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Hi, please: see the discussion below in the context of the definition of the protocol. I do not want to spark a discussion how implementations should store their data and what makes sense or not. On Jan 14, 2005, at 6:02, Art Cancro wrote: > So if it is a given that IMAP is definitely going to be there for mail > then > this raises the question: why use DAV at all? Why not just use IMAP > for all > groupware items? I thought I already answered that in my reply. IMAP4 is a protocol heavily targetted at mail, this includes that it doesn't need or support object update operations (not required for mails which are read only) and has extensive, mail targetted MIME searching facilities but none for structured content. I'm aware that several implementations mix mail and groupware storage (Exchange being one) - IMHO this is very very wrong, but the choice of the implementor ;-) Notably few of the implementations are contrained to IMAP4 or even use it as the primary protocol for mail. > I know, it's too late in the game to change gears now, but that is how > we > currently expose groupware objects to clients like Aethera. Unlike > OGo, the > Citadel server is more like Groupwise and Exchange in that it uses a > single, > unified store for mail, public folders, calendars, contacts, tasks, > etc. It > is all just a bunch of MIME. OK. > I guess we have different perspectives on this because your server is > an > adjunct which requires an external IMAP server for mail, while our > server > is a unified mail/groupware engine. The thing which I'm missing is how this matters to the _protocol_. It is perfectly fine that we have different opinions about how to do a groupware server, indeed this is a good thing as this will prove whether GroupDAV is generic enough to support your kind of server. Note: nitpicking, your wording is incorrect: "your server is an adjunct external IMAP server for mail". The IMAP4 server is just a specialized database for mail to us which we integrate. Comparable to how PostgreSQL is a specialized database for structured data like events. SQL/PostgreSQL is optimized on structured multiuser data while IMAP4/Cyrus is optimized on read only, single user unstructured data. > I do, however, respect (and ADMIRE) the goal of designing a protocol > that is intended to be easy to implement. More important in the context is that the protocol is supposed to have HIGH interoperability. This makes it necessary to focus. That your server also stores mail in the same storage is an extension to GroupDAV since this mode of operation is not widely used in OpenSource servers. The far majority of OpenSource servers use an RDBMS to store data in some self invented database model and we need to deal with that. > In the end we'll go along with whatever is in the final spec. If that > means > using separate protocols for mail and groupware, so be it. Well, you could still document an extension to GroupDAV which covers mail on your site and _OGo_ might even implement it (since I also like the idea, its just that I'm just pretty sure that it will be implemented by anyone else ;-). But GroupDAV is supposed to work with the meriad of available OpenSource servers. Including specialized servers like for example Bugzilla which could use GroupDAV to expose its data (instead of requiring Kontact [and every other client] to produce a specialized Bugzilla plugin). > What I would like to see, though, is some way of telling the client > that certain folders are going to be exposed through GroupDAV so they > ought to omit them when > enumerating the IMAP folders. I'm not entirely sure what you mean, but suggestions are welcome :-) Another interesting topic in this context is whether we should really include vjournal's in GroupDAV. It is a) AFAIK not widely used b) also well covered for HTTP by Blogging protocols Opinions are welcome. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From ajc@uncensored.citadel.org Sat Jan 15 09:10:39 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 1542A3CE23A for ; Sat, 15 Jan 2005 09:10:39 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 06258-03 for ; Sat, 15 Jan 2005 09:10:38 +0100 (CET) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by mail.opengroupware.org (mail) with SMTP id 9E3B43CE19D for ; Sat, 15 Jan 2005 09:10:28 +0100 (CET) From: Art Cancro To: Date: Sat Jan 15 03:09:04 EST 2005 Message-Id: <20050115081028.9E3B43CE19D@mail.opengroupware.org> X-Virus-Scanned: by a leet scanner. X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'Date' ^ X-Spam-Status: No, hits=-1.7 tagged_above=-999.0 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_SHORT X-Spam-Level: Subject: [Groupdav] mail in GroupDAV Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: >Well, you could still document an extension to GroupDAV which covers >mail on your site and _OGo_ might even implement it (since I also like >the idea, its just that I'm just pretty sure that it will be >implemented by anyone else ;-). Since the Citadel server does rely heavily on MIME for storage of all types of objects as a unified store, this is going to happen almost automatically. Do expect such an extension. Obviously it is up to the client community whether anyone actually does anything with it. >> What I would like to see, though, is some way of telling the client >> that certain folders are going to be exposed through GroupDAV so they >> ought to omit them when enumerating the IMAP folders. > >I'm not entirely sure what you mean, but suggestions are welcome :-) What I mean is, I currently expose IMAP folders with names like "Calendar" and "Contacts" etc. which contain groupware items ... it would be nice, when using a client like Kontact or Evolution, to have some way for the server to be aware that GroupDAV is in use, so that it *doesn't* expose these folders through IMAP at the same time. That's just going to confuse the users. This isn't really a problem with the design of the GroupDAV protocol. I'd simply be interested in figuring out a way for the server to know when both GroupDAV and IMAP are simultaneously in use from the same client. >Another interesting topic in this context is whether we should really >include vjournal's in GroupDAV. IMHO we need to at least have a plan for supporting any of the object types our target clients will expect to handle. That would include Calendar, Contacts, Tasks, Notes, Journals. Also of interest is RFC 2739, which specifies how to specify the URL for freebusy data inside the user's vCard (and also in LDAP, but that's definitely outside the scope of GroupDAV). Art Cancro From helge.hess@opengroupware.org Sat Jan 15 17:42:36 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id D9B3C3CE293 for ; Sat, 15 Jan 2005 17:42:36 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 18312-07 for ; Sat, 15 Jan 2005 17:42:36 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 1F3763CE23F for ; Sat, 15 Jan 2005 17:42:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5CFFF2CBC6B for ; Sat, 15 Jan 2005 17:41:00 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id BB4692CBC46 for ; Sat, 15 Jan 2005 17:40:59 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050115081028.9E3B43CE19D@mail.opengroupware.org> References: <20050115081028.9E3B43CE19D@mail.opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <753DCDFF-6714-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sat, 15 Jan 2005 17:42:34 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 15. Jan 2005, at 09:09 Uhr, Art Cancro wrote: >>> What I would like to see, though, is some way of telling the client >>> that certain folders are going to be exposed through GroupDAV so they >>> ought to omit them when enumerating the IMAP folders. >> >> I'm not entirely sure what you mean, but suggestions are welcome :-) > > What I mean is, I currently expose IMAP folders with names like > "Calendar" > and "Contacts" etc. which contain groupware items ... it would be > nice, when > using a client like Kontact or Evolution, to have some way for the > server > to be aware that GroupDAV is in use, so that it *doesn't* expose these > folders through IMAP at the same time. That's just going to confuse > the > users. I don't see how this is a protocol or client issue and I don't see what GroupDAV can do about that. If the client asks you to return the IMAP4 folders _using_ IMAP4, you might not want to return Calendar or Contact folders. > This isn't really a problem with the design of the GroupDAV protocol. > I'd > simply be interested in figuring out a way for the server to know when > both > GroupDAV and IMAP are simultaneously in use from the same client. You didn't yet comment on my suggestion of returning imap:// URLs in PROPFIND: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1173 On the other side I think that my suggestion wouldn't work with Kontact and probably doesn't work with Evolution (though I'm not sure). Besides delivering Kolab like Calendar of Contact folders to a generic IMAP4 client _never_ makes sense to the user. So it should be disabled completely. >> Another interesting topic in this context is whether we should really >> include vjournal's in GroupDAV. > IMHO we need to at least have a plan for supporting any of the object > types > our target clients will expect to handle. That would include Calendar, > Contacts, Tasks, Notes, Journals. What is the difference between in a note and a journal? Target clients: Kontact - Calendar, Contacts, Tasks, Journals Sunbird - Calendar, Tasks Evolution - Calendar, Contacts, Tasks Further I think that even with Kontact Journals are not widely used. But I might be wrong. As mentioned I also think that the proper protocol for "Journals" might be metaWebLog or Blogger. But I'm open for discussion. I just wanted to hint that this might be yet-another-format the client and server needs to be able to deal with. One which might not be worth the effort. > Also of interest is RFC 2739, which specifies how to specify the URL > for > freebusy data inside the user's vCard (and also in LDAP, but that's > definitely > outside the scope of GroupDAV). LDAP is interesting as it is partially in the same category like IMAP4. It might indeed make sense to return folders stored in some LDAP server as references. (I don't understand why LDAP is out of scope for you, but IMAP4 isn't - I guess this is just because you implement one but not the other ;-) What would be required is an "accept-" like header which tells the server what protocols the client supports and what protocols the server would need to proxy. Something like: x-accept-folder-url-schemes: http; q=0.9, https; q=1.0, imap, imaps, ldap, ldaps Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From ajc@uncensored.citadel.org Sat Jan 15 23:11:03 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id C78A73CE2B3 for ; Sat, 15 Jan 2005 23:11:03 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 04212-02 for ; Sat, 15 Jan 2005 23:11:03 +0100 (CET) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by mail.opengroupware.org (mail) with SMTP id 16AD53CE25F for ; Sat, 15 Jan 2005 23:10:52 +0100 (CET) From: Art Cancro To: Date: Sat Jan 15 17:10:28 EST 2005 Message-Id: <20050115221052.16AD53CE25F@mail.opengroupware.org> X-Virus-Scanned: by a leet scanner. X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'Date' ^ X-Spam-Status: No, hits=-1.7 tagged_above=-999.0 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_SHORT X-Spam-Level: Subject: [Groupdav] mail in GroupDAV Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: As a compromise, I suppose I can live with the idea of having IMAP:// URL's being enumerated by GroupDAV. I would ask, however, that there be a clear and documented way to do extensions to the core protocol, similar to the way IMAP and other protocols can advertise their available extensions. Art Cancro From helge.hess@opengroupware.org Sun Jan 16 00:43:03 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 1DA343CE2AC for ; Sun, 16 Jan 2005 00:43:03 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 17100-08 for ; Sun, 16 Jan 2005 00:43:02 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 761183CE23F for ; Sun, 16 Jan 2005 00:43:02 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 9F1CC2CBF7A for ; Sun, 16 Jan 2005 00:41:18 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 2021A2CBF73 for ; Sun, 16 Jan 2005 00:41:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050115221052.16AD53CE25F@mail.opengroupware.org> References: <20050115221052.16AD53CE25F@mail.opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <30C98F72-674F-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 00:43:00 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 15. Jan 2005, at 23:10 Uhr, Art Cancro wrote: > As a compromise, I suppose I can live with the idea of having IMAP:// > URL's > being enumerated by GroupDAV. I'm not yet sure whether the idea is valid. Two issues: a) the only client implementing resource access that way is Evolution and even Evolution has special handling for mail, so this probably won't work with it anyway => no relevance in practice with any existing client we target b) might not be WebDAV conform Further, I'm not yet sure whether we actually have an actual problem to solve. Its pretty clear how it will work: a) mail clients will connect using IMAP4, the server should not deliver non-mail folders (Exchange does it that way) b) calendaring clients will connect using GroupDAV, the server should not deliver mail folders (well, and if he does, they will get filtered out due to the different resource type) Summary: solving the issue is a nice-to-have, but there is no immediate need now. > I would ask, however, that there be a clear and documented way to do > extensions to the core protocol, similar to the way IMAP and other > protocols > can advertise their available extensions. This more or less depends on the extension in question. A lot of that is already covered by HTTP (accept-* headers and OPTIONS request), maybe this is sufficient for what you have in mind, maybe not. Only you can tell ;-) So please be specific on what extensions you think of and if possible give a suggestion on how to implement a capability discovery of the extension using HTTP/WebDAV/DASL. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From ajc@uncensored.citadel.org Sun Jan 16 16:03:02 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 1A8E33CE247 for ; Sun, 16 Jan 2005 16:03:02 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 31297-01 for ; Sun, 16 Jan 2005 16:03:01 +0100 (CET) Received: from uncensored.citadel.org (p78-90.acedsl.com [66.114.78.90]) by mail.opengroupware.org (mail) with SMTP id 3CC453CE243 for ; Sun, 16 Jan 2005 16:02:35 +0100 (CET) From: Art Cancro To: Date: Sun Jan 16 10:02:50 EST 2005 Message-Id: <20050116150235.3CC453CE243@mail.opengroupware.org> X-Virus-Scanned: by a leet scanner. X-Amavis-Alert: BAD HEADER Improper folded header field made up entirely of whitespace (char 00 hex) in message header 'Date' ^ X-Spam-Status: No, hits=0.8 tagged_above=-999.0 required=5.0 tests=BAYES_00, MSGID_FROM_MTA_SHORT, PORN_4 X-Spam-Level: Subject: [Groupdav] mail in GroupDAV Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: As Citadel's implementation of GroupDAV begins I will try a couple of things and see if any of them look usable as a proposed extension. One of the things I'd really like to achieve, if possible, is to avoid requiring users to separately specify their IMAP, SMTP, LDAP, and GroupDAV servers ... even if they're all the same host. High-end commercial groupware systems don't require this (just point to your Groupwise or Exchange host once, specify your username, and call it a day) and I think we should aim to make that possible too. Keep in mind that I'm only a part-time developer -- my day job is in the server hosting business, so I see how this stuff gets deployed in the real world, and not just in a single user community either. A system which is difficult for the end user to configure means many additional hours of calls to the help desk, and decision-makers use this as one of their criteria when they are deciding which groupware system to use. We don't want OGo, Citadel, or whoever else passed up for Groupwise or Exchange simply because we couldn't deliver a system that at least *appears* unified. Now, maybe that doesn't involve the actual delivery of mail through GroupDAV, or even the enumeration of available IMAP URL's through GroupDAV. Perhaps we just need a couple of quick links that the GroupDAV server can use to tell the client "Your IMAP server is at www.xxx.com, and your SMTP server is at www.xxx.com; use those, with the same user/pass you gave me, and all will be well." Or perhaps this is a job better suited to LDAP, and we should simply recommend that implementors put their GroupDAV, IMAP, and SMTP home server addresses into each user's LDAP entry. Whatever it takes to make the act of pointing a client to an open source groupware server a ONE STEP task. This matters more than you think it does. Art Cancro From helge.hess@opengroupware.org Sun Jan 16 16:28:18 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 2A6813CE27C for ; Sun, 16 Jan 2005 16:28:18 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 00326-04 for ; Sun, 16 Jan 2005 16:28:17 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 722103CE267 for ; Sun, 16 Jan 2005 16:28:17 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 368BC2CAA12 for ; Sun, 16 Jan 2005 16:26:39 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 9CF062CA688 for ; Sun, 16 Jan 2005 16:26:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <20050116150235.3CC453CE243@mail.opengroupware.org> References: <20050116150235.3CC453CE243@mail.opengroupware.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3DD0D358-67D3-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 16:28:15 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 16. Jan 2005, at 16:02 Uhr, Art Cancro wrote: > As Citadel's implementation of GroupDAV begins I will try a couple of > things > and see if any of them look usable as a proposed extension. Thanks a lot! > One of the things I'd really like to achieve, if possible, is to avoid > requiring users to separately specify their IMAP, SMTP, LDAP, and > GroupDAV > servers ... even if they're all the same host. Your comment makes a lot of sense and I discussed it with Reinhold (though under a different scope) on the meeting: http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=1179 I'm not yet sure whether its a GroupDAV task to suggest a discovery mechanism. Actually this can quickly become VERY complicated (eg different access URLs depending on whether you are inside or outside a firewall and different URLs depending on the client). For the first revision I think we can ignore that (protocol wise)? After all it can be covered by the client (using some wizard which allows you to enter a hostname once and creates multiple accounts). *If* we add this to GroupDAV, I would probably just take the HTTPmail properties. I would like to hear some additional opinions on that (whether it belongs into GroupDAV r1 and whether the HTTPmail mechanism would be sufficient). > This matters more than you think it does. Hm, really? How do you know what I think about it? ;-) Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From awilliam@whitemice.org Sun Jan 16 16:40:10 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 337943CE27C for ; Sun, 16 Jan 2005 16:40:10 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 02577-04 for ; Sun, 16 Jan 2005 16:40:09 +0100 (CET) Received: from estate1.whitemice.org (adsl-68-79-189-145.dsl.klmzmi.ameritech.net [68.79.189.145]) by mail.opengroupware.org (mail) with ESMTP id 021523CE25F for ; Sun, 16 Jan 2005 16:40:08 +0100 (CET) Received: from 192.168.3.196 ([192.168.3.196]) (authenticated bits=0) by estate1.whitemice.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j0GFe6DJ001065 for ; Sun, 16 Jan 2005 10:40:06 -0500 Subject: Re: [Groupdav] mail in GroupDAV From: Adam Tauno Williams To: groupdav@opengroupware.org In-Reply-To: <20050116150235.3CC453CE243@mail.opengroupware.org> References: <20050116150235.3CC453CE243@mail.opengroupware.org> Content-Type: text/plain Organization: BOTWM Date: Sun, 16 Jan 2005 10:41:57 -0500 Message-Id: <1105890117.6533.10.camel@laptop01.whitemice.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.4 (estate1.whitemice.org [192.168.3.1]); Sun, 16 Jan 2005 10:40:06 -0500 (EST) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org X-Reply-To: awilliam@whitemice.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: > One of the things I'd really like to achieve, if possible, is to avoid > requiring users to separately specify their IMAP, SMTP, LDAP, and GroupDAV > servers ... even if they're all the same host. High-end commercial groupware > systems don't require this (just point to your Groupwise or Exchange host > once, specify your username, and call it a day) and I think we should aim > to make that possible too. This is a solved problem. DNS SRV records are used for clients to 'discover' the providers of LDAP and other services. This is support AFAIK only by a few open-source/LDAP related packages BUT Microsoft uses this extensively and it is in fact one of the underpinnings of an Active Directory domain. http://www.faqs.org/rfcs/rfc2782.html > they are deciding which groupware system to use. We don't want OGo, Citadel, > or whoever else passed up for Groupwise or Exchange simply because we > couldn't deliver a system that at least *appears* unified. I really think this is a client issue. Open Source clients need to support DNS SRV to solve this problem. > Or perhaps this is a job better suited to LDAP, and we should simply But then you still need to tell the client about the LDAP service. You DNS SRV and you don't need to tell them anything. They look at the domain name they are in and look up _ldap._tcp.domain.name, _smtp._tcp.domain.name, etc... > recommend that implementors put their GroupDAV, IMAP, and SMTP home server > addresses into each user's LDAP entry. Whatever it takes to make the act of > pointing a client to an open source groupware server a ONE STEP task. This > matters more than you think it does. Lets make it a ZERO step task. :) From helge.hess@opengroupware.org Sun Jan 16 17:47:51 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 570433CE28B for ; Sun, 16 Jan 2005 17:47:51 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 08882-08 for ; Sun, 16 Jan 2005 17:47:50 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 528533CE1A3 for ; Sun, 16 Jan 2005 17:47:50 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 5B0E62CBD30 for ; Sun, 16 Jan 2005 17:46:12 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id 20D052CBF94 for ; Sun, 16 Jan 2005 17:46:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <1105890117.6533.10.camel@laptop01.whitemice.org> References: <20050116150235.3CC453CE243@mail.opengroupware.org> <1105890117.6533.10.camel@laptop01.whitemice.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5B25A616-67DE-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 17:47:49 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: Hi Adam, without understanding the DNS details, I don't think this really solves the issue of profiles. So, yes, an LDAP server can say its here using DNS. But how does the client find the record of the user account? Same for GroupDAV, it could say its there, but how does the client know the entry point URL of the user? (eg http://myserver/zidestore/so/adam vs http://myserver/citadel) I don't think profiles can be easily implemented using DNS. AFAIK storing profiles in LDAP is most common, though I don't know specific RFCs either. BTW: is RFC 2782 the same like Rendevouz/ZeroConf or is it something else? Greets, Helge On 16. Jan 2005, at 16:41 Uhr, Adam Tauno Williams wrote: >> One of the things I'd really like to achieve, if possible, is to avoid >> requiring users to separately specify their IMAP, SMTP, LDAP, and >> GroupDAV >> servers ... even if they're all the same host. High-end commercial >> groupware >> systems don't require this (just point to your Groupwise or Exchange >> host >> once, specify your username, and call it a day) and I think we should >> aim >> to make that possible too. > > This is a solved problem. DNS SRV records are used for clients to > 'discover' the providers of LDAP and other services. This is support > AFAIK only by a few open-source/LDAP related packages BUT Microsoft > uses > this extensively and it is in fact one of the underpinnings of an > Active > Directory domain. > > http://www.faqs.org/rfcs/rfc2782.html > >> they are deciding which groupware system to use. We don't want OGo, >> Citadel, >> or whoever else passed up for Groupwise or Exchange simply because we >> couldn't deliver a system that at least *appears* unified. > > I really think this is a client issue. Open Source clients need to > support DNS SRV to solve this problem. > >> Or perhaps this is a job better suited to LDAP, and we should simply > > But then you still need to tell the client about the LDAP service. You > DNS SRV and you don't need to tell them anything. They look at the > domain name they are in and look up _ldap._tcp.domain.name, > _smtp._tcp.domain.name, etc... > >> recommend that implementors put their GroupDAV, IMAP, and SMTP home >> server >> addresses into each user's LDAP entry. Whatever it takes to make the >> act of >> pointing a client to an open source groupware server a ONE STEP task. >> This >> matters more than you think it does. > > Lets make it a ZERO step task. :) > > -- > Groupdav > groupdav@opengroupware.org > http://mail.opengroupware.org/mailman/listinfo/groupdav > -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From reinhold@kainhofer.com Sun Jan 16 18:59:24 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 04A2E3CE244 for ; Sun, 16 Jan 2005 18:59:24 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 20877-08 for ; Sun, 16 Jan 2005 18:59:23 +0100 (CET) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by mail.opengroupware.org (mail) with ESMTP id 4C1193CE19C for ; Sun, 16 Jan 2005 18:59:23 +0100 (CET) Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j0GHxL0C005034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 16 Jan 2005 18:59:22 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 18:59:17 +0100 User-Agent: KMail/1.7.91 References: <20050114051211.BE6283CE242@mail.opengroupware.org> <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> In-Reply-To: <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1682227.VYNVQpu9TK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501161859.20078.reinhold@kainhofer.com> X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: --nextPart1682227.VYNVQpu9TK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 14. Januar 2005 18:04 schrieb Helge Hess: > Another interesting topic in this context is whether we should really > include vjournal's in GroupDAV. It is > a) AFAIK not widely used KOrganizer, Exchange and Outlook have it... > b) also well covered for HTTP by Blogging protocols Definitely not by the blogger api 1.0. You can map some functionality of=20 journals to blogging protocols, but that's only a very limited subset as=20 compared to what is defined for VJOURNAL. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain= er --nextPart1682227.VYNVQpu9TK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB6qt4TqjEwhXvPN0RAv5bAJ4yGDAITC/1IEqefFyTubqbEW9O9QCeLv2F qzvw5/Ak/L9vW3juAM3ewkk= =CKY9 -----END PGP SIGNATURE----- --nextPart1682227.VYNVQpu9TK-- From helge.hess@opengroupware.org Sun Jan 16 19:11:43 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id A80583CE25F for ; Sun, 16 Jan 2005 19:11:43 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 26255-03 for ; Sun, 16 Jan 2005 19:11:42 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id C1C713CE244 for ; Sun, 16 Jan 2005 19:11:42 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6BFBC2CA521 for ; Sun, 16 Jan 2005 19:10:05 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id B54202CA4E7 for ; Sun, 16 Jan 2005 19:10:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501161859.20078.reinhold@kainhofer.com> References: <20050114051211.BE6283CE242@mail.opengroupware.org> <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> <200501161859.20078.reinhold@kainhofer.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1271180C-67EA-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 19:11:41 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 16. Jan 2005, at 18:59 Uhr, Reinhold Kainhofer wrote: >> b) also well covered for HTTP by Blogging protocols > Definitely not by the blogger api 1.0. You can map some functionality > of > journals to blogging protocols, but that's only a very limited subset > as > compared to what is defined for VJOURNAL. What else is defined for VJOURNALs? If it is a lot more, it gets even more difficult to implement it ;-) We already have enough trouble implementing full vevents/vcards, so I would rather refrain from adding yet another complex object unless there are strong reasons for it. Remember that GroupDAV is not (only) targetted on servers which just store away the data as passed in but usually need to disassemble and map to existing functionality in a reasonable and useful way. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From reinhold@kainhofer.com Sun Jan 16 19:26:12 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 690253CE240 for ; Sun, 16 Jan 2005 19:26:12 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 26255-08 for ; Sun, 16 Jan 2005 19:26:11 +0100 (CET) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by mail.opengroupware.org (mail) with ESMTP id 941673CE19C for ; Sun, 16 Jan 2005 19:26:11 +0100 (CET) Received: from ip6-localhost (doob.fam.tuwien.ac.at [127.0.0.1]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j0GIQAe5007754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 16 Jan 2005 19:26:11 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 19:26:07 +0100 User-Agent: KMail/1.7.91 References: <20050114051211.BE6283CE242@mail.opengroupware.org> <200501161859.20078.reinhold@kainhofer.com> <1271180C-67EA-11D9-B499-000D936E5072@opengroupware.org> In-Reply-To: <1271180C-67EA-11D9-B499-000D936E5072@opengroupware.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2164542.m611OhdFcm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501161926.09364.reinhold@kainhofer.com> X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: --nextPart2164542.m611OhdFcm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 16. Januar 2005 19:11 schrieb Helge Hess: > What else is defined for VJOURNALs? rfc2445 allows attendees, recurrences, attachments, and arbitrary X-...=20 fields. In particular, apps like karm or knotes use these X-... fields to=20 store their additional data there... > Remember that GroupDAV is not (only) targetted on servers which just > store away the data as passed in but usually need to disassemble and > map to existing functionality in a reasonable and useful way. Yes. However, support for custom fields is really important. And afaik, no= =20 blogging api allows them. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain= er --nextPart2164542.m611OhdFcm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB6rHBTqjEwhXvPN0RAlUcAJwMnTVldhH1Gjg2JEJ06xhSGYUl/gCcCBVF yV5z+TC50Ric9NFqMb1ITBU= =B4Oy -----END PGP SIGNATURE----- --nextPart2164542.m611OhdFcm-- From awilliam@whitemice.org Sun Jan 16 21:28:28 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 12E953CE19E for ; Sun, 16 Jan 2005 21:28:28 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 15555-01 for ; Sun, 16 Jan 2005 21:28:27 +0100 (CET) Received: from estate1.whitemice.org (adsl-68-79-189-145.dsl.klmzmi.ameritech.net [68.79.189.145]) by mail.opengroupware.org (mail) with ESMTP id 0C0DA3CE19D for ; Sun, 16 Jan 2005 21:28:26 +0100 (CET) Received: from 192.168.3.196 ([192.168.3.196]) (authenticated bits=0) by estate1.whitemice.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j0GKSMDJ002156 for ; Sun, 16 Jan 2005 15:28:24 -0500 Subject: Re: [Groupdav] mail in GroupDAV From: Adam Tauno Williams To: groupdav@opengroupware.org In-Reply-To: <5B25A616-67DE-11D9-B499-000D936E5072@opengroupware.org> References: <20050116150235.3CC453CE243@mail.opengroupware.org> <1105890117.6533.10.camel@laptop01.whitemice.org> <5B25A616-67DE-11D9-B499-000D936E5072@opengroupware.org> Content-Type: text/plain Organization: BOTWM Date: Sun, 16 Jan 2005 15:30:14 -0500 Message-Id: <1105907415.6173.18.camel@laptop01.whitemice.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.4 (estate1.whitemice.org [192.168.3.1]); Sun, 16 Jan 2005 15:28:24 -0500 (EST) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org X-Reply-To: awilliam@whitemice.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: > without understanding the DNS details, I don't think this really solves > the issue of profiles. > So, yes, an LDAP server can say its here using DNS. But how does the > client find the record of the user account? This all depends upon the fact that the user's name is the same across systems (as would be logical in an NT4 or AD domain). The client uses it's domain to query for the service it needs, in the case of needing additional info you're correct that LDAP comes into play. The client knows the username of the user logging in and can search for the user's object. > Same for GroupDAV, it could say its there, but how does the client know > the entry point URL of the user? (eg http://myserver/zidestore/so/adam > vs http://myserver/citadel) This is a good point; and not one I'd thought of since it doesn't come into play for IMAP, SMTP, LDAP, and the like; knowing the where the service is, and the username, is enough for those. > I don't think profiles can be easily implemented using DNS. AFAIK > storing profiles in LDAP is most common, though I don't know specific > RFCs either. True. We do this for some applications, but I'm not aware of any mail clients that do so. They can't even decide on anything resembling a standard on how to query a server (the LDAP support in most mail clients really stinks). If this is to assist GroupDAV clients someone would need to acquire an OID (does OpenGroupware already have one?) and define an AUXILLIARY objectclass that allowed/required the appropriate attributes (groupdavurl, groupdavuid, etc...). attributetype ( 1.3.6.1.4.1.6921.4.1.1 NAME 'groupdavurl' DESC 'URL Entry Point To GroupDAV Service' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} SINGLE-VALUE ) attributetype ( 1.3.6.1.4.1.6921.4.1.2 NAME 'groupdavuserid' DESC 'GroupDAV useride if different than network userid') SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{64} SINGLE-VALUE ) objectclass ( 1.3.6.1.4.1.6921.4.2.1 NAME 'groupdavuser' DESC 'GroupDAV User Profile' SUP top AUXILIARY MUST ( groupdavurl ) MAY ( groupdavuserid ) ) Something like that. Then (1) client looks up LDAP server via DNS-SRV (2) searches based upon username for user's object (3) client looks up GroupDAV server via DNS-SRV (4) client connects to address with the appropriate URL and possible alternate username. Leaving the GroupDAV servername in DNS instead of LDAP makes load balancing and fail-over easier. DNS SRV can provide a list of potential servers to the client and an order in which they are supposed to try if one doesn't respond. > BTW: is RFC 2782 the same like Rendevouz/ZeroConf or is it something > else? I don't think there is any real relationship between zeroconf & DNS SRV. ZeroConf is about establishing an adhoc network, SRV is about locating existing services (I suppose a good ZeroConf client would be SRV aware, but I've never used ZeroConf/Rendevouz). From schumacher@kde.org Sat Jan 15 09:32:21 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 377D13CE25F for ; Sat, 15 Jan 2005 09:32:21 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 10699-06 for ; Sat, 15 Jan 2005 09:32:20 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mail.opengroupware.org (mail) with ESMTP id 918F73CE19E for ; Sat, 15 Jan 2005 09:32:20 +0100 (CET) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CpjM4-00074w-00 for groupdav@opengroupware.org; Sat, 15 Jan 2005 09:32:20 +0100 Received: from [80.140.113.212] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CpjM3-00038X-00 for groupdav@opengroupware.org; Sat, 15 Jan 2005 09:32:20 +0100 From: Cornelius Schumacher To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sat, 15 Jan 2005 09:32:15 +0100 User-Agent: KMail/1.7 References: <20050114051211.BE6283CE242@mail.opengroupware.org> <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> In-Reply-To: <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501150932.15836.schumacher@kde.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fd5aa51fca5cfd30953b7697951fa170 X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On Friday 14 January 2005 18:04, Helge Hess wrote: > > But GroupDAV is supposed to work with the meriad of available > OpenSource servers. Including specialized servers like for example > Bugzilla which could use GroupDAV to expose its data (instead of > requiring Kontact [and every other client] to produce a specialized > Bugzilla plugin). That's a nice idea. I would love to see an implementation for that. > Another interesting topic in this context is whether we should really > include vjournal's in GroupDAV. It is > a) AFAIK not widely used > b) also well covered for HTTP by Blogging protocols > Opinions are welcome. I would welcome the inclusion of vjournals. Many servers and clients have some kind of note object and requiring to use a blogging protocol to be able to store this on a server seems to make implementations unnecessarily complex to me. -- Cornelius Schumacher From schumacher@kde.org Sun Jan 16 17:01:05 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id E12213CE27C for ; Sun, 16 Jan 2005 17:01:04 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 04900-03 for ; Sun, 16 Jan 2005 17:01:04 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mail.opengroupware.org (mail) with ESMTP id 2B3BF3CE267 for ; Sun, 16 Jan 2005 17:01:04 +0100 (CET) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CqCpr-0003GD-00 for groupdav@opengroupware.org; Sun, 16 Jan 2005 17:01:03 +0100 Received: from [80.140.114.252] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CqCpr-0006O6-00 for groupdav@opengroupware.org; Sun, 16 Jan 2005 17:01:03 +0100 From: Cornelius Schumacher To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 17:01:00 +0100 User-Agent: KMail/1.7 References: <20050116150235.3CC453CE243@mail.opengroupware.org> In-Reply-To: <20050116150235.3CC453CE243@mail.opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501161701.00805.schumacher@kde.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fd5aa51fca5cfd30953b7697951fa170 X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On Thursday 01 January 1970 01:00, Art Cancro wrote: > > Or perhaps this is a job better suited to LDAP, and we should simply > recommend that implementors put their GroupDAV, IMAP, and SMTP home > server addresses into each user's LDAP entry. Whatever it takes to > make the act of pointing a client to an open source groupware server > a ONE STEP task. This matters more than you think it does. In Kontact we try to address this problem by providing server-specific wizards which know how things are usually set up and by trying to auto-detect server capabilities where possible. This isn't really satisfying and doesn't work 100% reliable. It would be nice if there would be a single file on the server which returns the configuration for the user, so you would only need the URL of the file (which could also be standardized to always have the same path), a username and a corresponding password. All other settings could then be taken from the file. This would make setup of access to a groupware server one step on the client. I don't know if there are already standards for this kind of stuff. If not I would suggest to use a simple XML file, something like: foo.bar.com 25 plain foo.bar.com 993 ssl plain .... ... We would certainly implement support for something like that in Kontact, if a server would offer it. -- Cornelius Schumacher From helge.hess@opengroupware.org Sun Jan 16 22:05:05 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 3E0573CE23E for ; Sun, 16 Jan 2005 22:05:05 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 18908-02 for ; Sun, 16 Jan 2005 22:05:04 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 562C73CE19C for ; Sun, 16 Jan 2005 22:05:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 9A8772CC343 for ; Sun, 16 Jan 2005 22:03:27 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id E88862CC307 for ; Sun, 16 Jan 2005 22:03:26 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501150932.15836.schumacher@kde.org> References: <20050114051211.BE6283CE242@mail.opengroupware.org> <5E3CE40E-664E-11D9-B113-000D93C1A604@opengroupware.org> <200501150932.15836.schumacher@kde.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 22:05:02 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 15. Jan 2005, at 09:32 Uhr, Cornelius Schumacher wrote: >> But GroupDAV is supposed to work with the meriad of available >> OpenSource servers. Including specialized servers like for example >> Bugzilla which could use GroupDAV to expose its data (instead of >> requiring Kontact [and every other client] to produce a specialized >> Bugzilla plugin). > That's a nice idea. I would love to see an implementation for that. Yup, wasn't there a Novell Evolution Bounty for that? Maybe we can fetch it by implementing it as a gateway server ;-) > I would welcome the inclusion of vjournals. Many servers and clients > have some kind of note object and requiring to use a blogging protocol > to be able to store this on a server seems to make implementations > unnecessarily complex to me. Complex? Blogging APIs are very simple (for sure the reason why they are so popular), and as Reinhold says: ---snip--- rfc2445 allows attendees, recurrences, attachments, and arbitrary X-... fields. ---snap--- This is quite complex and by far exceeds in what "many servers" support as "notes". Actually a note as implemented by OGo is just a text file with a title, a creation/modification date and an creator. Which is nothing else but a text/plain file stored on the WebDAV server (or a blog entry). Full RFC 2445 vjournal's as mentioned by Reinhold probably will never get implemented in OGo. I'm not convinced that full journals are relevant in any real world setups. Recurring notes? Notes with attendees? Just use a vevent for such. Anyway. If there is broad agreement that vjournal as per iCal is something which is absolutely required to have a working groupware solution, I wouldn't fight putting that into the spec. Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From helge.hess@opengroupware.org Sun Jan 16 22:15:26 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id EC1983CE23E for ; Sun, 16 Jan 2005 22:15:25 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 18908-07 for ; Sun, 16 Jan 2005 22:15:25 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id 3B8213CE19E for ; Sun, 16 Jan 2005 22:15:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 256DE2CB4A5 for ; Sun, 16 Jan 2005 22:13:48 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id B76902CB495 for ; Sun, 16 Jan 2005 22:13:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501161701.00805.schumacher@kde.org> References: <20050116150235.3CC453CE243@mail.opengroupware.org> <200501161701.00805.schumacher@kde.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 22:15:23 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 16. Jan 2005, at 17:01 Uhr, Cornelius Schumacher wrote: > In Kontact we try to address this problem by providing server-specific > wizards which know how things are usually set up and by trying to > auto-detect server capabilities where possible. This isn't really > satisfying and doesn't work 100% reliable. Yup. > It would be nice if there would be a single file on the server which > returns the configuration for the user, so you would only need the URL > of the file (which could also be standardized to always have the same > path), a username and a corresponding password. All other settings > could then be taken from the file. This would make setup of access to a > groupware server one step on the client. Yes, I think we should be able to find some LDAP objectclass which allow this. Eg I'm pretty sure that the Netscape LDAP server used to provide roaming profiles for Netscape Communicator. > I don't know if there are already standards for this kind of stuff. If > not I would suggest to use a simple XML file, something like: Something like this should definitely get coordinated with the Evolution guys prior attempting to support it. I'm not sure whether its realistic that we could find an agreement here? Especially because this is above the protocol which can be implemented using the existing storage provider APIs but instead requires support in the config panels of the core client application? > We would certainly implement support for something like that in > Kontact, > if a server would offer it. Well, GroupDAV currently doesn't require the server to be a full WebDAV server. If it *is* a full WebDAV server, you could just perform a PUT to store your configuration in some file, and say (along with some more specific content type) GET /zidestore/so/helge/kontact-config.xml PUT /zidestore/so/helge/kontact-config.xml if it fails, you know that you can't store the information on the server, if it works, great! ;-) This wouldn't allow for profile sharing between clients, but might be sufficient for Kontact. Indeed, if the server knows about Kontact and its capability to store data this way, it could pregenerate the file based on server info (OGo could do this). Summary: maybe more a Kontact specific extension? Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From reinhold@kainhofer.com Sun Jan 16 22:28:00 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id E3A6A3CE243 for ; Sun, 16 Jan 2005 22:27:59 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 22824-06 for ; Sun, 16 Jan 2005 22:27:59 +0100 (CET) Received: from doob.fam.tuwien.ac.at (doob.fam.tuwien.ac.at [128.130.51.99]) by mail.opengroupware.org (mail) with ESMTP id 207BB3CE19C for ; Sun, 16 Jan 2005 22:27:59 +0100 (CET) Received: from ip6-localhost (reinhold@curie.fam.tuwien.ac.at [128.130.51.116]) by doob.fam.tuwien.ac.at (8.13.2/8.13.2/Debian-1) with ESMTP id j0GLRvLw017714 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 16 Jan 2005 22:27:58 +0100 From: Reinhold Kainhofer Organization: Vienna University of Technology To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 22:27:53 +0100 User-Agent: KMail/1.7.91 References: <20050114051211.BE6283CE242@mail.opengroupware.org> <200501150932.15836.schumacher@kde.org> <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> In-Reply-To: <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1591254.DnyfE8i56e"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501162227.55174.reinhold@kainhofer.com> X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: --nextPart1591254.DnyfE8i56e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 16. Januar 2005 22:05 schrieb Helge Hess: > Complex? Blogging APIs are very simple (for sure the reason why they > are so popular), Yes, they are simple for a reason: They are taylored to easily publishing=20 simple texts on the web.=20 One thing all APIs are missing is to get a list of all available blog entri= es.=20 In the blogger and the metaweblog api there's only the getRecentPosts metho= d,=20 which takes a parameter numberOfPosts, which specifies how many posts shall= =20 be returned. But you can never be sure you really got all posts. > and as Reinhold says:=20 > ---snip--- > rfc2445 allows attendees, recurrences, attachments, and arbitrary X-... > fields. > ---snap--- > This is quite complex and by far exceeds in what "many servers" support > as "notes". Yep. And the only thing we in kde would really need are the X-... fields.=20 AFAIK, none of the blogging apis support such custom fields. BTW, metaweblog uses RSS, so you'll need to completely implement RSS, which= =20 allows attachments in the form of the enclosure tag. Another problem with blogging apis is that they don't allow to change the d= ate=20 of the blog posting... Once again, all that we need in KDE is summary, description, dtstart and=20 custom fields, and maybe categories. If blogging APIs support these, I have= =20 no problem with that. I just see it as an inconsistency, since for events,= =20 journals, and contacts GroupDAV defines an easy protocol, and for=20 notes/journal it specifies something completely different. Cheers, Reinhold =2D-=20 =2D----------------------------------------------------------------- Reinhold Kainhofer, Vienna, Austria email: reinhold@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintain= er --nextPart1591254.DnyfE8i56e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBB6txbTqjEwhXvPN0RAkxrAJ9Cq4UasE5yzAaH2eBRVPCVvCcxiACfYYkf l7KWAWd+chD0dkEuknalTkA= =fX5/ -----END PGP SIGNATURE----- --nextPart1591254.DnyfE8i56e-- From helge.hess@opengroupware.org Sun Jan 16 22:47:38 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id DAE963CE1B3 for ; Sun, 16 Jan 2005 22:47:38 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 27345-02 for ; Sun, 16 Jan 2005 22:47:37 +0100 (CET) Received: from mail.mdlink.net (medusa.mdlink.de [213.211.192.34]) by mail.opengroupware.org (mail) with ESMTP id D3F103CE19D for ; Sun, 16 Jan 2005 22:47:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.mdlink.net (Postfix) with ESMTP id 6039A2CC38B for ; Sun, 16 Jan 2005 22:46:01 +0100 (CET) Received: from [213.211.232.140] (port-ip-213-211-232-140.reverse.mdcc-fun.de [213.211.232.140]) by mail.mdlink.net (Postfix) with ESMTP id B04A72CC37E for ; Sun, 16 Jan 2005 22:46:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200501162227.55174.reinhold@kainhofer.com> References: <20050114051211.BE6283CE242@mail.opengroupware.org> <200501150932.15836.schumacher@kde.org> <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> <200501162227.55174.reinhold@kainhofer.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3C2D6078-6808-11D9-B499-000D936E5072@opengroupware.org> Content-Transfer-Encoding: 7bit From: Helge Hess Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 22:47:36 +0100 To: groupdav@opengroupware.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On 16. Jan 2005, at 22:27 Uhr, Reinhold Kainhofer wrote: > One thing all APIs are missing is to get a list of all available blog > entries. > In the blogger and the metaweblog api there's only the getRecentPosts > method, > which takes a parameter numberOfPosts, which specifies how many posts > shall > be returned. But you can never be sure you really got all posts. The API is sufficient to accomplish that for all practical purposes, it just doesn't have the best possible efficiency: ---snip--- fetchCount = 20; while (1) { posts = getRecentPosts(fetchCount); if (posts.length != fetchCount) break; fetchCount *= 2; } ---snap--- Do that in better steps, like 20, 100, 1000, 10000 and you have covered all cases which are relevant in practice. >> and as Reinhold says: >> ---snip--- >> rfc2445 allows attendees, recurrences, attachments, and arbitrary >> X-... >> fields. >> ---snap--- >> This is quite complex and by far exceeds in what "many servers" >> support >> as "notes". > Yep. And the only thing we in kde would really need are the X-... > fields. > AFAIK, none of the blogging apis support such custom fields. OK, I won't disagree :-) Can I assume that we agree that relying on vjournal support as per specification is unnecessarily complex? > Another problem with blogging apis is that they don't allow to change > the date > of the blog posting... Which matches notes in OGo. The creation date of a note cannot be changed (for good reason). > Once again, all that we need in KDE is summary, description, dtstart > and > custom fields, and maybe categories. If blogging APIs support these, I > have > no problem with that. I just see it as an inconsistency, since for > events, > journals, and contacts GroupDAV defines an easy protocol, and for > notes/journal it specifies something completely different. OK. The question is how we can continue in a useful way. IMHO using vjournal doesn't make sense. Even KOrg - which is the only OpenSource client which supports journals at all - doesn't support the RFC features. One option would be that we specify a very strict subset of vjournal. Maybe even invent a new thing called a "vnote"? Something which really bothers me is the "capability" request issue. How can the server tell the client that it supports vevent except no attachments, alarms and extra properties. Or vtodo's without cycles. This is a strong requirement to allow for the goal of GroupDAV. I guess this is more or less work as in Calsify, make a categorization of features in vevent/vtodo/vjournal, then find a way to query that information. Maybe this could be done in an accept: header, like: accept: text/calendar; features=rrule-full, extra, alarms-n Greets, Helge -- http://docs.opengroupware.org/Members/helge/ OpenGroupware.org From awilliam@whitemice.org Sun Jan 16 22:59:01 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id E59F53CE1B3 for ; Sun, 16 Jan 2005 22:59:00 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 27345-05 for ; Sun, 16 Jan 2005 22:59:00 +0100 (CET) Received: from estate1.whitemice.org (adsl-68-79-189-145.dsl.klmzmi.ameritech.net [68.79.189.145]) by mail.opengroupware.org (mail) with ESMTP id B4AA33CE19C for ; Sun, 16 Jan 2005 22:58:59 +0100 (CET) Received: from 192.168.3.196 ([192.168.3.196]) (authenticated bits=0) by estate1.whitemice.org (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id j0GLwwDJ002487 for ; Sun, 16 Jan 2005 16:58:58 -0500 Subject: Re: [Groupdav] mail in GroupDAV From: Adam Tauno Williams To: groupdav@opengroupware.org In-Reply-To: References: <20050116150235.3CC453CE243@mail.opengroupware.org> <200501161701.00805.schumacher@kde.org> Content-Type: text/plain Organization: BOTWM Date: Sun, 16 Jan 2005 17:00:51 -0500 Message-Id: <1105912851.6173.29.camel@laptop01.whitemice.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.4 (estate1.whitemice.org [192.168.3.1]); Sun, 16 Jan 2005 16:58:58 -0500 (EST) X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org X-Reply-To: awilliam@whitemice.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: > > It would be nice if there would be a single file on the server which > > returns the configuration for the user, so you would only need the URL > > of the file (which could also be standardized to always have the same > > path), a username and a corresponding password. All other settings > > could then be taken from the file. This would make setup of access to a > > groupware server one step on the client. > Yes, I think we should be able to find some LDAP objectclass which > allow this. Eg I'm pretty sure that the Netscape LDAP server used to > provide roaming profiles for Netscape Communicator. Yes, it did; was very nice. You could provide roaming profiles to netscape from any LDAP server. From schumacher@kde.org Sun Jan 16 23:57:56 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id C3C493CE1B3 for ; Sun, 16 Jan 2005 23:57:56 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 01646-06 for ; Sun, 16 Jan 2005 23:57:56 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mail.opengroupware.org (mail) with ESMTP id 195B93CE19D for ; Sun, 16 Jan 2005 23:57:56 +0100 (CET) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CqJLH-0001DF-00 for groupdav@opengroupware.org; Sun, 16 Jan 2005 23:57:55 +0100 Received: from [80.140.94.105] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CqJLH-0002Gq-00 for groupdav@opengroupware.org; Sun, 16 Jan 2005 23:57:55 +0100 From: Cornelius Schumacher To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Sun, 16 Jan 2005 23:57:52 +0100 User-Agent: KMail/1.7 References: <20050114051211.BE6283CE242@mail.opengroupware.org> <200501150932.15836.schumacher@kde.org> <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> In-Reply-To: <4A017132-6802-11D9-B499-000D936E5072@opengroupware.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501162357.52883.schumacher@kde.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fd5aa51fca5cfd30953b7697951fa170 X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On Sunday 16 January 2005 22:05, Helge Hess wrote: > On 15. Jan 2005, at 09:32 Uhr, Cornelius Schumacher wrote: > >> But GroupDAV is supposed to work with the meriad of available > >> OpenSource servers. Including specialized servers like for example > >> Bugzilla which could use GroupDAV to expose its data (instead of > >> requiring Kontact [and every other client] to produce a > >> specialized Bugzilla plugin). > > > > That's a nice idea. I would love to see an implementation for that. > > Yup, wasn't there a Novell Evolution Bounty for that? I think so, but I don't know if it got implemented. > Maybe we can > fetch it by implementing it as a gateway server ;-) Well, there is a Bugzilla resource for Kontact for quite a while. It would be nicer, though, if Bugzilla could directly offer an interface which can be understood without implementing Bugzilla-specific code. > Complex? Blogging APIs are very simple I didn't say that blogging APIs are complex. My point was that supporting a blogging API in addition to GroupDAV makes the implementations of clients more complex, because they not only have to implement HTTP, WebDAV, GroupDAV, but also RSS, XMLRPC or whatever else is needed for the blogging API. So if we can get support for notes/blog-like objects just by extending GroupDAV to use the remaining small bits of RFC2445 which specify journals, I think this would be worth the effort. That servers might not support journals and we are still lacking a way to properly communicate that, as with all other capabilities which aren't present everywhere, is a different topic which needs to be addressed separately. -- Cornelius Schumacher From schumacher@kde.org Mon Jan 17 00:07:28 2005 Return-Path: Delivered-To: groupdav@opengroupware.org Received: from localhost (mail.opengroupware.org [213.211.192.141]) by mail.opengroupware.org (mail) with ESMTP id 4B1563CE1B3 for ; Mon, 17 Jan 2005 00:07:28 +0100 (CET) Received: from mail.opengroupware.org ([213.211.192.141]) by localhost (mail [213.211.192.141]) (amavisd-new, port 10024) with ESMTP id 01646-10 for ; Mon, 17 Jan 2005 00:07:27 +0100 (CET) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mail.opengroupware.org (mail) with ESMTP id 7E2EC3CE19C for ; Mon, 17 Jan 2005 00:07:27 +0100 (CET) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1CqJUV-0004hN-00 for groupdav@opengroupware.org; Mon, 17 Jan 2005 00:07:27 +0100 Received: from [80.140.94.105] (helo=[192.168.0.3]) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1CqJUU-0004Vu-00 for groupdav@opengroupware.org; Mon, 17 Jan 2005 00:07:27 +0100 From: Cornelius Schumacher To: groupdav@opengroupware.org Subject: Re: [Groupdav] mail in GroupDAV Date: Mon, 17 Jan 2005 00:07:24 +0100 User-Agent: KMail/1.7 References: <20050116150235.3CC453CE243@mail.opengroupware.org> <200501161701.00805.schumacher@kde.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501170007.24616.schumacher@kde.org> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:fd5aa51fca5cfd30953b7697951fa170 X-Virus-Scanned: by a leet scanner. X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.0 tests=BAYES_00 X-Spam-Level: Sender: groupdav-admin@opengroupware.org Errors-To: groupdav-admin@opengroupware.org X-BeenThere: groupdav@opengroupware.org X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: groupdav@opengroupware.org List-Help: List-Post: List-Subscribe: , List-Id: Everything Groupdav List-Unsubscribe: , List-Archive: On Sunday 16 January 2005 22:15, Helge Hess wrote: > > > I don't know if there