- Inf-IT DAV Clients - lists.mate.software

Danish translation update
by Ján Máté 19 Jul '13

19 Jul '13

Hi list, is there anyone who speaks Danish and wants to update the CalDavZAP translation? We are ready to release the next version of our clients, but the original Danish translator is not responding and there are lot of untranslated strings (marked as "// X" in rc2) in CalDavZAP since 0.8.1.1. JM

2 4

carddavmate xml login not working
by basti 19 Jul '13

19 Jul '13

Hello, we try to use Carddavmate with XML-auth to implement this in owr own software. At the moment we have the following config: Davical Server: https://kalender.myserver.de/caldav.php Carddavmate: https://kalender.myserver.de/carddavmate/ config.js var globalNetworkCheckSettings={href: location.protocol+'//'+location.hostname+(location.port ? ':'+location.port: '')+location.pathname.replace(RegExp('/+[^/]+/*(index\.html)?$'),'')+'/carddavmate/auth/', crossDomain: true, withCredentials: false, syncInterval: 0, timeOut: 30000, additionalResources: ['nx4group'], delegation: true}; /auth/config.inc <?php // auth method: generic (auth/plugins/generic_conf.inc) or ldap (auth/plugins/ldap_conf.inc) $config['auth_method']='generic'; // set to true for debugging XML response, otherwise set to false to avoid browser // to show http authentication window after unsuccessful authentication $config['auth_send_authenticate_header']=false; // successfull authentication XML specification (change the "http://www.server.com:80" to your protocol/server/port) $config['accounts']=array('resources'=>array()); // note: if you want to use regex values, then use one of the following formats (the second example is with regex modifier): 're:.*someregex.*[0-9]$' or 're|i:.*someregex.*[0-9]$' $config['accounts']['resources'][]=array( 'resource'=>array( 'type'=>array('addressbook'=>''), 'href'=>'https://kalender.myserver.de/caldav.php/'.$_SERVER['PHP_AUTH_USER'].'/', 'hreflabel'=>'', // if undefined or empty href value is used (see above) 'crossdomain'=>'true', // set to true for different protocol/server/port origin (default is null = autodetect) 'forcereadonly'=>'null', // see auth/doc/example_config_response.xml for proper use, for example: 'forcereadonly'=>array(array('collection'=>'/caldav.php/user/collection/'), array('collection'=>'re:^/caldav.php/user/collection[0-9]/$')), 'withcredentials'=>'false', // for experts only (note: if true, Access-Control-Allow-Origin "*" is not allowed) 'showheader'=>'true', // if undefined, empty or not false header is displayed 'settingsaccount'=>'true', // client properties are saved here (note: set it to true only for ONE account) 'checkcontenttype'=>'true', // check content-type in the server response (if you cannot see data in the interface /buggy server response/ you may try to disable it) 'delegation'=>'true', // see auth/doc/example_config_response.xml for proper use, for example: 'delegation'=>array(array('resource'=>'/caldav.php/user%40domain.com/'), array('resource'=>'re|i:^/caldav.php/a[b-x].+/$')), 'userauth'=>array( 'username'=>$_SERVER['PHP_AUTH_USER'], 'password'=>$_SERVER['PHP_AUTH_PW'] ), 'syncinterval'=>60000, 'timeout'=>30000, 'locktimeout'=>10000 ) ); ?> auth/generic.conf <?php // Server base URL $pluginconfig['base_url']='https://kalender.myserver.de'; // Default values are usually OK // for Davical: $pluginconfig['request']='/caldav.php'; // change only if your Davical is not installed into server root directory // for Lion server: //$pluginconfig['request']='/principals/users'; $pluginconfig['timeout']=30; ?> the xml (header) looks like: <resources xmlns="urn:com.inf-it:configuration"> <resource> <type> <addressbook></addressbook> </type> <href>https://kalender.myserver.de/caldav.php/tuser/</href> <hreflabel></hreflabel> <crossdomain>true</crossdomain> <forcereadonly>null</forcereadonly> <withcredentials>false</withcredentials> <showheader>true</showheader> <settingsaccount>true</settingsaccount> <checkcontenttype>true</checkcontenttype> <delegation>true</delegation> <userauth> <username>tuser</username> <password>123456</password> </userauth> <syncinterval>60000</syncinterval> <timeout>30000</timeout> <locktimeout>10000</locktimeout> </resource> </resources> But we cant login, the is always the login-screen shown auth/index.php <?php require_once('config.inc'); require_once('common.inc'); require_once('cross_domain.inc'); require_once('plugins/'.$config['auth_method'].'.inc'); // configured module - it defines the 'MODULE_authenticate()' function if(call_user_func($config['auth_method'].'_authenticate')!==1) { // HTTP authentication (exit if unsuccessfull) if($config['auth_send_authenticate_header']) header('WWW-Authenticate: Basic realm="Inf-IT Auth Module"'); header('HTTP/1.0 401 Unauthorized'); echo <<<HTML <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title>401 Authorization Required</title> </head> <body> <h1>Authorization Required</h1> <p>This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.</p> </body> </html> HTML; exit(0); } else { /* debug output */ exit ("here we are but login screen is still shown"); header('Content-type: text/xml; charset="utf-8"'); echo array_to_xml($config['accounts']); } ?>

2 4

CalDavZAP 0.9.1-rc2 & CardDavMATE 0.11.1-rc2
by Ján Máté 13 Jul '13

13 Jul '13

Hi all, new release candidates available: CalDavZAP: changelog: http://www.inf-it.com/caldavzap-next/changelog.txt source: http://www.inf-it.com/CalDavZAP_0.9.1-rc2.zip demo: http://www.inf-it.com/caldavzap-next/ CardDavMATE: changelog: http://www.inf-it.com/carddavmate-next/changelog.txt source: http://www.inf-it.com/CardDavMATE_0.11.1-rc2.zip demo: http://www.inf-it.com/carddavmate-next/ We currently do not have any additional confirmed issues so these releases are stable for production use. There are only few missing translation strings (will fix in the final release). As usually, do not forget to execute ./cache_update.sh! JM

1 0

RE: [Inf-IT DAVcl] All day event considered as from midnight to midnight
by Andrej Lezo 12 Jul '13

12 Jul '13

Hi Julien, This will be changed in next version. "all day" checkbox will set time on default values - start and end of business day. Regards, Andrej Lezo "Julien Métairie" <ruliane(a)ruliane.net> napísal: >Hi "list", > >When I tick the "All day" check box for an event, it is actually created >as during from 0:00 to 0:00. Here is part of the ics file : > >BEGIN:VEVENT >SUMMARY:Test >[...] >DTSTART;TZID=Europe/Paris:20130712T000000 >DTEND;TZID=Europe/Paris:20130712T000000 >END:VEVENT > >Is there a place where I can change this behavior ? > >Julien > >

7 8

All day event considered as from midnight to midnight
by "Julien Métairie" 11 Jul '13

11 Jul '13

Hi "list", When I tick the "All day" check box for an event, it is actually created as during from 0:00 to 0:00. Here is part of the ics file : BEGIN:VEVENT SUMMARY:Test [...] DTSTART;TZID=Europe/Paris:20130712T000000 DTEND;TZID=Europe/Paris:20130712T000000 END:VEVENT Is there a place where I can change this behavior ? Julien

1 0

accessing particular vcard files
by chrysn 11 Jul '13

11 Jul '13

hello, as of integrating carddav with an ikiwiki, i'd like to link to a particular contact in carddavmate. my idea is to dissect the fragment identifier of the url once the page is loaded, and if the fragment identifier is found on the server, it is opened right away so eg. http://my_server/carddavmate/#/jdoe/addresses/1234-5678-90ab-cdef.vcf would open the described contact in jdoe's address book (or whatever the semantics of the webdav server are) for viewing. two issues are to be considered imo: * authentication: if the setup needs authentication, the fragment identifier should be analyzed once login is complete. (that's where i failed to write a patch -- i could have found *some* place to invoke `globalAddressbookList.loadContactByUID()`, but not *the right* place). many such setups will already use some kind of single sign on solution (even simply basic http authentication) and won't require a login step. * identifiers might need to contain data describing which server the resource is on, possibly just the complete url. carddavmate should not expect to find the user name as part of the url, though. would you consider adding this feature? that whole scheme could be extended to directly edit (#/file.vcf?edit) or for search queries (#?search=john), but something basic would give good entry points for bigger setups, i think. likewise, actively rewriting the fragment identifer might get carddavmate a working back-button and an easy way to forward links to "the contact i have open right now", but that too is just my idea of where this feature could lead. thanks for maintaining carddavmate and caldavzap, i'm actively using them with radicale, and they work great! best regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

2 7

404 error when authenticating (with cross-domain)
by "Julien Métairie" 10 Jul '13

10 Jul '13

Hi everybody, I am trying to use CalDavZap with crossdomain. My DaviCAL installation is located at http://davical.my.domain/. My CalDavZap installation is located at http://appart.my.domain/caldavzap/. I configured my Apache vhost and set the following in config.js : var globalNetworkCheckSettings={ href: location.protocol+'//davical.my.domain/caldav.php/', hrefLabel: null, crossDomain: true, additionalResources: [], forceReadOnly: null, withCredentials: false, showHeader: true, settingsAccount: true, checkContentType: true, syncInterval: 60000, timeOut: 30000, lockTimeOut: 10000, delegation: false, ignoreAlarms: false, backgroundCalendars: [] } When I visit http://appart.my.domain/caldavzap/ I am prompted to enter credentials (in an HTML form). When I enter credentials, the following lines appear in the console (using Firefox 22.0) : OPTIONS http://davical.my.domain/caldav.php/ [HTTP/1.1 401 Unauthorized 160ms] Error: [netCheckAndCreateConfiguration: 'http://davical.my.domain/caldav.php/'] code: '404' Any idea ? Julien

3 6

carddavmate feature request
by basti 10 Jul '13

10 Jul '13

Hi, first of all the tool you have build is great, congratulations! How can I show the notice/ memo field next to the in the "address book"-column? Is it possible to include the notice/ memo field into search? Or a check-box to only search in this field? Would it be also possible to include a check box or something else to send a mail to multiple contacts at once? Regards, Basti

2 1

Shared group / user calendar
by basti 08 Jul '13

08 Jul '13

Hello @all, can anybody help me to use a shared calendar for a group? At the moment it look like group_user -> /group_user/calendar/ -> /group_user/calendar1/ Is it possible to share the calendar of a user to an other user? and see both calendars in caldavzap? Regards, Basti

2 1

CalDavZAP 0.9.1-rc1 & CardDavMATE 0.11.1-rc1
by Ján Máté 08 Jul '13

08 Jul '13

Hi all, new release candidates available: CalDavZAP: changelog: http://www.inf-it.com/caldavzap-next/changelog.txt source: http://www.inf-it.com/CalDavZAP_0.9.1-rc1.zip demo: http://www.inf-it.com/caldavzap-next/ CardDavMATE: changelog: http://www.inf-it.com/carddavmate-next/changelog.txt source: http://www.inf-it.com/CardDavMATE_0.11.1-rc1.zip demo: http://www.inf-it.com/carddavmate-next/ thanks for your bug reports! JM

3 2

mailing list archive
by Ján Máté 04 Jul '13

04 Jul '13

Hi all, mailing list archive is now public and available at: http://www.inf-it.com/mlmmj/davclients/ JM p.s.: the archive is updated hourly

1 0

Re: Bug in CalDav-Sync with deletion of repeating events
by Marten Gajda 02 Jul '13

02 Jul '13

Hi Felix, I hope you don't mind that I include the CalDavZAP mailing list (I've BBC'ed you). The problem is that Android doesn't actually delete instances of a recurring event. Instead Android creates an exception and sets the status to "cancelled". My app synchronizes the event just like that. The app could try to fix that automatically, but I think converting a "cancelled" exception to a deleted event would be wrong. The app should sync events, not modify them. What you see in CalDavZAP is a bug in the exception handling of CalDavZap. I've attached an event that shows the problem. It's a recurring event (it recurs every Tuesday, Wednesday and Thursday). The instances on 2013-07-03 and 2013-07-04 have been deleted in Android, i.e. their status is set to "CANCELLED". CalDavZap shows the original event + the exceptions. I think the correct behavior would be to show the exception crossed out. That's what most clients to with cancelled events. cheers Marten Am 02.07.2013 13:14, schrieb Felix: > Hi there, > > i am using caldav-sync on cyanogenmod 10.1 with an davical-server > 1.1.1-1 on debian and caldavzap as web-frontend. > When i have a repeating event and delete one occurence of it in android, > caldavzap still shows the deleted event in addition to a clone of the > event without repeatitions. Android does not show these events. > > Best regards, > Felix -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten(a)dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391 -- Marten Gajda Schandauer Straße 34 01309 Dresden Germany tel: +49 177 4427167 email: marten(a)dmfs.org twitter: twitter.com/dmfs_org VAT Reg. No.: DE269072391

2 1

CardDavMATE 0.11.0 and CalDavZAP 0.9.0
by Ján Máté 01 Jul '13

01 Jul '13

Hi everybody, CardDavMATE 0.11.0 and CalDavZAP 0.9.0 are released. Changelog: http://www.inf-it.com/carddavmate/changelog.txt http://www.inf-it.com/caldavzap/changelog.txt Download: http://www.inf-it.com/CardDavMATE_0.11.0.zip http://www.inf-it.com/CalDavZAP_0.9.0.zip Many thanks for your feedbacks and bugreports! JM

4 10

CalDavZAP 0.9.0rc2
by Ján Máté 28 Jun '13

28 Jun '13

Hi all, here is the version which fixes the "hanging" loader problem: http://www.inf-it.com/CalDavZAP_0.9.0rc2.zip demo: http://www.inf-it.com/caldavzap-next/ changelog: http://www.inf-it.com/caldavzap-next/changelog.txt JM

4 10

Re: [Inf-IT DAVcl] Access-Control-Expose-Headers
by Ken Murchison 29 May '13

29 May '13

Hi Ján, I think I understand what my server needs to do as you outline below. Here is an actual (partial) response to a preflight PUT request from CalDavZap: Access-Control-Max-Age: 3600 Access-Control-Allow-Headers: authorization,content-type,if-none-match,x-client Access-Control-Allow-Methods: OPTIONS, GET, HEAD, PUT, DELETE Access-Control-Allow-Methods: PROPFIND, REPORT, COPY, MOVE, LOCK, UNLOCK Access-Control-Allow-Origin: http://localhost Access-Control-Allow-Credentials: true What I'm asking is if your client would like to get the ETag from the response to the actual PUT, would the browser allow it? Do I need to include Access-Control-Expose-Headers: ETag to allow it? The reason I ask this particular question is that your client does a calendar-multiget REPORT immediately following the PUT asking for the getetag and calendar-data properties. Are you doing this because this is the only way to get the ETag, or do you want to make sure that the calendar-data is the same as what you PUT, or both? Obviously, the ETag should be available in the PUT response and if you use the Prefer:return=representation header, the server might also give you the calendar-data in the PUT response body saving a round-trip. See draft-snell-http-prefer <http://datatracker.ietf.org/doc/draft-snell-http-prefer/> and draft-murchison-webdav-prefer <http://datatracker.ietf.org/doc/draft-murchison-webdav-prefer/> On 05/29/2013 11:19 AM, Ján Máté wrote: > Hi Ken, > > the problem is not as simple as it looks like. We cannot use "simple" headers, because if a browser detects any cross-domain query (different protocol/domain or port), it will make a "preflight" OPTIONS request and if there are no proper CORS headers in the response, the browser will refuse to make the real request (from JavaScript). There is no way to disable these preflight requests (these are generated internally by browsers). > > Correct CORS headers for CardDavMATE/CalDavZAP looks like: > > Access-Control-Allow-Origin * > => everybody can make request to this server > > Access-Control-Allow-Methods GET,POST,OPTIONS,PROPFIND,REPORT,PUT,MOVE,DELETE,LOCK,UNLOCK > => all allowed methods (even if you return something like "unsupported" or "not implemented" for some of them) > > Access-Control-Allow-Headers User-Agent,Authorization,Content-type,Depth,If-match,If-None-Match,Lock-Token,Timeout,Destination,Overwrite,X-client,X-Requested-With > => all standard headers used by dav clients/browsers (sometime you need to add another one for new client ... so it is good to have a configuration option for additional headers) > > > JM > > > On May 29, 2013, at 4:28 PM, Ken Murchison<murch(a)andrew.cmu.edu> wrote: > >> Ján, >> >> I'm adding support for CORS requests to my server and I'm wondering if there any response headers that you need/want exposed. I'm not familiar with XMLHttpRequest so I don't know what you have access to normally. Non-simple response headers that I think might be useful: >> >> Accept-Ranges >> Content-Encoding >> Content-Location >> DAV >> ETag >> Lock-Token >> Preference-Applied >> Schedule-Tag >> >> >> Right now, your client works fine without Access-Control-Expose-Headers in the response, but I'm just trying to future-proof my code. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

Access-Control-Expose-Headers
by Ken Murchison 29 May '13

29 May '13

Ján, I'm adding support for CORS requests to my server and I'm wondering if there any response headers that you need/want exposed. I'm not familiar with XMLHttpRequest so I don't know what you have access to normally. Non-simple response headers that I think might be useful: Accept-Ranges Content-Encoding Content-Location DAV ETag Lock-Token Preference-Applied Schedule-Tag Right now, your client works fine without Access-Control-Expose-Headers in the response, but I'm just trying to future-proof my code. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ken Murchison 29 May '13

29 May '13

OK. But you still haven't bumped them up to 0.9 and 0.11 respectively. Or do you plan to do that when you actually release them? On 05/29/2013 10:59 AM, Ján Máté wrote: > These version numbers are "OK" because we have no support for "beta/rc" version comparison. So every beta/rc release is always numbered: > > *.42 > > http://en.wikipedia.org/wiki/42_(number) > > :-) > > > JM > > On May 29, 2013, at 4:14 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> On 05/21/2013 04:19 PM, Ján Máté wrote: >>> Hi everybody, >>> >>> new release candidates: >>> >>> http://www.inf-it.com/CardDavMATE_0.11rc4.zip >>> http://www.inf-it.com/CalDavZAP_0.9rc4.zip >> FYI. The version info in the X-Client request headers isn't up to date. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ken Murchison 29 May '13

29 May '13

On 05/21/2013 04:19 PM, Ján Máté wrote: > Hi everybody, > > new release candidates: > > http://www.inf-it.com/CardDavMATE_0.11rc4.zip > http://www.inf-it.com/CalDavZAP_0.9rc4.zip FYI. The version info in the X-Client request headers isn't up to date. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Discovery Via PROPFIND
by Jim Seymour 28 May '13

28 May '13

From another thread... On Mon, 20 May 2013 07:17:56 -0400 Ken Murchison <murch(a)andrew.cmu.edu> wrote: [snip] > > BTW, rather than having the admin specify the path to user principals > in config.js, you should look into doing your discovery by doing a > PROPFIND on /.well-known/caldav for DAV:current-user-principal, and > following any redirects. See http://tools.ietf.org/html/rfc6764 > What are the odds of this happening? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

CardDavMATE 0.11rc4 & CalDavZAP 0.9rc4
by Ján Máté 21 May '13

21 May '13

Hi everybody, new release candidates: http://www.inf-it.com/CardDavMATE_0.11rc4.zip http://www.inf-it.com/CalDavZAP_0.9rc4.zip RC3 -> RC4 changes: - XML requests cleanup (both clients) - added "loader" and "error" icons to the CardDavMATE resource list - CalDavZAP support for additional servers - removed obsolete functions from CalDavZAP - fixed problem with delete operation in CardDavMATE (workaround for jQuery 2.0.0 and missing reponseXML property) - proper processing of addressbook-home-set and calendar-home-set - updated IANA timezone database + related changes/fixes - removed TRANSP property from Todos JM

1 0

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available
by Ken Murchison 20 May '13

20 May '13

Actually, my power went out. I will let you know when I'm back up and running. On 5/20/2013 9:13 AM, Ján Máté wrote: > Hi Ken, > > looks like you forgot to disable your firewall. I tried to connect > from two different networks and then also using telnet: > > telnet ksmurchison.dyndns.org <http://ksmurchison.dyndns.org> 443 > Trying 76.180.197.142... > telnet: connect to address 76.180.197.142: Network is unreachable > telnet: Unable to connect to remote host > > > > JM > > > On May 20, 2013, at 1:17 PM, Ken Murchison <murch(a)andrew.cmu.edu > <mailto:murch@andrew.cmu.edu>> wrote: > >> OK, the quickest way for me to do this was to give you a test account >> on my home dev machine: > -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available
by Ken Murchison 20 May '13

20 May '13

On 05/20/2013 02:17 AM, Ján Máté wrote: > On May 20, 2013, at 2:50 AM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> I applied the caldavzap patch and the client got further along. It sees my calendars but spins trying to load them. The last request that I see if a sync-collection report. I can send telemetry of the request in the morning if you like. I *might* be able to get you access to a test account. > The fastest way to find the root of the problem is a test account. OK, the quickest way for me to do this was to give you a test account on my home dev machine: host: https://ksmurchison.dyndns.org/dav/principals/user/test01/ passwd: test01 BTW, rather than having the admin specify the path to user principals in config.js, you should look into doing your discovery by doing a PROPFIND on /.well-known/caldav for DAV:current-user-principal, and following any redirects. See http://tools.ietf.org/html/rfc6764 -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available
by Ken Murchison 20 May '13

20 May '13

I applied the caldavzap patch and the client got further along. It sees my calendars but spins trying to load them. The last request that I see if a sync-collection report. I can send telemetry of the request in the morning if you like. I *might* be able to get you access to a test account. On 05/19/2013 05:10 PM, Ján Máté wrote: > Hi Ken, > > XML requests cleanup patches for RC3 (for CardDavMATE there are also few very minor changes): > > http://www.inf-it.com/fixes/caldavzap_0.9rc4x.diff > http://www.inf-it.com/fixes/carddavmate_0.11rc4x.diff > > Please report whether these patches solve your problem. > > > JM > > > On May 19, 2013, at 7:51 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Just started testing this release, and found the following PROPFIND request: >> >> <?xml version="1.0" encoding="utf-8"?><D:propfind xmlns:x3="http://apple.com/ns/ical/" xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><x3:calendar-color/><D:current-user-privilege-set/><D:max-image-size xmlns:Dd="urn:ietf:params:xml:ns:carddav"/><D:displayname/><D:resourcetype/><D:supported-report-set/><B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/><B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/><D:sync-token/></D:prop></D:propfind> >> >> >> - You declare the caldav namespace globally (prefixed by 'C'), but then you redeclare it locally in supported-calendar-component-set (prefixed by 'B'). This is confusing my server (which is a bug on my part), but it seems to be extra unnecessary bits on the wire. >> >> - There is no standard caldav property named supported-calendar-component-sets (plural). Are you expecting this from some server or is it a typo? v0.9rc3 isn't showing any of my calendars and I'm wondering if this is the reason. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available
by Ken Murchison 19 May '13

19 May '13

On 05/19/2013 11:20 AM, Ján Máté wrote: > Hi all, > > we have a good news for you :-) > > > CalDavZAP 0.9.0 release candidate 3 - biggest changes since the rc2: > - fixed TON of bugs related to new Todo interface (especially Apple related) ... many thanks for your bug reports! > - added globalIgnoreCompletedAlarms option > - updated jQuery to 2.0.0 > - updated jQuery-UI to 1.10.3 > - Hungarian localization > > http://www.inf-it.com/CalDavZAP_0.9rc3.zip > > demo: http://www.inf-it.com/caldavzap-next/ > changelog: http://www.inf-it.com/caldavzap-next/changelog.txt > > > CardDavMATE 0.11 release candidate 3 - biggest changes since the rc2: > - this version works well with THOUSANDS of contacts (previous versions was very slow with more than several hundreds of contacts) > - updated jQuery to 2.0.0 > - updated jQuery-UI to 1.10.3 > > http://www.inf-it.com/CardDavMATE_0.11rc3.zip > > demo: http://www.inf-it.com/carddavmate-next/ > changelog: http://www.inf-it.com/carddavmate-next/changelog.txt > > > Both releases are very stable (installed on our production servers). If nobody reports any problem in ~1-2 weeks we will update few missing translation strings and will release the next public version of both clients. Just started testing this release, and found the following PROPFIND request: <?xml version="1.0" encoding="utf-8"?><D:propfind xmlns:x3="http://apple.com/ns/ical/" xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><x3:calendar-color/><D:current-user-privilege-set/><D:max-image-size xmlns:Dd="urn:ietf:params:xml:ns:carddav"/><D:displayname/><D:resourcetype/><D:supported-report-set/><B:supported-calendar-component-set xmlns:B="urn:ietf:params:xml:ns:caldav"/><B:supported-calendar-component-sets xmlns:B="urn:ietf:params:xml:ns:caldav"/><D:sync-token/></D:prop></D:propfind> - You declare the caldav namespace globally (prefixed by 'C'), but then you redeclare it locally in supported-calendar-component-set (prefixed by 'B'). This is confusing my server (which is a bug on my part), but it seems to be extra unnecessary bits on the wire. - There is no standard caldav property named supported-calendar-component-sets (plural). Are you expecting this from some server or is it a typo? v0.9rc3 isn't showing any of my calendars and I'm wondering if this is the reason. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 2

CalDavZAP 0.9rc3 + CardDavMATE 0.11rc3 available
by Ján Máté 19 May '13

19 May '13

Hi all, we have a good news for you :-) CalDavZAP 0.9.0 release candidate 3 - biggest changes since the rc2: - fixed TON of bugs related to new Todo interface (especially Apple related) ... many thanks for your bug reports! - added globalIgnoreCompletedAlarms option - updated jQuery to 2.0.0 - updated jQuery-UI to 1.10.3 - Hungarian localization http://www.inf-it.com/CalDavZAP_0.9rc3.zip demo: http://www.inf-it.com/caldavzap-next/ changelog: http://www.inf-it.com/caldavzap-next/changelog.txt CardDavMATE 0.11 release candidate 3 - biggest changes since the rc2: - this version works well with THOUSANDS of contacts (previous versions was very slow with more than several hundreds of contacts) - updated jQuery to 2.0.0 - updated jQuery-UI to 1.10.3 http://www.inf-it.com/CardDavMATE_0.11rc3.zip demo: http://www.inf-it.com/carddavmate-next/ changelog: http://www.inf-it.com/carddavmate-next/changelog.txt Both releases are very stable (installed on our production servers). If nobody reports any problem in ~1-2 weeks we will update few missing translation strings and will release the next public version of both clients. Many thanks for your feedback! JM

1 0

mailing list web archive
by Ján Máté 18 May '13

18 May '13

http://www.inf-it.com/mlmmj/ (it is updated hourly) JM p.s.: I will publish the link to the website after more testing

1 0

Re: [Inf-IT DAVcl] Firefox not displaying events
by Ken Murchison 17 May '13

17 May '13

FYI, I just checked Chrome and it works fine too. The problem appears isolated to Firefox. On 05/17/2013 05:38 PM, Ján Máté wrote: > I really don't know ... if the next RC will not fix your problem, then we can check your setup (but there are TON of fixes since the last RC, so I hope it will work). > > > JM > > > On May 17, 2013, at 11:34 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Thanks. I look forward to the fix. >> >> Just curious, why does Safari work? Does it have something to do with the format of my sync report or multiget report response and WebKit does a better job of parsing it? >> >> >> >> On 05/17/2013 05:28 PM, Ján Máté wrote: >>> Hi Ken, >>> >>> 0.8.1.1 is complatible ONLY with DAViCal. This problem is fixed (I hope) in our GIT /fixed yesterday by using a demo Baikal server/ ... just wait few days for the next release candidate (we are still working on one additional fix). >>> >>> >>> JM >>> >>> On May 17, 2013, at 11:11 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: >>> >>>> I have version 0.8.1.1 running against the server that I am developing and it works perfectly with Safari 6.0.4. However with Firefox (v20.1 on Fedora 18 and v21.0 on WinXP) when the client starts up it does not display any existing events in the calendars. It allows me to create new events and will display them until I log out. When I log back in, any events that I created no longer display. They do show up in CalDAVZap/Safari, iCal, and Lightning. >>>> >>>> Is there a config option that I need to flip in Firefox to fix this? >>>> >>>> -- >>>> Kenneth Murchison >>>> Principal Systems Software Engineer >>>> Carnegie Mellon University >>>> >>>> >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

3 3

Re: [Inf-IT DAVcl] Firefox not displaying events
by Ken Murchison 17 May '13

17 May '13

Thanks. I look forward to the fix. Just curious, why does Safari work? Does it have something to do with the format of my sync report or multiget report response and WebKit does a better job of parsing it? On 05/17/2013 05:28 PM, Ján Máté wrote: > Hi Ken, > > 0.8.1.1 is complatible ONLY with DAViCal. This problem is fixed (I hope) in our GIT /fixed yesterday by using a demo Baikal server/ ... just wait few days for the next release candidate (we are still working on one additional fix). > > > JM > > On May 17, 2013, at 11:11 PM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> I have version 0.8.1.1 running against the server that I am developing and it works perfectly with Safari 6.0.4. However with Firefox (v20.1 on Fedora 18 and v21.0 on WinXP) when the client starts up it does not display any existing events in the calendars. It allows me to create new events and will display them until I log out. When I log back in, any events that I created no longer display. They do show up in CalDAVZap/Safari, iCal, and Lightning. >> >> Is there a config option that I need to flip in Firefox to fix this? >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Firefox not displaying events
by Ken Murchison 17 May '13

17 May '13

I have version 0.8.1.1 running against the server that I am developing and it works perfectly with Safari 6.0.4. However with Firefox (v20.1 on Fedora 18 and v21.0 on WinXP) when the client starts up it does not display any existing events in the calendars. It allows me to create new events and will display them until I log out. When I log back in, any events that I created no longer display. They do show up in CalDAVZap/Safari, iCal, and Lightning. Is there a config option that I need to flip in Firefox to fix this? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Error: 'unable to save the event': unauthorized!
by Jim Seymour 17 May '13

17 May '13

Hi There, DAViCal 1.1.1 running, with several client types. Installed and got running CalDAVZap today. Browser is Firefox 21.0 on Linux Mint 13, using the Mate desktop. When I try to create an event in my calendar, I get "Error: 'unable to save the event': unauthorized!" Error Console tells me: Timestamp: 05/17/2013 04:54:35 PM Error: [Exception... "'Method not implemented' when calling method: [nsIAuthPrompt2::asyncPromptAuth]" nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

Multiple Calendars?
by Jim Seymour 17 May '13

17 May '13

Hi There, Have DAViCal server (1.1.1 with iOS patches applied) and several clients working with it. Trying CalDAVZap for a web-based solution. We have, of course, individual calendars. We'll have group calendars. (The biggest of which, in subscribers, will be the company-wide calendar.) We have individuals which will want to share calendars on a read-only basis with coworkers. Etc. I, for example, have my calendar, a resource (calendar) that is r/w by a DAViCal group, and a coworker's calendar is marked "public read." The only calendar that shows up is mine. Is it possible for CalDAVZap users to see the others? Write to the ones that should be writable by them? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

2 1

Got Some CalDAVZap Questions
by Jim Seymour 17 May '13

17 May '13

Hi There, Before I ask questions that have already been asked & answered: Is there a mailing list archive somewhere? Thanks, Jim -- Note: My mail server employs *very* aggressive anti-spam filtering. If you reply to this email and your email is rejected, please accept my apologies and let me know via my web form at <http://jimsun.LinxNet.com/contact/scform.php>.

3 2

Fwd: Re: [Tc-caldav-l] PROPPATCH on principal resources
by Ken Murchison 17 May '13

17 May '13

FYI. The message below is from some Apple folks that I know. One on the client side and one on the server side. I also received a response from one of the Oracle developers that their "server does not allow PROPPATCH on principal resources either. Calendar home or calendar collection are fine." -------- Original Message -------- Subject: Re: [Tc-caldav-l] PROPPATCH on principal resources Date: Wed, 15 May 2013 14:16:13 -0400 From: Cyrus Daboo <cyrus(a)daboo.name> To: Helge Heß <helge_hess(a)apple.com>, tc-caldav-l Reflector tc-caldav-l <tc-caldav-l(a)calconnect.org> Hi Helge, --On May 15, 2013 at 10:39:31 AM -0700 Helge Heß <helge_hess(a)apple.com> wrote: > I don't think it's a good idea even if some servers allow that (I mean > it's a good idea in pure DAV theory, but it's not a good choice in > practice ;-). Principals will be often mapped to some kind of > authentication service (say LDAP) and such rarely provide arbitrary extra > storage. > > My guess is that PROPPATCHing something into the home is probably going > to work slightly better. But it's still not required and I would expect > many servers to not support this (such where the home is not a real > physical entity, but just an entry point into e.g. a DB). > > Yet another approach would be to just PUT a non-calendar resource with > the config into the home. But again, this will only work in a few servers. > > One thing which would work universally for the client, is taking another > URL (pattern) where the client can store config information. Then the > admin of the backend server could decide where user configuration should > go. (direct it to the principal, to the home or some other, regular DAV > store). > > Summary: There is no interoperability on this :-/ Agreed. For the record our server does not support PROPPATCH of dead properties on a principal resource. With our delegate support we do allow PROPPATCH of group-member properties on the delegate resources which are children of the principal. I do think using WebDAV properties for preferences is not the best solution. In Mulberry, as a replacement for IMSP and ACAP, I ended using a simple WebDAV PUT of a properties document to a "regular" WebDAV server (not that our calendar server does not support non-calendar/address data puts in a home). The benefit of using a resource rather than properties is that conflicts can be detected (etag conditions) - that is important because multiple clients are involved. That said, it is still not ideal in that it would be nice to be able to do partial updates - but PATCH could take care of that. In any case, I suggest telling the client folks to try PROPPATCH on principals, if that fails, try the calendar home, if that fails try the default calendar (which is not ideal because it could be deleted), if that fails - fail gracefully! -- Cyrus Daboo _______________________________________________ tc-caldav-l mailing list tc-caldav-l(a)lists.calconnect.org http://lists.calconnect.org/mailman/listinfo/tc-caldav-l -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Re: [Inf-IT DAVcl] CalDavZAP and settings
by Ken Murchison 10 May '13

10 May '13

Hmm. I haven't seen Apple iCal do a PROPPATCH on anything but individual calendars or the calendar-home-set. I will see the Apple, DaviCal, Bedework, Oracle, and AOL developers the first week of June at the next CalConnect event and I will bring this up as a topic of discussion to formulate some recommended best practices. BTW, other than my few nit-picks, both of your clients look great and I will be recommending them as add-ons for our server. Keep up the good work! On 05/10/2013 01:48 AM, Ján Máté wrote: > Hi Ken, > > we use the same approach as Apple ... yes, it is not required, but usually it works. > > > JM > > On May 10, 2013, at 1:15 AM, Ken Murchison <murch(a)andrew.cmu.edu> wrote: > >> Hello, >> >> I see that the client tries to store its settings with a PROPPATCH on DAV:current-user-principal. Per RFC 3744, a server isn't required to support PROPPATCH on principal resources, which the client can probably deduce from DAV:current-user-privilege-set. I wonder if doing the PROPPATCH on CALDAV:calendar-home-set would make more sense. >> >> -- >> Kenneth Murchison >> Principal Systems Software Engineer >> Carnegie Mellon University >> >> -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

1 0

CalDavZAP and settings
by Ken Murchison 10 May '13

10 May '13

Hello, I see that the client tries to store its settings with a PROPPATCH on DAV:current-user-principal. Per RFC 3744, a server isn't required to support PROPPATCH on principal resources, which the client can probably deduce from DAV:current-user-privilege-set. I wonder if doing the PROPPATCH on CALDAV:calendar-home-set would make more sense. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

CalDavZAP calendar creation
by Ken Murchison 09 May '13

09 May '13

Hello, Are there any plans to allow this client to create calendars using either MKCALENDAR or MKCOL? -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

CalDavZAP: missing PRODID
by Ken Murchison 09 May '13

09 May '13

Hello, I just started testing this client with the CalDAV server that we are developing and I noticed that when creating an iCalendar object, the required PRODID property is missing. This violates RFC 5545 (and even the obsolete RFC 2445). -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University

2 1

Sabre_DAV_Exception_ReportNotSupported
by Florian Rauscher 12 Apr '13

12 Apr '13

Hi to all, I use ownCloud 5 with CalDavZAP last stable release. CalDavZAP can ... ... connect to ownCloud ... read the calendars from ownCloud ... write events to ownCloud (i can see it on ownClounds own calendar) but CalDavZAP can't read events. ownCloud use SabreDAV 1.7.5, i get in Firebug this error REPORT: http://user:pass@192.168.1.1/owncloud/remote.php/caldav/calendars/user/defa… 403 Forbidden Answer body: <d:errorxmlns:d="DAV:"xmlns:s="http://sabredav.org/ns"> <s:exception>*Sabre_DAV_Exception_ReportNotSupported*</s:exception> <s:message></s:message> <s:sabredav-version>1.7.5</s:sabredav-version> <d:supported-report></d:supported-report> </d:error> is there any way to get CalDavZAP to run with ownCloud. /owncloud/remote.php/caldav/principals/user/ gives return: calendar-proxy-read Proxy-Read, Principal calendar-proxy-write Proxy-Read, Principal

2 10

CalDavZAP 0.9.0 rc1 + CardDavMATE 0.11 rc2 available
by Ján Máté 10 Apr '13

10 Apr '13

Hi all, after several months of hard work we have a good news for you :-) CalDavZAP 0.9.0 release candidate 1 with completely new Todo interface and a ton of other improvements/fixes available at: http://www.inf-it.com/CalDavZAP_0.9rc1.zip demo: http://www.inf-it.com/caldavzap-next/ changelog: http://www.inf-it.com/caldavzap-next/changelog.txt CardDavMATE 0.11 release candidate 2 also with lot of improvements/fixes available at: http://www.inf-it.com/CardDavMATE_0.11rc2.zip demo: http://www.inf-it.com/carddavmate-next/ changelog: http://www.inf-it.com/carddavmate-next/changelog.txt If nobody reports any problem in ~1 week we will update some missing translations and will release the next public version of both clients. Many thanks for your feedback! JM

4 5

Using CalDAVzap with ownCloud
by Johan Vromans 26 Mar '13

26 Mar '13

I hope this is not considered off-topic ;) Has anyone succeeded in running CalDAVzap and CardDAVmate with the ownCloud server? -- Johan

2 1

Problem with crossDomain-setup
by Thomas W. 26 Mar '13

26 Mar '13

Hi, regarding the documentation I have to use the crossDomain attribute, if I want to use a caldavzap installation with the URL "https://xxx.aaa.com:443/calclient", which should use a Davical installation at URL "https://yyy.aaa.com:443/". I set the crossDomain attribute to "true", but the installation is not working. The Apache2 logging says, that there is an request to URL "https://xxx.aaa.com:443/caldav.php/", but this is wrong. What is the correct setup for this scenario? Must I use the hrefLabel attribute or something else? I also tried to modify the Apache2 Vhost config for the Davical vhost (generic allow rule), but this is not working either. Any ideas? Thanks and kind regards, Thomas

2 2

Re: [Inf-IT DAVcl] Strange behaviour
by Andrej Lezo 22 Mar '13

22 Mar '13

Hello Simon It is normal behaviour because we are using PROPATCH property for saving user settings. The request is launched with every resource synchronization. So we need support for additional methods. Best regards, Andrej Lezo Simon <caldavzap(a)svswift.de> napísal: >Hello Jan, > >I now took a look in the logs: > >When opening caldavzap I get the following: > >ROPFIND http://server/SOGo/dav/user/Calendar/ 207 Multi-Status 74ms > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus xmlns:a="http://apple.com/ns/ical/" >xmlns:D="DAV:"><D:response><D:href>/SOGo/dav/user/Calendar/</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><D:read/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><D:unbind/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege></D:current-user-privilege-set><D:displayname>Calendar</D:displayname><D:resourcetype><D:collection/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.ics</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal.xml</D:href><D:propstat><D:status>HTTP/1.1 >200 OK</D:status><D:prop><D:current-user-privilege-set >xmlns:D="DAV:"></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype/></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><a:calendar-color/><D:sync-token/></D:prop></D:propstat></D:response><D:response><D:href>/SOGo/dav/user/Calendar/personal/</D:href><D:propstat><D:status>HTTP/1.1 >200 >OK</D:status><D:prop><a:calendar-color>#84BC34FF</a:calendar-color><D:current-user-privilege-set >xmlns:n2="urn:inverse:params:xml:ns:inverse-dav" xmlns:D="DAV:" >xmlns:n1="urn:ietf:params:xml:ns:caldav"><D:privilege><D:read/></D:privilege><D:privilege><D:read-current-user-privilege-set/></D:privilege><D:privilege><n1:read-free-busy/></D:privilege><D:privilege><D:bind/></D:privilege><D:privilege><n1:schedule/></D:privilege><D:privilege><n1:schedule-post/></D:privilege><D:privilege><n1:schedule-post-vevent/></D:privilege><D:privilege><n1:schedule-post-vtodo/></D:privilege><D:privilege><n1:schedule-post-vjournal/></D:privilege><D:privilege><n1:schedule-post-vfreebusy/></D:privilege><D:privilege><n1:schedule-deliver/></D:privilege><D:privilege><n1:schedule-deliver-vevent/></D:privilege><D:privilege><n1:schedule-deliver-vtodo/></D:privilege><D:privilege><n1:schedule-deliver-vjournal/></D:privilege><D:privilege><n1:schedule-deliver-vfreebusy/></D:privilege><D:privilege><n1:schedule-respond/></D:privilege><D:privilege><n1:schedule-respond-vevent/></D:privilege><D:privilege><n1:schedule-respond-vtodo/></D:privilege><D:privilege><D:unbind/></D:privil >ege><D:privilege><D:write-properties/></D:privilege><D:privilege><D:write-content/></D:privilege><D:privilege><D:write/></D:privilege><D:privilege><D:read-acl/></D:privilege><D:privilege><D:write-acl/></D:privilege><D:privilege><n2:admin/></D:privilege><D:privilege><D:all/></D:privilege></D:current-user-privilege-set><D:displayname>Persönlicher >Kalender</D:displayname><D:resourcetype><D:collection/><calendar >xmlns="urn:ietf:params:xml:ns:caldav"/><vevent-collection >xmlns="http://groupdav.org/"/><vtodo-collection >xmlns="http://groupdav.org/"/><schedule-outbox >xmlns="urn:ietf:params:xml:ns:caldav"/></D:resourcetype></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 >404 Not >Found</D:status><D:prop><D:sync-token/></D:prop></D:propstat></D:response></D:multistatus> > > >REPORT http://server/SOGo/dav/user/Calendar/personal/ 207 Multi-Status > ><?xml version="1.0" encoding="utf-8"?> ><D:multistatus >xmlns:D="DAV:"><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/6d026dd6044076dfde4ed7ecbedeec887b0df320de9ccd95f9f7469aae99cd17.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000002"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-response><D:href>/SOGo/dav/user/Calendar/personal/c35bf93529a8a22cb079dc4d924ac359c477d2f0d60fcc88208b9bb02a14a658.ics</D:href><D:status>HTTP/1.1 >201 >Created</D:status><D:propstat><D:prop><D:getcontenttype>text/calendar</D:getcontenttype><D:getetag>"gcs00000001"</D:getetag></D:prop><D:status>HTTP/1.1 >200 >OK</D:status></D:propstat></D:sync-response><D:sync-token>1363922134</D:sync-token></D:multistatus> > >The .ics-file looks as follows: >BEGIN:VCALENDAR >VERSION:2.0 >BEGIN:VEVENT >CREATED:20130322T031033Z >LAST-MODIFIED:20130322T031532Z >DTSTAMP:20130322T031532Z >UID:b583diub-4e32-ia2p-ljmd-2yak0ufcgl5g >SUMMARY:Test3 >TRANSP:OPAQUE >CLASS:PUBLIC >DTSTART;TZID=Europe/Berlin:20130322T090000 >DTEND;TZID=Europe/Berlin:20130322T100000 >END:VEVENT >END:VCALENDAR > > >Right after the next REPORT I get the following: > >PROPPATCH http://server/SOGo/dav/user/Calendar/personal/ 403 Forbidden ><?xml version="1.0" encoding="ISO-8859-1"?> ><html xmlns="http://www.w3.org/1999/xhtml"> ><body><h3>An error occurred during object publishing</h3><p>Property >'{http://inf-it.com/ns/cal/}cal-settings' cannot be set.</p></body> ></html> > > >Yours, >Simon > >Am 06.03.2013 01:58, schrieb Ján Máté: >> Hi Simon, >> >> On Mar 6, 2013, at 1:51 AM, Simon <caldavzap(a)svswift.de> wrote: >> >>> Hey Jan, >>> >>> just tell when and how I can help (with logs or an account etc.). >>> So far: Seems really good! >>> If you are redoing the interface, could you make it so that entrys have a default starting hour (p.ex. next full hour) and an end-date which is starting hour+1 (even if one changes the starting hour). >> >> use double-click on the hour fields, and you will get: >> - the current time as "start time" and >> - current time+1 hour as "end time" (if the start and end dates are the same) or >> - the same "end time" as "start time" (if the end date is greater than start date) >> >> You can also create events using mouse (click, drag and release) and the dates/times will be predefined :-) >> >> >> JM >> >>> >>> I really like the fact that CalDAVzap uses the predefined colors from the server. >>> >>> Simon >>> >>> Am 06.03.2013 01:42, schrieb Ján Máté: >>>> Hi Simon, >>>> >>>> CalDavZAP is currently tested ONLY with DAViCal. Support for more servers will come in future - I hope in next 2-3 months (currently we are working on completely new interface for ToDo and minor bug fixes). >>>> >>>> >>>> JM >>>> >>>> >>>> On Mar 6, 2013, at 1:35 AM, Simon <caldavzap(a)svswift.de> wrote: >>>> >>>>> Hello from Passau, >>>>> >>>>> I have setup CalDAVzap with SOGo. This is working partly. >>>>> When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. >>>>> >>>>> However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. >>>>> >>>>> It seems like CalDAVzap is failing to load those entries from SOGo. >>>>> In the SOGo-Logs I see PROPFIND and REPORT. >>>>> >>>>> Any help appreciated. >>>>> >>>>> Simon >>>>> >>>> >>> >> >

3 3

Strange behaviour
by Simon 22 Mar '13

22 Mar '13

Hello from Passau, I have setup CalDAVzap with SOGo. This is working partly. When I enter an entry I can see it on all my devices (SOGo WebClient, Thunderbird and Android via CalDAV-Sync). I can edit it and everything is fine. However, after reloading CalDAVzap the entry is not shown like all entries made on my other devices. It seems like CalDAVzap is failing to load those entries from SOGo. In the SOGo-Logs I see PROPFIND and REPORT. Any help appreciated. Simon

2 4

Custom fields?
by Sven Anders 21 Mar '13

21 Mar '13

Hello! Is it possible to configure custom fields in the clients? We want to build a company wide addressbook and we need a customer number/id. I think something like would be nice: custom_fields = [ {name:'Customer Number', id:'X-CustomerNumber' }, ... ]; Regards Sven Anders -- Sven Anders <anders(a)anduras.de> () UTF-8 Ribbon Campaign /\ Support plain text e-mail ANDURAS intranet security AG Messestrasse 3 - 94036 Passau - Germany Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55 Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. - Benjamin Franklin

2 1

About v0.11rc1
by Attila Asztalos 14 Mar '13

14 Mar '13

Hi, a few things I encountered / remembered just now (currently with 0.11rc1): - At the periodic sync update (the default 60 seconds for me) the entire webpage goes void of data (the frames are still there, but address books and contacts disappear) for a few seconds, then all goes back to normal. However, it does jump back to the first contact in the address book and if I was editing a contact, the light-grey "edit mode" of the list persists, so I cannot click on other contacts unless I either log in and back out or click "edit" on the displayed contact then cancel. If there was unsaved data in the edited contact it is of course lost after this. There are no error messages in the console. I don't remember this happening before - CalDavZAP for instance still syncs very nicely in the background, all I see is the little rotating symbol. - You might want to include special Romanian chars U+015E, U+015F (s with cedilla) and U+0162, U+0163 (t with cedilla) in the sort and search alphabet strings at letter 's' and 't' respectively - I can do it in my own config but I guess it doesn't hurt to have them there by default. You might also want to include U+218, U+219 (s with comma) and U+21A, U+21B (t with comma) versions too - only one of these two version is actually supposed to exist, but which one is the correct one is a rather messy affair - interested parties can read all about it at [1] (TL;DR: cedilla is the widely supported and used one, comma is supposed to be the correct one). - Currently the address format for contacts in Romania hides the "county" field which is a very much existing, valid and used field (as also supported by [2] and [3]) called "Judet". Personally, the layout I use for "addressTypes['ro']" in "common.js" is 2 : street, 5 : code, 6 : locality, 9 : region (county), 11 : country but I guess the exact layout / order is a matter of some debate as well - even [2] and [3] contradict each other on this. To be honest, I also use the same field on Hungarian addresses as well ("Megye"), but official addressing samples don't seem to support me on this so I'm not particularly pushing for that. Regards, - Attila [1] - http://en.wikipedia.org/wiki/Romanian_alphabet#Comma-below_.28.C8.99_and_.C… [2] - http://en.wikipedia.org/wiki/Mailing_address_format_by_country#Romania [3] - http://www.posta-romana.ro/posta-romana/produse-si-servicii/Personal_subpag…

2 5

CardDavMATE 0.11rc1
by Ján Máté 13 Mar '13

13 Mar '13

Hi everybody, CardDavMATE 0.11rc1 is available at: http://www.inf-it.com/CardDavMATE_0.11rc1.zip with: - **MAJOR** performence enhancements - support for photo editing by click to the "photo box" - and many other fixes/imporovements: http://www.inf-it.com/carddavmate-next/changelog.txt demo: http://www.inf-it.com/carddavmate-next/ Much thanks for your feedback! JM

1 0

Re: vCard files
by Ján Máté 07 Mar '13

07 Mar '13

Atilla, thanks for testing the patch - here is the more optimised version + one additional fix for the PHOTO attribute: http://www.inf-it.com/fixes/data_process.js for everybody who experience the same problem with duplicate IM values or have a problem with missing photos, use the quick fix above (replace the data_process.js in CardDavMATE) ... or wait for the next version ... JM On Mar 6, 2013, at 9:29 PM, Attila Asztalos <attila.asztalos(a)gmail.com> wrote: > Hi Ján, > > Yes it does fix the duplication. Thank you. In the long run, you might want to consider parsing the X-SKYPE key too though - if I understand correctly, right now it wouldn't even show up if there were no IMPP duplicate of it in the vCard (this does not affect of course software that already does store skype IDs in both formats). > > Regards, > - Attila

1 0

regarding merging of IMPP data
by Attila Asztalos 06 Mar '13

06 Mar '13

Hi, I just noticed that something funny is going on with the IM ID data of my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so: X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id While it certainly can be argued that this is not exactly good practice (RFC4770 that defines the IMPP syntax says nothing about allowing or prohibiting the alternative notation in parallel - strictly speaking CardDavMate being entitled to interpret this as FOUR individual IDs), I think we can safely say it's reasonable to merge any number of instances of the same specific protocol AND same exact ID to a single one when presenting it to the user (reducing the above to only two IDs). Especially since this is already happening with Skype - but not with Yahoo. Could this be implemented as proposed? Regards, Attila

2 2

DAV clients vs. Chrome vs. Firefox
by Attila Asztalos 26 Feb '13

26 Feb '13

Hi all, I'm fighting with this stuff for over a week now and I have just about lost the will to live - there has to be something about my config but I have no idea what, and frankly it's a bit strange anyway: I managed to get both caldav and carddav running - but only in Chrome. So, here's the long version... - as mentioned earlier, I'm running a Baikal 0.2.4 server on top of Apache 2.2.22 with PHP 5.3.21 on a WinXP SP2 box. The Baikal folder sits inside the Apache htdocs folder, and is designated as "document root" (so "/" = "/htdocs/baikal"). The files of CalDavZap and CardDavMate are each sitting in their own "caldav" and "carddav" folders inside /htdocs/baikal/ respectively (I've briefly tried playing with other setups using virtual hosts, but even though those did work fine both with my phone and the [1] PHP test tool, I could never get either CalDavZap or CardDavMate to even authenticate so I dropped that - no virtual hosts are configured currently - that is not the issue at hand). - all this is running locally on the same Windows box I'm testing it from, currently designated as "dav.home.lan"; the port in use is the standard 80; the clients are accessed as "dav.home.lan/carddav/" and "dav.home.lan/caldav/"; the Baikal scripts are (as per default) "card.php" and "cal.php". - the browsers tested were Chrome 26.0.1410.12 beta-m and Firefox 18.0.2 - between each test and the next browsers had their caches cleared, Apache was restarted. - considering it isn't quite clear whether the Baikal URIs are supposed to end in "calendars" / "addressbooks" or "principals", I've tried both ways - neither was a complete success. Results were as follows (for brevity, accesses to inf-it are not listed): - Carddav, href: 'http://dav.home.lan/card.php/principals/' : Chrome works fine, Firefox apparently logs into an "empty session" (looks normal but all data is missing, there is no account logged in) - in fact, the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 401 ...I suppose Firefox is expected here to retry with a digest auth to the rejected basic one (as it did at line 2 after line 1), but it never does. - Carddav, href: 'http://dav.home.lan/card.php/addressbooks/' : Chrome works fine, Firefox works fine - this time, the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/ with reply 207 REPORT http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 403 PROPFIND http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 207 REPORT http://myuser:mypass@dav.home.lan/card.php/addressbooks/myuser/default/ with reply 207 etc... - Caldav, href: 'http://dav.home.lan/cal.php/principals/' : Chrome works fine, Firefox fails to log in (comes back to login prompt) then if login button is pressed again, appears to log in to an "empty session" (looks normal but all data is missing, there is no account logged in) - the exchange is: PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 401 (...nothing happens then I press "login" again...) GET http://dav.home.lan/caldav/cache.manifest with reply 200 GET http://dav.home.lan/caldav/ with reply none (not modified) GET http://dav.home.lan/caldav/cache.manifest with reply 200 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/principals/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 401 ...then nothing happens - no digest auth retry. In the error console there are two errors for the two attempts: Error: [netCheckAndCreateConfiguration: 'http://dav.home.lan/cal.php/principals/'] code: '401' (from webdav_protocol.js 138) Error: [CalDAVnetLoadABResource: 'http://myuser@dav.home.lan'] code: '401' (from webdav_protocol.js 1040) - Caldav, href: 'http://dav.home.lan/cal.php/calendars/' : Chrome gets stuck with "Loading Resource List"... PROPFIND dav.home.lan/cal.php/calendars/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/ with reply 207 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 401 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND dav.home.lan/ with reply 200 ...which can't be right: without either "cal.php" or "card.php" in the path, all that's returned is "Baikal is running OK" and I'm pretty sure caldavzap can't process that. The error console shows nothing. ...while Firefox gets stuck exactly the same way, at exactly the same spot (no errors in the console): PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/ with reply 401 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/cal.php/calendars/myuser/ with reply 207 PROPFIND http://myuser:mypass@dav.home.lan/ with reply 200 On all tries the only href variable set was "globalNetworkCheckSettings"; "globalUseJqueryAuth" was set to true; "crossDomain" was set to null, reported always as "false". Disabling all add-ons in Firefox made no difference. The problem is I normally use Firefox, not Chrome, and anyway, this is bizarre. Any idea what the heck is going on here...? If any further specific log details are needed, please let me know. Best regards and sorry for the "wall of text", - Attila [1] - https://github.com/graviox/CardDAV-PHP

2 3

CalDavZAP 0.8.1.1 released
by Ján Máté 25 Feb '13

25 Feb '13

Hi everybody, CalDavZAP 0.8.1.1 released - BIG thanks for your bug reports! http://www.inf-it.com/CalDavZAP_0.8.1.1.zip (no configuration changes, so you can use your config.js from 0.8.1) here are the patches from previous versions (for simpler upgrade): 0.8.1 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1-0.8.1.1.diff 0.8.1.1rc1 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1.1rc1-0.8.1.1.diff 0.8.1.1rc2 => 0.8.1.1 http://www.inf-it.com/CalDavZAP_0.8.1.1rc2-0.8.1.1.diff As usually, do not forget to execute cache_update.sh after you apply the patch! JM

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Inf-IT DAV Clients