Subject: RE: CAP draft - last call, etc.

From: [email-masked]
Date: Mon, 7 Jul 2003 13:27:17 -0400

Hi Satya, I agree with your comments.  That's why we do last drafts. Based 
on a conversation I had over the weekend, I don't believe the 
Recurrence-Id issue is going to impact CAP.  Frank Dawson, one of the 
original authors of iCal and iTIP has chatted with Derek, another of the 
authors and is going to give us some comments to help clear this up. 
Several people have already "sort of" agreed with Bruce's assertions 
regarding Recurrence-IDs and his opinion of what the draft means.  It is 
Bruce's job as the Methods Reviewer for those drafts to make sure changes 
to them don't break the RFC's and to interpret comments regarding those 
drafts. 

Now, back to the discussion about CAP.  I think we are ok with CAP as it 
pertains to Recurrece-ID's but that will be confirmed a bit later.  What's 
left in CAP that needs to be fixed/removed/discussed.  Bruce brought up 
Scoping.  I don't see where that was resolved.  Is it an issue?  List?

If someone sees other items in CAP that need to be 
fixed/removed/discussed, please discuss them now.  And if you have text 
that should change, provide your example as text so we can snap it into 
the draft.  That really helps the editor.

Thanks!

Satya Vempati <[email-masked]>
Sent by: [email-masked]
07/01/2003 12:46

        To:     "[email-masked]" <[email-masked]>
        cc: 
        Subject:        RE: CAP draft - last call, etc.

Some of the iCAL/iTIP questions will impact the decisions on CAP. 
Especially, the outcome of the discussion on RECURRENCE-ID fundamentally 
affects the CAP spec based on how it is eventually resolved.

IMHO, one final draft (hopefully 11) to iron out the differences is 
required before going to RFC.

-----Original Message-----

From: Doug Royer [mailto:[email-masked]]
Sent: Monday, June 30, 2003 8:19 PM
To: [email-masked]
Subject: Re: CAP draft - last call, etc.

Items that will be changed in the -11 version of the draft.

(1) Sorting is out per this WG. (I submitted my own add on draft).
(2) The ABNF will be fixed per the email on this WG.
(3) Various typos sent to me and this list.
(4) CS to generate FREEBUSY data (NOT CUA).

As of the San Francisco IETF meeting (-10 release) there have been no
other new CAP issues that seem to have reach consensus. The only
new issue seems to be if TARGET will default and I did not think
that made it past a couple of questions and opinions sent to the list.

Unless I missed something, all of the other issues are
all iCal/iTIP/iMIP issues.

PLEASE SPEAK UP if you think that something else should make the -11
version of the draft - I AM EDITING IT NOW.

Still To do:

(I) Beep profile.
(II) Document the 1:1 or 1:MANY replies.

Item (II) was discussed in S.F. and the thoughts were that
you would bundle all single TARGET replies in one blob,
and for each unique TARGET in the CS reply, the CS would
send another blob of data.

[email-masked] wrote:
> 
> Well, there's been a lot of traffic going on about all sort of issues 
> and topics.  However, it came to a halt when one note came up with what 
> may be a "show-stopper."  So, I think we need to make a decision here. 
>  Do we take items that are too hard to fix, remove them, and put in an 
> addendum that says "the following items need to be resolved in the next 
> version"?  Or do we try to take a stab at fixing them.  We need to get a 

> version of CAP into RFC status.  We need to get people interoperating so 

> we can see what's really working and what's really hosed badly.  I asked 

> for a last call and that didn't work.  We really do need to get this out 

> the door.  Therefore, I'm once again asking for a last hard look at what 

> can stay and what needs to go in the current CAP draft. If it's broken 
> and needs a lot of work - it goes out.  I am going to go back over the 
> last year's thr! eads and see what I can determine are the big issues. 
>  I'll post a note to the list with the items and will ask for a "hm" 
> from the list as to whether the item stays or goes.  If it goes, we'll 
> need help changing the draft to remove all text regarding that topic.
> 
> If you disagree with the items I post - say so.  If you agree with the 
> items - say so.  That way I know people are reading the list and will 
> agree with what we produce as the final draft. 
> 
> Cool?
> ___________________
> Patricia Egen Consulting
> www.egenconsulting.com
> 423-875-2652

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jul 2003 13:13:11 -0600

[email-masked] wrote:

> pertains to Recurrece-ID's but that will be confirmed a bit later. 
>  What's left in CAP that needs to be fixed/removed/discussed.  Bruce 
> brought up Scoping.  I don't see where that was resolved.  Is it an 
> issue?  List?

That is part of the ABNF changes that are being updated. ABNF
as many know is a real pain to write. So far there have been
no suggested fixes just those noticing issues. Which is a good
thing, suggested fixes would speed it up.

So if anyone wishes to submit ABNF changes to the list, I would
appreciate it. Not a re-write as that would cause a few month
delay as everyone reevaluated. Just updates, additions, fixes
or whatever you think would help.

Thanks!

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jul 2003 14:18:52 -0600

> the draft.  That really helps the editor.

As there have been no replies to my comments to the BEEP profile
and after re-reading the WG archives, I will put the following
into -11 (still not too late to comment on my proposal).

Beep replies will be one to one (1:1 MSG/RPY) if possible
and one to many (1:many MSG/ANS) when the TARGET changes.

    Profile Identification: specify a URI [10] that authoritatively
       identifies this profile.

		http://iana.org/beep/cap/1.0

    Message Exchanged during Channel Creation: specify the datatypes that
       may be exchanged during channel creation.

		CUAs SHOULD supply the BEEP "localize" attributes
		in the BEEP "greeting" messages.

		CSs SHOULD supply the BEEP "localize" attributes
		in the BEEP "greeting" messages.

		CUAs SHOULD supply the BEEP "serverName" attribute at
                 channel creation time to the CS so that if the CS is
		performing virtual hosting the CS can determine the
		intended virtual host. CSs that do not support virtual
		hosting may ignore the BEEP "serverName" attribute.
	
    Messages starting one-to-one exchanges: specify the datatypes that
       may be present when an exchange starts.

		The initial message each direction MUST BE single	
		"text/calendar" object containing a CAP "CAPABILITY" CMD
		and must not be part of a MIME multipart message.

		After the initial message then a BEEP "MSG" may contain
		one or more MIME objects at least one of which MUST be
		"text/calendar" and each "text/calendar" MIME object
                 MUST contain a CAP "CMD" property.

		The BEEP "MSG" messages can only contain MIME "multipart"
		MIME objects if the other endpoint has received a CAP
		"CAPABILITY" indicating the other endpoint supports
		multipart MIME objects. This does not prevent the endpoint
		from sending multiple "text/calendar" MIME objects
		in a single BEEP "MSG" so long as all of the
		"text/calendar" CAP objects have the same "TARGET"
		property value.

    Messages in positive replies: specify the datatypes that may be
       present in a positive reply.

		After the initial message then a BEEP "RPY" may contain
		one or more MIME objects at least one of which MUST be
		"text/calendar" and each "text/calendar" MIME object
                 MUST contain a CAP "CMD" property. All "text/calendar"
		MIME objects in a single BEEP "RPY" messages MUST have
		the same "TARGET" property value.

		The BEEP "RPY" messages can only contain MIME "multipart"
		MIME objects if the other endpoint has received a CAP
		"CAPABILITY" indicating the other endpoint supports
		multipart MIME objects. This does not prevent the endpoint
		from sending multiple "text/calendar" MIME objects
		in a single BEEP "RPY" so long as all of the
		"text/calendar" CAP objects have the same "TARGET"
		property value.

    Messages in negative replies: specify the datatypes that may be
       present in a negative reply.

		Any valid "text/calendar" MIME object that contains
		CAP "REQUEST-STATUS" property and a CAP "CMD" property
                 with a property value of "REPLY". And where the CS has
		determined the requested operation to be a fatal error.
		And when the CS has performed NO operation that effected
		the contents of any part of the CS or any calendar
		controlled by the CS.

    Messages in one-to-many exchanges: specify the datatypes that may be
       present in a one-to-many exchange.

		After the initial message then a BEEP "MSG" may contain
		one or more MIME objects at least one of which MUST be
		"text/calendar" and each "text/calendar" MIME object
                 MUST contain a CAP "CMD" property.

		The BEEP "MSG" messages can only contain MIME "multipart"
		MIME objects if the other endpoint has received a CAP
		"CAPABILITY" indicating the other endpoint supports
		multipart MIME objects. This does not prevent the endpoint
		from sending multiple "text/calendar" MIME objects
		in a single BEEP "MSG" so long as all of the
		"text/calendar" CAP objects have the same "TARGET"
		property value.

		The BEEP "RPY" messages can only contain MIME "multipart"
		MIME objects if the other endpoint has received a CAP
		"CAPABILITY" indicating the other endpoint supports
		multipart MIME objects. This does not prevent the endpoint
		from sending multiple "text/calendar" MIME objects
		in a single BEEP "ANS" so long as all of the
		"text/calendar" CAP objects in EACH BEEP "ANS" message
		have the same "TARGET" property value. Each unique
		"TARGET" property value per BEEP "ANS" message.

    Message Syntax: specify the syntax of the datatypes exchanged by the
       profile.

		They are CAP "text/calendar" MIME objects as specified
		in this memo. (Remember this text will be part of CAP).

    Message Semantics: specify the semantics of the datatypes exchanged
       by the profile.

		As defined in this memo. (Remember this will be part
		of CAP).

--