CALSCH Action Items

This is a list of action items for the CALSCH Working Group.
This list will be sent out once a week and updated as often
as practical (That means if I am not available it may take
an extra week or two before you see your changes).

Updates should be sent to mailto:ietf-calendar <at> imc.org or to myself
mailto:Doug.Royer <at> Sun.COM .

There are three parts to this action list:

	(W) Working group action items.
	(C) CAP editor action items.
	(I) iCalendar action items (Frank Dawson)

Each action item will be assigned a unique ID that will aid in
tracking the items.

------------------------------------------------------------------------------

			Working Group Action Items   

Where Resolution is one of:

	U - undecided.
	Y - Chair determined consensus is in favor of the proposal.
	N - Chair determined consensus is NOT in favor of the proposal.
	D - Dropped. Chair has decided that it may never reach consensus.

 The following are a list of proposals and their status in the WG:

Re: Implementing ..?

Transport data mixed with Application data?

Can anyone come up with an example of a CAP command that returns both
transport AND application level data? I don't think we have one yet.

Several of you spoke with me after the Oslo meeting and indicated that
the "capabilities" information we returned in the example we covered was
really all application-level data. I tend to agree with that.

The response to a CAP command currently has this general form:

     <replycode> ; text ;  more text  <CRLF>
     [<application-level-data>] <CRLF>.<CRLF>

If there's really a need to return transport level stuff in the same
reply, then we'll need to change it.

Please respond if you see a problem with this.

-Steve

Re: RFC-2445: ABNF/prose mismatch on parameters

Works for me.

bob

> From: pregen <at> egenconsulting.com
> To: ietf-calendar <at> imc.org
> Subject: Re: RFC-2445: ABNF/prose mismatch on parameters
> Date: Tue, 27 Jul 1999 21:01:40 GMT
> X-Priority: 3 (Normal)
> X-MIMETrack: Serialize by Router on Notes1/Egen Consulting/01(Release 5.0 
|March 30, 1999) at 07/27/99 05:01:42 PM, Serialize complete at 07/27/99 
05:01:42 PM
> MIME-Version: 1.0
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:ietf-calendar-request <at> imc.org?body=unsubscribe>
> 
> Everyone else agree with this change. If so, can I hear some "electronic 
> hums" so we can get a concensus and close this item.
> ----- Forwarded by Pat R Egen/Egen Consulting/01 on 07/27/99 05:02 PM 
> -----
> 
> 
> Doug Royer <Doug.Royer <at> Sun.COM>
> Sent by: owner-ietf-calendar <at> imc.org
> 07/27/99 02:36 PM
> Please respond to Doug Royer
> 
>  
>         To:     ietf-calendar <at> imc.org
>         cc: 
>         Subject:        Re: RFC-2445: ABNF/prose mismatch on parameters
> 
> 
> 
> I think that does it.
> 
> > From: Frank_Dawson <at> lotus.com
> > Date: Mon, 26 Jul 1999 17:08:05 GMT
> > 
> > Doug (and others):
> >
> > Current ABNF says:
> >      eventc     = "BEGIN" ":" "VEVENT" CRLF
> >                                  eventprop *alarmc
> >                            "END" ":" "VEVENT" CRLF
> > 
> > Would the following combination of ABNF and comments be sufficient to 
> > address this issue? And then similar specification for other such 
> > instances in the ABNF?
> > 
> >      eventc     = "BEGIN" ":" "VEVENT" CRLF
> >                                  1*(eventprop / alarmc) ;Must have at 
> > least one eventprop
> >                            "END" ":" "VEVENT" CRLF
> > 
> > -- Frank
> 
> -Doug
> -------------------------------------------------------------------
> Doug.Royer <at> Sun.COM                               
http://playground.sun.com/~dougr
> Pager: Doug.Royer <at> Pager.Eng.Sun.com
> 801 W. El Camino #131                            Work:   (650)786-7599
> Mountain View, CA 94040                          Ham Radio: N6AAW, 
> Aviation: PP-ASEL
> 
> 

Robert Weiler
Amplitude Software Corporation
415-659-3520

CAPABILITIES, again...

Our current proposal for CAP has been to have "capabilities" information
returned as part of a successful connection, authentication, or change
of identity. The reasoning (I think) was to remove the need to send a
special command to get the server capabilities --it also makes the
command set smaller by one command..

There have been a couple of objections to this design. In particular,
there is concern over using a wireless transport or a limited bandwidth
transport. Is it bad design to force the transmission of this extra
information in response to a connection, or an authentication, or an
identity change?

What do people think?

-Steve

Re: Transport data mixed with Application data?

Sure  - SENDDATA

	CUA SENDDATA
	CUS <MIME-DATA>
	CS <TRANSPORT-PROTOCOL-REPLY>
	CS <iCAL-MIME-REPLY>
	CS ...application data...
	CS <CRLF>
	CS .
	CS <CRLF>

> Date: Mon, 02 Aug 1999 13:31:59 -0700
> From: sman <at> netscape.com (Steve Mansour)
> X-Accept-Language: en
> To: CalSched IETF <ietf-calendar <at> imc.org>
> Subject: Transport data mixed with Application data?
> List-Archive: <http://www.imc.org/ietf-calendar/mail-archive/>
> List-Unsubscribe: <mailto:ietf-calendar-request <at> imc.org?body=unsubscribe>
> 
> Can anyone come up with an example of a CAP command that returns both
> transport AND application level data? I don't think we have one yet.
> 
> Several of you spoke with me after the Oslo meeting and indicated that
> the "capabilities" information we returned in the example we covered was
> really all application-level data. I tend to agree with that.
> 
> The response to a CAP command currently has this general form:
> 
>      <replycode> ; text ;  more text  <CRLF>
>      [<application-level-data>] <CRLF>.<CRLF>
> 
> If there's really a need to return transport level stuff in the same
> reply, then we'll need to change it.
> 
> Please respond if you see a problem with this.
> 
> -Steve

-Doug
-------------------------------------------------------------------
Doug.Royer <at> Sun.COM		http://playground.sun.com/~dougr
Pager:				Doug.Royer <at> Pager.Eng.Sun.com
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

Re: CAPABILITIES, again...

> Date: Mon, 02 Aug 1999 13:43:57 -0700
> From: sman <at> netscape.com (Steve Mansour)
> 
> Our current proposal for CAP has been to have "capabilities" information
> returned as part of a successful connection, authentication, or change
> of identity. The reasoning (I think) was to remove the need to send a
> special command to get the server capabilities --it also makes the
> command set smaller by one command..

And it reduces round trip time for low bandwidth connections.

The first thing you have to do is to send a capability when connecting
to determine what AUTH method to use for authentication.

100 % of the time?

> There have been a couple of objections to this design. In particular,
> there is concern over using a wireless transport or a limited bandwidth
> transport. Is it bad design to force the transmission of this extra
> information in response to a connection, or an authentication, or an
> identity change?

What 'extra' data are you talking about?

I don't recall anyone adding any data this way.

> What do people think?

-Doug
-------------------------------------------------------------------
Doug.Royer <at> Sun.COM		http://playground.sun.com/~dougr
Pager:				Doug.Royer <at> Pager.Eng.Sun.com
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

Re: Transport data mixed with Application data?

Steve Mansour wrote, in part:
>Can anyone come up with an example of a CAP command
>that returns both transport AND application level data?

Do you mean a response to a CAP command that returns both transport and
application data? Such as the response to the SENDDATA command?

-- Frank

Re: CAPABILITIES, again...

Re: Transport data mixed with Application data?

Doug,

I don't understand your reply. We currently use this form of reply:

     <replycode> ; text ;  more text
     [<CRLF><application-level-data>]
     <CRLF>.<CRLF>

This has no place for transport-level data. It only allows the transport to
provide a reply code and optional human-readable comment data.

Below is an example reply from the draft. What is the transport-level data in
this reply? The first line has the reply code and the text. The <CRLF>.<CRLF>
is at the end. Everything in between is application-level data.  Is there any
reply that has transport-level data?

S: 2.0 ; got the request OK
S: Content-type:text/calendar; Method=RESPONSE;
S:   Optinfo=VERSION:2.1
S: Content-Transfer-Encoding: 7bit
S:
S: BEGIN:VCALENDAR
S: VERSION:2.1
S: METHOD:RESPONSE
S: TARGET:cap://cal.example.com/opaqueid99
S: CMDID:xyz12345
S: RESPONSE-STATUS:2.0
S: BEGIN:VEVENT
S: DTSTART:19990714T200000Z
S: DTEND:19990714T210000Z
S: UID:000444888929922
S: SUMMARY:Blah bla
S: END:VEVENT
S: BEGIN:VEVENT
S: UID:0034848098038888989443
S: SUMMARY:meeting
S: DTEND:19990714T233000Z
S: DTSTART:19990714T223000Z
S: END:VEVENT
S: END:VCALENDAR
S: .

-Steve

Doug Royer wrote:

> Sure  - SENDDATA
>
>         CUA SENDDATA
>         CUS <MIME-DATA>
>         CS <TRANSPORT-PROTOCOL-REPLY>
>         CS <iCAL-MIME-REPLY>
>         CS ...application data...
>         CS <CRLF>
>         CS .
>         CS <CRLF>