iCalendar Source Forge Project - new

I have created a new http://SourceForge.net project - iCalendar

	https://sourceforge.net/projects/icalendar

I released the XSLT files that transform an xCal object into
an iCalendar object.

I want to open this SourceForge project open to any iCalendar
open source work.

--

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

_______________________________________________
Ietf-calsify mailing list
Ietf-calsify <at> osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Re: xCal - resubmitted.

On namespace URIs: We went through this on XMPP.  It turned out that
URIs of this form were the winner:

urn:ietf:params:xml:ns:xmpp-tls
urn:ietf:params:xml:ns:xmpp-sasl

(See RFC 3920)

I also agree that <iCalendar/> needs to be in a namespace.  I'm not
sure why it needs to be in a different namespace than <vcalendar/>,
unless you wanted to be able to put other things inside a calendar. 
I'd suggest that having two different namespaces would be unnecessary
complexity.

>From 2.7, xmlns isn't really an attribute.  You shouldn't call out how
namespaces work.  And PLEASE don't imply that prefixes are required,
or that they must take on some special value.  I want to be able to
use a doc like this:

<iCalendar xmlns='urn:ietf:params:xml:ns:xcal'>
  <vcalendar>
    <version>2.0</version>
  </vcalendar>
</iCalendar>

which is semantically identical (assuming that iCalendar moves into
the namespace).  Writing your examples in this format might make them
easier to read, as well.

If the language attribute could be mapped (special-case) on to

Fwd: RFC2518bis - tracking the things we agree on...

I thought it was worthwhile cross-posting this volunteer need -- the 
WebDAV spec could be significantly simplified and re-issued, if we get 
any more traction on resolving the issues with the current draft.  Any 
volunteers to do issue tracking or interop test/reporting?

Lisa

Begin forwarded message:

> From: Julian Reschke <julian.reschke <at> gmx.de>
> Date: September 26, 2005 2:23:54 PM PDT
> To: Lisa Dusseault <lisa <at> osafoundation.org>
> Cc: Cullen Jennings <fluffy <at> cisco.com>, WebDav <w3c-dist-auth <at> w3.org>
> Subject: Re: RFC2518bis - tracking the things we agree on...
>
>
>> Note that I've tracked a bunch of issues separately in a Word 
>> document.  This is a big document because it tracks not only every 
>> change made to RFC2518 but also why -- it was intended to link issues 
>> together with what changes were made in an attempt to resolve the 
>> issue.
>> http://ietf.webdav.org/webdav/rfc2518bis/RFC2518%20Changes.doc
>> If people are OK with me tracking issues, then I propose to move the 
>> issues table to the same location and edit it myself.
>
> i) Any volunteers for the issue tracking besides Lisa?
>
> ii) Format: whatever works. I personally prefer formats that I can 
> link to (so each issue has a stable URI), such as BugZilla URLs or 
> anchors in (X)HTML documents.

Availability of CalConnect CalDAV Use Cases Document

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

CalDAV Use Cases document from CalConnect

The CalDAV Technical Committee of The Calendaring and Scheduling Consortium
has published a document identifying use cases specifically for use with a
calendaring access protocol such as CalDAV.

The document is available from the Work Products area of the Consortium
website or at the following URL:

http://www.calconnect.org/publications/caldavusecasesv1.0.pdf

Cheers,
Bernard

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav

HTTP authentication

Talking with various potential CalDAV deployers lately, there's a 
perceived need for better HTTP authentication mechanisms: ones which 
can deal with federated identity and single sign-on.  I've also heard 
people respond "what's the problem? Put an authentication proxy in the 
proxy path" or suggest HTTP-SASL or a number of other possible 
solutions to possible problems.

So, we probably need first to discuss whether there is a problem, and 
if so, what to do about it.  There's been a suggestion to hold a BOF in 
Vancouver (if it's not too late to plan one) to see who the interested 
parties are and start defining (or defining away) the problem.  Another 
idea is to hold a workshop at some point after we've identified the 
interested parties.

Anyway, I've started a separate discussion list for this topic-- I 
didn't want to spam the general HTTP list or make people who weren't 
interested in general HTTP issues (but only in authentication for 
CalDAV/WebDAV) join that list.  Please join and chime in any time about 
what you perceive the problem or lack of problem to be or leap straight 
to what ought to be done.

http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth

Lisa

Re: HTTP authentication

May  I forward this to other interested parties?

I think it is too late to get a BOF for IETF 64, but would be happy to
work on it for the next IETF.  We could definitely have a bar bof.

_______________________________________________
Ietf-caldav mailing list -- Ietf-caldav <at> osafoundation.org
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav