Subject: Re: VCAR to seperate draft?

From: [email-masked]
Date: Wed, 23 Jan 2002 17:29:57 -0500

Doug, if we do this, and the draft is tied to CAP, it could possibly delay 
CAP.  When you separate drafts and they are "linked" they need to move up 
the internet food chain as a group.  Only if the VCAR draft would stand 
alone would it make sense to have it in a separate document. 
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Doug Royer <[email-masked]>
Sent by: [email-masked]
01/23/02 12:47
Please respond to "[email-masked]"

        To:     "[email-masked]" <[email-masked]>
        cc: 
        Subject:        VCAR to seperate draft?

VCAR to seperate draft?

Do we want VCAR's to go into a seperate draft? If we do, then
CAP with some tweaks and LOTS of minor edits is much closer.

---

From: Doug Royer <[email-masked]>
Date: Wed, 23 Jan 2002 16:21:19 -0700

[email-masked] wrote:
> 
> Doug, if we do this, and the draft is tied to CAP, it could possibly
> delay CAP.  When you separate drafts and they are "linked" they need
> to move up the internet food chain as a group.  Only if the VCAR draft
> would stand alone would it make sense to have it in a separate
> document.

I just sent out another email that included this topic.
Addressing it specifically:

I think we can do this if in CAP we call access control an
administrative function to be defined later. This would
not 'link' them. But allow the reader to implement a CS.

I think we all agree we want access control. And I think
that we all agree that we want CAP. But for now,  why can't
we say in CAP:

	Here is how you store objects in the CS, subject
	to administrative restrictions.

And in CAP

	Access control is an administrative function of a CS
	and CAP does not specify how a CS determines when
	a CU/CUA has or does not have permission to perform
	an operation. So the CUA must be able to deal with
	"<error code>;permission denied".

We keep the framework for errors that VCAR-draft will use without
specifying that it is designed for VCAR. And that's easy because
the text is already in CAP - we just have to remove the VCAR specifics
and say this it what the CS MUST return for permission denied.
And that you won't get XXX if YYY. And defer how you tell
the CS until a VCAR draft.

-AND-	At the same time that CAP is being worked on, and
	independently (not linked) work on draft...calsch-vcar- ?

Why do we want access control to be defined in this WG?

	Because we want to have our implementations CUA's talk
	AND control the other implementations CS.

	Because large sites have administrators that do not
	want X number of ways to control access.

At this point in time no CUA can do access control with any
other implementations CS because there is no standard way
to do that. So can we please settle to baby step this interoperability
by doing access control as step number two ?

Will this require a tweak to the charter - yep - lets do it.

---

From: George Babics <[email-masked]>
Date: Wed, 23 Jan 2002 23:17:39 -0500

VCARs are very important for group scheduling, and CAP in
general. Without them one can not easily share one's agenda
with others. It may hurt interoperability.

VCARs are not that far from being completed. All they need
are a few adjustments. Bernard seems to be willing to come
up with a proposal very soon. Lets see if we can resolve
the issues with the current VCARs.

George