Subject: Re: CAP Issues And To-Do List

From: Doug Royer <[email-masked]>
Date: Sun, 13 Jan 2002 10:55:12 -0700

- have decreed VCARS? If yes, need to make some changes to VCARS
  in order to allow Decreed VCARS to be identifiable.

I don't know why?
We have CARID's and if you have access to the VCARs, then
you can VQUERY for them. Do you mean you want to mandate
that all decreed VCARS have CARID's and that if you have
sufficient permission, you can view them?

If that is what you mean, then I propose that all decreed VCARS
be stored under one VCAR in the implementation with a
CARID of 'decreed'. Comments?

- DENY/GRANT does have an ordering
  see post "CAP: no ordering on GRANT/DENY?"

True. You can GRANT then later DENY, and you can DENY then
later GRANT. They are bits, not a chain of events to process.

- CALMASTER: why does it have to be a mailto: URI? Why not im:
            (when IMPP is standardized), or http: (to get a page to read
            before sending a message)? ...

The idea was that you could send email to a responsible entity.
Like hostmaster, postmaster, and so on. It is a contact entity.

 ....If it does have to be email, why
            not a bare email address rather than a URI?

So that we could later specify that it was something other
than a mailto URI. :-)

- CURRENT_DATETIME:
    * What is this for? So the CUA can synchronize its clock
      with the CS? If so, then doing it over TCP is probably
      a bad idea. NTP already provides this functionality;
      CAP shouldn't attempt to duplicate it.

I think we discussed this recently. It is my impression that the
WG list decided it would stay.

    * It says it's a DATE-TIME value, but it's returned as a
      local time and TZID. How? The DATE-TIME syntax doesn't
      have room for a TZID.

There is a TIMEZONE property also, that plus CURRENT_DATETIME
gives you everything.

- Transparency for scheduled components? What should be the default?
  Maybe specify it as a VCAR per VAGENDA: For calendar X people can
  or can not set the transparency.
  (December 2001)

So if I send you a bunch of junk, then your CS is going to
block your schedule? No. They are transparent until processed
by some CUA.

- What should the format be for relcalid? Should it be utf8?
  (December 2001)

Any valid URI. Lets not define what that means. Note to
impmlementors that URI's may be 8-bit in future.

To Register:
============

- Register Olson timezone's with IANA.
  (Does CAP really depend on this?)

No.

- Register "cap" service name for SASL with IANA
  (No longer need to do this due to BEEP?)

I think we do need to MANDATE a minimum authentication
level in CAP. As I recall from my discussions with the
area directors, it is a requirement.

ToDos:
======

- Add restriction tables to the server replies to the "schedule"
command?

Drop redundant schedule command.

- Review CAP Requirements doc to make sure that we have met
  all requirements.

- Make sure that CAP supports synch.

Synch?

- Section 8.0
  Response codes.  Need to make sure response codes in all drafts -
  iCal, iMip and iTip and examples. Error numbers need to be the same. 
Put
  text about error codes in comments below the examples (so that
  people don't look at them as being required in their text).  Pat
  will look at the codes. (Doug's list).

Same for related errors. Make sure that when CAP lists error
message, that it is what iTIP specifies for iTIP methods.

- Section 15.1.4 (now section ?)
   Submit entity for approval - John submitted to list.  Need to find.
   Get John's text and add back into CAP draft.  John submitted as a
   separate draft document. Use the MIME appeal verbiage with John's
   additional text. Point WG at John's draft and say it should be
   included in the draft.  We need to also submit to April Marine as
   well.
   See thread: "[EDITORS NOTE: John Stracke to review..."

JOHN - IT HAS BEEN OVER A YEAR - ARE YOU DONE?   :-)

- If iTIP specifies that the commands must be processed in order,
  then see do not need to specify it in CAP, since CAP must conform
  to iTIP.
  see thread: "CAP: order of processing iTIP messages"

I agree. I think that there may have been one comment that
is unique to CAP and iTIP.

- How do you identify specific counters? Can you use the ATTENDEE
  property, but is it unique. This issue seems to have come up on
  the list before with iTIP. In CAP we'll be able to retrieve specific
  components.  Make sure all itip components have unique keys.
  (December 2001)

I proposed we add SENT-BY the the METHOD in CAP. Comments?

- Add a UID to VALARMs. (December 2001.)

Add ALARMID or SEQUENCE to VALARMS. The idea is to uniquely
identify a VALARM within a component. There is no need for
it to be globally unique.

- Add the ability to use a wildcard in queries,
  if there are no objections.
  See thread: "Wildcard for component name."
  (November-December 2001)

With recent posts and the concern for understandable SQL (for
some reason :-), I think we need to remove wildcards for everything
except the SELECT clause.

---

From: George Babics <[email-masked]>
Date: Wed, 30 Jan 2002 13:31:00 -0500

> CARID of 'decreed'. Comments?

  The issue with decreed VCARs is that there is no way of telling
them apart from non-decreed VCARs.

> So that we could later specify that it was something other

  Does anyone see a reason why we should remove the restriction
  that is must be a "mailto" URI. If not think we can close this
  issue.

  An alternative is to reuse the iCalendar "CONTACT" property.
  It is already defined, thus we do not have to define CALAMASTER.
  It can also contain a phone number, name, and so forth.

>       local time and TZID. How? The DATE-TIME syntax doesn't

  This is OK by me.

> block your schedule? No. They are transparent until processed

  This is OK by me.

> impmlementors that URI's may be 8-bit in future.

  Yes it does not belong in to the do list.

>   (No longer need to do this due to BEEP?)

   Yes, it is handled by BEEP.
> area directors, it is a requirement.

  Ideas anyone?

> - Make sure that CAP supports synch.

  Synchronization.

> it to be globally unique.

  If we make it globally unique, it will easily allow for global
  VALARMs in some future version of CAP, if they are needed.

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 14:22:36 -0700

> them apart from non-decreed VCARs.

If you don't have the VCAR to change them - what's the differance?
In effect they are decreed to you.

I assume with the new proposal you can still DENY/GRANT
access to VCARs by ID?

If we want the ones "compiled in" to be tagged, then lets
add a paramater?

	CARID;decreed=true:NAME

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 14:25:22 -0700

>   that is must be a "mailto" URI. If not think we can close this

I think it should stay a MAILTO URI.

>   It can also contain a phone number, name, and so forth.

I could see adding CONTACT, but if we remove CALMASTER then
we loose a way to always find an email address. As the CONTACT
property value has no pre-defined format.

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jan 2002 14:29:22 -0700

> > except the SELECT clause.

I agree, this item should be deleted - use the new query syntax.