Subject: [Ietf-caldav] Re: HTTP authentication
From: Sam Hartman <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, WebDav WG <[email-masked]>, Mike Shaver <[email-masked]>, Scott Lawrence <[email-masked]>, HTTP working group <[email-masked]>, Alexey Melnikov <[email-masked]>, CalDAV DevList <[email-masked]>
Date: Thu, 29 Sep 2005 16:18:32 -0400
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

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.

From: Lisa Dusseault <[email-masked]>
Date: Thu, 29 Sep 2005 13:07:54 -0700
To: HTTP working group <[email-masked]>, CalDAV DevList <[email-masked]>, WebDav WG <[email-masked]>
Cc: Mike Shaver <[email-masked]>, "Paul B.Hill" <[email-masked]>, Scott Lawrence <[email-masked]>, Alexey Melnikov <[email-masked]>, Sam Hartman <[email-masked]>
Subject: [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

Date: Tue, 27 Sep 2005 11:32:34 -0400
From: Bernard Desruisseaux <[email-masked]>
To: [email-masked]
Subject: [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

Date: Tue, 27 Sep 2005 08:28:15 -0700
From: Dave Thewlis <[email-masked]>
Organization: The Calendaring and Scheduling Consortium
To: ietf-caldav list <[email-masked]>
Subject: [Ietf-caldav] Availability of CalConnect CalDAV Use Cases Document
Reply-To: [email-masked]

This is a multi-part message in MIME format.
--------------010304060001030901040408
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

TC-CALDAV, the CalDAV Technical Committee of the Calendaring and 
Scheduling Consortium, has published a document detailing use cases for 
a calendar access protocol such as CalDAV.  The document is available on 
the CalConnect web site at 
http://www.calconnect.org/publications/caldavusecasesv1.0.pdf or by 
going to http://www.calconnect.org and selecting "Work Products" from 
the sidebar index.

-- 
*Dave Thewlis, Executive Director
Calconnect - The Calendaring and Scheduling Consortium*
+1 707 840 9391 (voice) · +1 707 498 2238 (mobile)
http://www.calconnect.org · [email-masked] 
<mailto:[email-masked]>

--------------010304060001030901040408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
TC-CALDAV, the CalDAV Technical Committee of the Calendaring and
Scheduling Consortium, has published a document detailing use cases for
a calendar access protocol such as CalDAV.&nbsp; The document is available
on the CalConnect web site at <a
 href="http://www.calconnect.org/publications/caldavusecasesv1.0.pdf">http://www.calconnect.org/publications/caldavusecasesv1.0.pdf</a>
or by going to <a href="http://www.calconnect.org">http://www.calconnect.org</a>
and selecting "Work Products" from the sidebar index.<br>
<br>
<div class="moz-signature">-- <br>
<font size="-1"><b>Dave Thewlis, Executive Director<br>
Calconnect - The Calendaring and Scheduling Consortium</b><br>
+1 707 840 9391 (voice) &middot; +1 707 498 2238 (mobile)<br>
<a href="http://www.calconnect.org">http://www.calconnect.org</a> &middot; <a
 href="mailto:[email-masked]">[email-masked]</a>
</font></div>
</body>
</html>

--------------010304060001030901040408--

To: CalDAV DevList <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Date: Mon, 26 Sep 2005 15:43:08 -0700
Subject: [Ietf-caldav] Fwd: RFC2518bis - tracking the things we agree on...

--Apple-Mail-10--856466721
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

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 <[email-masked]>
> Date: September 26, 2005 2:23:54 PM PDT
> To: Lisa Dusseault <[email-masked]>
> Cc: Cullen Jennings <[email-masked]>, WebDav <[email-masked]>
> 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.

--Apple-Mail-10--856466721
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

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:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>Julian Reschke <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date:
</color></bold>September 26, 2005 2:23:54 PM PDT

<bold><color><param>0000,0000,0000</param>To: </color></bold>Lisa
Dusseault <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Cc: </color></bold>Cullen
Jennings <<[email-masked]>, WebDav <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Subject: </color>Re:
RFC2518bis - tracking the things we agree on...

</bold>

<excerpt>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.

</excerpt>

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.

</excerpt>
--Apple-Mail-10--856466721--

Date: Wed, 21 Sep 2005 00:26:52 -0600
From: Joe Hildebrand <[email-masked]>
To: [email-masked], "[email-masked]" <[email-masked]>, [email-masked], Doug Royer <[email-masked]>, CalDAV DevList <[email-masked]>, [email-masked]
Subject: Re: [Ietf-caldav] xCal - resubmitted.
Reply-To: [email-masked]

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.=20
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=3D'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
xml:lang, it would be great, since there are some tools that already
deal with xml:lang.

In 2.9, specifying that invalid XML characters MUST be entity encoded
prohibits <![CDATA[ ]]> escapes.   You might just refer to standard
XML escaping mechanisms.

I don't think 2.10 adds value.  People using XML should understand
[XMLNS] at this point.  No need to be remedial.

It might be nice to have a section about extensibility.
- extend with any XML you want, as long as it's in its own namespace
- MUST ignore any extensions you don't understand
- MUST NOT expect extensions to survive round-tripping to ical.

Once some of the namspace issues are worked out, it looks like you're
on the right track.

On 8/9/05, Julian Reschke <[email-masked]> wrote:
> Dan Connolly wrote:
> > On Tue, 2005-08-09 at 11:08 +0200, Julian Reschke wrote:
> > [...]
> >
> >>>Copies of the draft at:
> >>>
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.txt
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.html
> >>>    http://INET-Consulting.com/draft-royer-calsch-xcal-01.xml
> >>
> >>Just two quick formal comments...:
> >>
> >>1) Is it intentional that in the examples, the iCalendar container
> >>element is in no namespace?
> >>
> >>2) I don't think the IETF will let you use something like
> >>"http://ietf.org/rfc/rfcXXXX.txt" as namespace name;
> >
> >
> > Right; I gather Best Current Practice is...
> >
> > [[[
> > If the registrant wishes to
> >    have a URI assigned, then a URN of the form
> >
> >       urn:ietf:params:xml:<class>:<id>
> >
> >    will be assigned where <class> is the type of the document being
> >    registered (see below).
> > ]]]
> >  -- http://www.faqs.org/rfcs/rfc3688.html
>=20
> One could probably also use: <urn:ietf:rfc:NNNN> (see
> <http://ietf.org/rfc/rfc2648>).
>=20
> > ...
>=20
> Best regards, Julian
> _______________________________________________
> Ietf-caldav mailing list -- [email-masked]
> See http://ietf.webdav.org/caldav/ for more CalDAV resources
> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
>=20

--=20
Joe Hildebrand

Date: Sat, 03 Sep 2005 20:19:58 -0600
From: Doug Royer <[email-masked]>
Organization: IntelliCal.com
To: Calsify <[email-masked]>, CalDAV DevList <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [Ietf-caldav] iCalendar Source Forge Project - new

This is a cryptographically signed message in MIME format.

--------------ms030502060600040401020900
Content-Type: multipart/mixed; boundary="------------010704080309030704000201"

This is a multi-part message in MIME format.
--------------010704080309030704000201
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------010704080309030704000201
Content-Type: text/x-vcard; charset=utf-8;
 name="Doug.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Doug.vcf"

begin:vcard
fn:Doug Royer
n:Royer;Doug
org:INET-Consulting.com
adr:;;;;;;U.S.A
email;internet:[email-masked]
title:CEO
tel;work:866-594-8574
tel;fax:866-494-8574
note;quoted-printable:AOL: SupportUnix=0D=0A=
	MSN: [email-masked]=0D=0A=
	Yahoo: Help4Unix
x-mozilla-html:FALSE
url:http://Royer.com
version:2.1
end:vcard

--------------010704080309030704000201--

--------------ms030502060600040401020900
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030502060600040401020900--