Re: CAP draft

Security considerations in cap-08

In the security considerations (section 13) of the new draft it says:

'Although service provisioning is a policy matter, at a minimum, all 
implementations must provide the following tuning profiles:'

I think the must in this line should be either a MUST or a SHOULD.

I would prefer if it was a SHOULD as some countries might have problems 
(legally) with specific security technologies.

So could the line be changed to:
'Although service provisioning is a policy matter, at a minimum, all 
implementations SHOULD provide the following tuning profiles:'

Mark Davidson

Re: Security considerations in cap-08

Mark Davidson wrote:
> 
> In the security considerations (section 13) of the new draft it says:
> 
> 'Although service provisioning is a policy matter, at a minimum, all
> implementations must provide the following tuning profiles:'
> 
> I think the must in this line should be either a MUST or a SHOULD.
> 
> I would prefer if it was a SHOULD as some countries might have problems
> (legally) with specific security technologies.
> 
> So could the line be changed to:
> 'Although service provisioning is a policy matter, at a minimum, all
> implementations SHOULD provide the following tuning profiles:'
> 
> Mark Davidson

We must have a minimum set of authentication requirements or
we will not have interoperability. So the is section can only
be a MUST.

The correct thing to do is to make sure it is the correct
set of 'MUST'. In the past, Paul Hill took on this responsibility
and he consulted the security experts (for which I call him an
expert), and they concluded that DIGEST-MD5 was the correct
'MUST' to use for authentication. And I seem to recall that
they concluded that triple DES with SHA was also the correct
minimum for TLS and certificates.

Paul? - is this correct?

-Doug

Schudling an event 'asap'

How can I use iCalendar to schedule an event 'as soon as possible' i.e.
as soon as there's an available slot in a calendar?  Looking at RFC
2445, the only approach I can see is to use a non-standard property e.g.
X-DTSTART: ASAP.

Cheers,

paul

--

-- 
Paul Sharpe - Technical Director  Tel: +44 (0)1483 894158
Russell Sharpe Ltd.               Fax: +44 (0)1483 898932
The Tannery, Tannery Lane         mailto:paul <at> russellsharpe.com
Bramley, Surrey GU5 0AJ, UK

Re: Schudling an event 'asap'

Paul Sharpe wrote:
> 
> How can I use iCalendar to schedule an event 'as soon as possible' i.e.
> as soon as there's an available slot in a calendar?  Looking at RFC
> 2445, the only approach I can see is to use a non-standard property e.g.
> X-DTSTART: ASAP.

You have to get the calendars BUSY (VFREEBUSY) time and
then do an iTIP (RFC 2446) METHOD:REQUEST for the time slot.

There is no 'notification' in 2445, 2446, 2447, or CAP.

There would be some issues that would have to be worked
out to make such a request. Interesting add-on idea.

-Doug

Re: Schudling an event 'asap'

Paul,

RFC 2445 does not address your problem.  It is simply a schema.  Your
problem is specific to scheduling. I believe it would fall more in the CAP
domain (and possibly iTIP) than the iCalendar domain.

I think what you're trying to do will turn out to be a client feature rather
than something we build into a protocol RFC. We do need to make sure you
have the raw functionality to build this feature, and I believe that
functionality is present.

-Steve

Paul Sharpe wrote:

> How can I use iCalendar to schedule an event 'as soon as possible' i.e.
> as soon as there's an available slot in a calendar?  Looking at RFC
> 2445, the only approach I can see is to use a non-standard property e.g.
> X-DTSTART: ASAP.
>
> Cheers,
>
> paul
>
> --
> Paul Sharpe - Technical Director  Tel: +44 (0)1483 894158
> Russell Sharpe Ltd.               Fax: +44 (0)1483 898932
> The Tannery, Tannery Lane         mailto:paul <at> russellsharpe.com
> Bramley, Surrey GU5 0AJ, UK

[Fwd: RFC 3283 on Guide to Internet Calendaring]

WAY TO GO!

-------- Original Message --------
Subject: RFC 3283 on Guide to Internet Calendaring
Date: Mon, 08 Jul 2002 14:20:01 -0700
From: rfc-editor <at> rfc-editor.org
To: IETF-Announce: ;
CC: rfc-editor <at> rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

        RFC 3283

        Title:	    Guide to Internet Calendaring
        Author(s):  B. Mahoney, G. Babics, A. Taler
        Status:	    Informational
	Date:       June 2002
        Mailbox:    bobmah <at> mit.edu, georgeb <at> steltor.com,
                    alex <at> 0--0.org 
        Pages:      16
        Characters: 31768
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-calsch-inetcal-guide-02.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3283.txt

This document describes the various Internet calendaring and
scheduling standards and works in progress, and the relationships
between them.  Its intent is to provide a context for these
documents, assist in their understanding, and potentially aid in the
design of standards-based calendaring and scheduling systems.  The
standards addressed are RFC 2445 (iCalendar), RFC 2446 (iTIP), and
RFC 2447 (iMIP).  The work in progress addressed is "Calendar Access
Protocol" (CAP).  This document also describes issues and problems
that are not solved by these protocols, and that could be targets for
future work.

This document is a product of the Calendaring and Scheduling Working
Group of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

Examples in latest draft

Hi all,

I've been following this wg list for just a couple of months so
bear with me if this has already been discussed. While reading the
draft I noticed the following (after definition of CREATE):

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: CMD;ID=creation01:REPLY
   S: TARGET:cal.example.com
   S: BEGIN:REPLY                     <- Reply for 1st calendar create
   S: CALID:relcalz1
   S: REQUEST-STATUS:2.0
   S: END:REPLY
   S: BEGIN:VREPLY                    <- Reply for 2nd calendar create
   S: CALID:relcalz2
   S: REQUEST-STATUS:2.0
   S: END:VREPLY
   S: END:VCALENDAR

The VCALENDAR is missing the PRODID property. Moreover, VREPLY is
mispelled as REPLY.

In addition, part of the exhanges are labeled with C: and S:, and
part with I: and L:.

Bye,
	andrea

--

-- 
Andrea Campi                              mailto:a.campi <at> inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

Re: Examples in latest draft

Andrea Campi wrote:
> 
> Hi all,
> 
> I've been following this wg list for just a couple of months so
> bear with me if this has already been discussed. While reading the
> draft I noticed the following (after definition of CREATE):
> ...
>
> The VCALENDAR is missing the PRODID property. Moreover, VREPLY is
> mispelled as REPLY.

Thanks, I just edited in those fixes.

> In addition, part of the exhanges are labeled with C: and S:, and
> part with I: and L:.

This refers to the BEEP Initiator and Listener. GET-CAPABILITY
can be initiated by the CUA or CS.

3.3.1 Use of BEEP, MIME and iCalendar

   ...

   This example tells the CS to generate and return 10 UIDs to be used
   by the CUA.  (Note throughout this memo, 'C:' refers to what the CUA
   sends, 'S:' refers to what the CS sends, 'I:' refers to what the
   initiator sends, and 'L:' refers to what the listener sends.  Where
   initiator and responder are used as defined in [BEEP].)

-Doug

Re: Examples in latest draft

On Tue, Jul 09, 2002 at 12:15:15PM -0600, Doug Royer wrote:
> 
> Andrea Campi wrote:
> > 
> > The VCALENDAR is missing the PRODID property. Moreover, VREPLY is
> > mispelled as REPLY.
> 
> Thanks, I just edited in those fixes.

Great, thanks. By the way, I only mentioned CREATE as an example, but
it wasn't the only one missing PRODID...

>  
> > In addition, part of the exhanges are labeled with C: and S:, and
> > part with I: and L:.
> 
> This refers to the BEEP Initiator and Listener. GET-CAPABILITY
> can be initiated by the CUA or CS.
> 

Right, I see it now.

> 
> -Doug

Bye,
	Andrea

--

-- 
Andrea Campi                              mailto:a.campi <at> inet.it
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy