Subject: CAP -12 and LAST CALL (hopefully)

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 13:34:56 -0600

With the addition to the typo's that people have filed using bugzilla
and the ones on this list it looks as if CAP is almost ready
to release.

The only non-typo issue seems to be the BEEP profile. Bruce
has declared twice that it has not been discusses and proposed
no solution. So that responce is a dead end. If anyone
(including Bruce) has a proposal or objection to the BEEP
profile below - please speak up.

There has been a discussion on the 1:1 and 1:many replies
and the first time I sent the BEEP proposal below (apx JUL-7)
there have been no responces. I do not really have any choice
but to assume it is acceptable.

I'll fix the typos submitted, add the BEEP profile below.
This weekend (if I have time) I'll submit -12 and hopefully
it will be the last WG call. There have been posts asking
for issues, so obviously those asking for the issues do
not have any at this time.

Proposed Beep profile:

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 -12 (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 at least one "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 at least one "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 at least one "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.

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

         As defined in this memo.

-- 

  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: [email-masked]
Date: Mon, 11 Aug 2003 16:54:26 -0400

> and the ones on this list it looks as if CAP is almost ready

I have yet to see the diffs document for the last change that were 
promised a while ago.  Will there be one?  If not, will there be one for 
CAP 10 -> 12?

Also will there be some due diligence in addressing the issues already 
raised in the WG list over the past few months?  I would have expected the 
issues to be logged by the current author(s) as they were raised so we 
could be sure they were addressed.  Making them get reraised to be 
addressed before Last Call seems like an attempt to sweep them under the 
rug if someone does not speak up _again_...

Examples of recenty issues:

The issue of searching scoping was raised and once the issue was clear to 
everyone there was no discussion on resolving it.

The issue of busytime lookups and maintenance was rasied and I proposed a 
change but I dont know if it got into CAP 11 or the pending 12.

I had noted that only the CREATE command had the ability in the ABNF to 
actually use a VQUERY but I dont know if it was addressed in CAP 11 or the 
pending 12.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 15:50:28 -0600

> promised a while ago.  Will there be one?  If not, will there be one for 

If I do not get to it soon, feel free to use the diff tool of your
choice and post them.

> raised in the WG list over the past few months?  I would have expected 
> the issues to be logged by the current author(s) as they were raised so 
> we could be sure they were addressed.  Making them get reraised to be 

Pat has just declared on this list that the CHAIRs declare such a list,
NOT the editors. Pat - do you have any open issues?

> The issue of searching scoping was raised and once the issue was clear 
> to everyone there was no discussion on resolving it.

It was addressed in CAP-11, the ABNF updates were made and I did
comment in the CAP-11 announcement that no proposals were submitted.
Bruce- did the updates in -11 solve the problem as you see it?

> The issue of busytime lookups and maintenance was rasied and I proposed 
> a change but I dont know if it got into CAP 11 or the pending 12.

There have been lots of VFREEBUSY posts. Your proposal said
for future use:

    ...I suspect that anything that can be CREATEd in your queue needs to be
    able to get searched for so you can remove 'em, process 'em, etc.  Although
    we dont have iMIP -> CAP designed now, it may be possible in the future
   (CAP creation is not the only way to get 'em into your queue essentially).

I just re-read your reply and it did NOT include a proposal.
Your (1) - was the reason I asked the question - when are they not useless?
Your (2) - is NOT what CAP does at this time. It does not get iMIP
            messages.

So I'll ask - why do we want to store objects in CAP when NO tool
can use  them? Why not add it later if need?

> actually use a VQUERY but I dont know if it was addressed in CAP 11 or 
> the pending 12.

The XML->RFC tool may be busted. It is in my XML here and it does
not make it in to the TXT version, I'll hand edit CAP-12 (not from the XML 
source) to fix it until I can find the reason. (not sure when it
got added as it did not show up in the TXT version).

The missing text for SEARCH is (follows the ABNF):

    "The format of the request is the search command (search-cmd) followed
    by one or more (query) "VQUERY" components"

Followed by the 'Response' section and then examples of 'SEARCH'.

--

---

From: "G. Barnes" <[email-masked]>
Date: Mon, 11 Aug 2003 16:04:00 -0700 (PDT)

I've just submitted another 'bug report', that is mostly typos.  In any
event, nothing there is really an 'issue', but there were a few things that
deserve a little more publicity than just a bug report:

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

Section 3.3.1  States that 'CREATE' can be implied for iTIP objects.  What
does that mean?  That you can omit a CMD if you include an iTIP object, and
the server should infer you want to CREATE it?  If so, this should be
explained clearly, here and in 10.1 or 10.1.4.  Note that this
'implied command' probably contradicts Doug Royer's proposed BEEP profile,
which states CMDs are mandatory.

6.1.1.13  The paragraph in this section is extremely difficult to
understand. The key point, I gather, is that 'If there are two VALARM
components in a given VEVENT, then both components are tested' and if either
matches (and the STATE=BOOKED), then the UID, SUMMARY, DESCRIPTION of that
VEVENT is returned. As it reads now, the 3rd sentence says *all* UID,
SUMMARY, DESCRIPTIONS from all VEVENTs are returned if we get one match,
which is surely not right.
   Assuming this is right, a more plausible rewrite might be:

     If a query references a component and a component or property
     contained in the component, any clauses referring to the contained
     component or property must be evaluated on all of the contained
     components or properties.  If any of the contained components or
     properties match the query, and the conditions on the containing
     component are also true, the component matches the query.

     For example, in the query below, if a BOOKED VEVENT contains multiple
     VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs
     in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT
     would be included in the QUERY results.

[Someone please check my work here.  I may be missing something...]

6.1.2 'A CU's UPN MUST never be an e-mail address that is deliverable to
a different person as there is no requirement that a person's UPN MUST BE
their e-mail address'.  The logic in this sentence is contradictory (if
there's no requirement that the UPN be a person's mailing address, then why
does that imply they can't have a UPN that is someone else's e-mail address?
It would seem to imply the exact opposite).

			Greg Barnes
			Computing and Communications, University of Washington
			[email-masked]
			(206) 685-3295

---

From: [email-masked]
Date: Mon, 11 Aug 2003 18:57:52 -0400

> If I do not get to it soon, feel free to use the diff tool of your

Not my job; thats something the editor does. 

Thats NOT what she said.  She wrote:

>3.  Saying that no one responding to a comment by Bruce stops the issue 
is
>the chairs call, not the editors.

Its the chairs call if the issue is resolved or not; the list is not 
theirs to maintain.   Thats something for the editor to do.  You did it 
before so you should be familiar w/the process.

> Bruce- did the updates in -11 solve the problem as you see it?

I did not see CAP 11.  As I said I have too much to do to reread CAP 11 
front to back to find the differences.  Thats why I asked for a diff to be 
posted.  No diffs still for 10-11 so I was reposting what I could recall 
off hand.  I dont recall seeing any WG discussion of some issues like the 
fact that queryc was only in the CREATE command and no other.  I would 
expect that the ABNF for all commands would be changed such that its clear 
what commands can or cannot take queryc, etc but thats not something we 
talked about at all.

> can use  them? Why not add it later if need?

I had proposed that we reinstate the text that was removed w/o WG 
discussion or approval that was in CAP-03 thru -05 that said that the CS 
maintained the busytime data (and other stuff related to it).  I had even 
provided the snippets from 03 and 05 as reference.

Perhaps you missed that posting.

I want to be sure of what I think you are saying:  Are you claiming as the 
current CAP author that we will never support iMIP generated VFREEBUSY 
messages via CAP?  Thats what I read you to say with "when are they not 
useless?" but I could be wrong

If its possible to have them ("useless" != "never") then CAP needs to be 
able to at least clean them out if nothing else.  Even if the CS does not 
autoprocess them and craft back some kind of iMIP VFREEBUSY REPLY, if they 
can get into your queue then CAP MUST provide some way to find and remove 
them.  I would expect that SEARCH with STATE()!='BOOKED' would mean this 
so STATE() may be necessary for SEARCHing on VFREEBUSYs if only to remove 
them from your queue.  Ideally the CS would handle processing of the 
requests (subject to VCARs) and generate the proper iMIP REPLY but thats 
just an idea I have and not actually in CAP...

You misunderstood (2).  If I can CREATE a VFEEBUSY REQUEST in your queue 
by TARGETing it and the response that the CS generates is "Yes, I created 
your VFREEBUSY REQUEST" (which it logically means) then either A) CREATE 
needs to be reworked to disallow this (assuming there is some other way to 
do busytime lookups!!) or B) CREATE and SEARCH of VFREEBUSY components 
need to be beter codified to their behaviour to distinguish exactly how 
busytime is searched for in a CAP system.

And if you think no CAP client can use a busytime system then you dont 
understand the use of busytime for dong Scheduling.  Accurate busytime 
greatly improves the workflow process; missing or inaccurate busytime 
greatly degrades the process.

> got added as it did not show up in the TXT version).

This causes me some big concerns.  What else may be missing?  What else 
may be in the XML version that disappears in the TXT version that folks 
may object to but not know about?  As long as the TXT is whats submitted 
then things may be ok but its sure gonna make me leary of the TXT 
versions.  What about the HTML versions too??

> Followed by the 'Response' section and then examples of 'SEARCH'.

This is insufficient since this is not reflected in the ABNF.  In previous 
drafts we've had text to the effect of order of precedence:

   The memo also includes a formal grammar for the content type based on
   the Internet ABNF defined in [RFC 2234]. This ABNF is required for
   the implementation of parsers and to serve as the definitive
   reference when ambiguities or questions arise in interpreting the
   descriptive prose definition of the memo.

but we are missing it in CAP.  We need something like this for resolving 
future disputes or to aid in interpreation.  Otherwise its possible to 
generate ABNF accurate CAP payloads that are nonsensical or conflict w/the 
prose and we have no way to resolve the dispute.

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 18:22:07 -0600

> deserve a little more publicity than just a bug report:

Thanks - your right. I'll remove the 'optional' from the text. It
was discussed in the past.

I'll change it to:

    CREATE -  Create a new object on the CS.(Section 10.1.4)

> [Someone please check my work here.  I may be missing something...]

What you don't want an obscure wildcard? :-)

Yes and it has had a few rewrites.

> It would seem to imply the exact opposite).

I'll rewrite it into two sentences:

A CU's UPN MUST never be an e-mail address that is deliverable to a
different person. There is no requirement that a persons UPN be
their e-mail address.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Aug 2003 19:14:33 -0600

> Not my job; thats something the editor does.  

Bruce - I supplied them in the past and I have NOT seen any
other editor do such a thing. No not my 'job'. Feel free to post
a diff. When I posted them in the past to my web site you complained
because you wanted it on calsch.org (which 'I' do not own and until
recently had NO access to change the web pages.) Are you going to
complain if I post them to my webite this time?

>  >3.  Saying that no one responding to a comment by Bruce stops the issue is

I did NOT say "...that no one responding to a comment by Bruce..."
I said "Bruce has declared twice that it has not been discusses
and proposed no solution."

The reason that I said that was because you have declared twice
on this list that it has not been discussed and you did not propose
a solution.

> before so you should be familiar w/the process.

I did not declare the list resolved. I said:

    " With the addition to the typo's that people have filed using bugzilla
    and the ones on this list it looks as if CAP is almost ready
    to release.

    The only non-typo issue seems to be the BEEP profile. Bruce
    has declared twice that it has not been discusses and proposed
    no solution. So that response is a dead end. If anyone
    (including Bruce) has a proposal or objection to the BEEP
    profile below - please speak up."

And after 20+ years on IETF mailing lists, it is *RARE* for an
editor to post a list. I did in the past does not mean that I have
to do it now. If you or others have issues - PLEASE post them.

> front to back to find the differences.  Thats why I asked for a diff to 
> be posted.  No diffs still for 10-11 so I was reposting what I could 
> recall off hand.  I dont recall seeing any WG discussion of some issues 
> like the fact that queryc was only in the CREATE command and no other. 
>  I would expect that the ABNF for all commands would be changed such 
> that its clear what commands can or cannot take queryc, etc but thats 
> not something we talked about at all.

Declaring that you have not read -11 or even bothered to run
a diff yourself tells me that I can not worry and ignore your
comments about CAP until you read it for yourself. I do not
get paid to do this and I will not spend any more time with
you on the subject of CAP if you do not read the proposals.
I'll simply take your word for it - you do not know because
you do not have the time to look.

--