Subject: Interim Meeting minutes - warning large doc

From: Pat Egen <[email-masked]>
Date: Mon, 05 Apr 1999 17:42:16 -0400

These are the minutes from the Menlo Park interim meeting held right
before the 44th IETF.  Several of the items worked on were discussed at
the Minneapolis meeting and can be found on the minutes previously
submitted.

CAP Editors WG Interim meeting – March 9
Attendees: Frank Dawson(Lotus), John Stracke (ECal), Paul Hill (MIT),
Andre Courtemanche (CS&T), Steve Mansour (Netscape), Alex
Hopmann(Microsoft), Richard Shusterman (Netscape), Issac Roth (?)
Robert Weiler, (Amplitude), Mark  Parmet (On Technology), David Williams
(Acrocon), Pat Egen (Patricia Egen Consulting), Doug Royer (Sun - our
host)

Meeting Agenda

1. Review schedule of work, draft by July, meeting schedules
2. Review state of work
 ICalendar RFC 2445 based
 Data Model
 System Model
 Addressing model
 Past meeting work
      - vcar, vquery,vcommand
 Scenarios for illustration
3. Transport sizing discussion
4. Identify “holes” in draft
   - Assignments for next meeting

Schedule of work, draft by July meeting schedules
--------------------------------------------------------------
Frank gave a brief history of charter, goals, etc.  He explained the
reason for the speed in trying to finish – committee needs to close by
July.  Two more interim meetings will be held before July.  Dates for
the next meeting -  4/27-28 (Atlanta) and 6/7-9 (Montreal)

We went over MN agenda.

XML discussion
--------------
There was a general discussion about the XML draft currently being
worked on by several people on the list. This will be reviewed at a
later date.

Data model
----------
Because of some new faces in the meeting, we decided to spend some time
on the models. Steve put up the CAL store model.  He showed the Calendar
ID scheme://csid/relative CALID.  CSID is a DNS internet standard -
common internet scheme syntax  (compliant to RFC 1738).

               +-----+           +-----+
        CAP    |     |   CAP     |     |   CAP
 CUA1 ---------| CS1 |-----------| CS2 |--------- CUA2
               |     |           |     |            A
               |     |  [IRIP]   |     |            |
               |     |-----------|     |            |
               |     |           |     |            |
               |     |           |     |            |
               |     |           |     |            |
               +-----+           +-----+            |
                  |      IMIP                       |
                  +---------------------------------+

Examples:  cap://cal.example.com/bob

We know it needs to be unique within the cal store – but there is not a
requirement that it be globally unique - friendly names is an issue.
The relative CALID has to be 7 bit ASCII (needs to be a valid URL for
CAP).  The issue that came out last time is how do we indicate the
hierarchy.

One proposal is : cap://cal.example.com/bobsoccar (flat naming space)
A second proposal is we pick a delimiter (like a /)  -  Decision was to
have an opaque relative calid that does not require any semantics
required. An arbitrary  string
Cal props: localized name, parent, children, owner(s)

Alex said the CALID should be a searchable DNS host name.

Inheritance is not in CAP 1. There are no access rights unless you
implement them.
If no VCARS are present then all access is denied.

We need to work through, at some point, the detail of Access control and
inheritance.  It will be harder to add it later.  One potential is we
could define what inheritance means.  If you don’t have it then
everything is denied.

We could go to cal props and pick up localized name.  A calendar can
have more than one owner and an owner can be a user, a process, or an
authentication entity.  Owner is one area where the identification may
be an issue.  It has to be tied into some kind of security mechanism.
It could be whatever the server side says is the security mechanism.
How do we identify who the owner is and what do we use as the underlying
mechanism – LDAP, security.  The term USER is not really a user – it is
an address of a CUA (calendar user agent).  There could be processes
that want to authenticate to a calendar store.  One option is to make an
owner a URI (like a LDAP entry).  If it is a human, use a mailto url.
It should be whatever the server can authenticate.  Alex says if we use
a real URI (rfc 2396) it can be what we need.  It appears that using
SASL would give us what we want on both sides. By using a standard in
place we can at least point them a mandatory CS’s  SASL implementation
and define it.  We may have to prefix something on the front in order to
store it.  Alex used Active Directory as an “example”.

Quite a long discussion ensued regarding URI and LDAP authentication.
Paul put up an example.  Using x.509  Microsoft Server:
vcm:[email-masked] wants to talk to the Lotus server.  When
Alex wants to grant you access, user will be the same as owner (USER
becomes a new value type), should  we at that point validate security?
You have to be able to resolve the owner at some point. Using the
example where one server is Kerberos and the other X.509, you won’t be
able to establish a security connection.  At that point, you need to
know the “style” of the format and a should would be should you validate
it?

Paul says you won’t be able to validate it at that time.  You won’t have
the certificate.  If it is an LDAP uri, we better go get the data.  A
LDAP url points down to the distinguished name, you may not be able to
go verify the security rights at that time.  The user at some other
point may present an X.509 certificate (like in Active Directory).  You
don’t put the certificate in the URI; just put the LDAP URI in the data
– it is the query URI information.

Alex says you may want to let the Area Directors know that ACL might
prolong the issue.  Everyone else says we need some ACL VCAR stuff
included or the draft won’t fly.  There should be no unpredictable
results generated from security and ACL’s .  We need to make a statement
that we need to identify the major issues regarding security.  We need
to change the draft that we are going to put in ACL controls.  We need
to detail the VCAR.

System Model
------ - - - -
Based on the last meeting and discussion on the list, consensus says
FANOUT is back.

Note: throughout the notes there will be references to CUA1 (calendar
user agent 1), CS1 (calendar store 1), CUA2 (calendar user agent 2) and
CS2 (Calendar store 2).

CUA1 talks via CAP to a Calendar Store (CS1) and it wants to talk to
another Calendar Store (CS2) it can go via CAP or optionally IRIP
(however, can’t do everything) and another mandatory use IMIP to get to
CUA2.  Note. CAP is not server to server

NAT issues are not addressed in CAP.  We do have to deal with proxy
issues in firewalls. Do we want to put in an item in the requirements
that we don’t support NAT.  Alex says it may be required to support
multi-homed servers – you may want to address a server by name.  If you
use IP addresses you may have to let NAT look at addresses.  You fall
back to IMIP if you can’t find a connection.   IRIP addresses some of
the issues.

Alex asked why we have to have something in the protocol to have a CS
talk to a CS.  It was a requirement.  His question was there anything
specific in the requirement that states why this has to be there.  One
way is to have the CS act as another CUA.   CUA authenticates as CS1
when he talks to CS2 and he uses the SASL framework to handle this.

There was a lengthy discussion about server to server authentication and
trusted relationships.  Which credentials are being presented to the
server.  Will SASL handle this as the framework.  It will be determined
by what is running on the calendar store.  What will they allow.  If
there is no trust relationship you go back to ITIP and use whatever
binding is in place.  Paul says you can do “Impersonation” instead of
trusted relationships – some of the implementations in SASL allow. CS1
logs onto CS2.  The VCAR on the CUA on CS2 has something set up that
says what is allowed to be read/etc.  If we use SASL, two companies can
agree to use an “impersonation” or “trust” relationship.  CS2 would have
to be set up to do whatever is required.  If nothing is set up on CS2,
there will be no access.  CS2 would have to be set up to do whatever
CUA1 to do.

Here are the specific points for security.

SASL does not address granularity.  Some of the mechanisms support
impersonations.  For the mandatory SASL spec that CAP specifies it must:
Kerberos V5,

List of security features
-------------------------------
Strong authentication – mandatory
Impersonation – optional or MAY
Authentication and authorization are both mandatory
SASL support authentication not authorization
CRMV5 is a part of SASL (does it support authorization)

Impersonation:

CUA1 wants to talk to CS2.  It can get the credentials (sort of like
caching user id and password).  Impersonation does not show that it is a
different person.  It is the actual person, not “acting on behalf of “

I authenticate as who I am; then the VCAR tells the rights that are set
up.  It has to be a trusted relationship.  It will depend on what the
VCAR on the Calendar Store says is the approved access rights.  The CS
needs to have VCAR status that says update everyone, not everyone, etc.

If we do the trusted relationship, this works.  If we do impersonation,
we may have broken some of the capability we want.

You need to have support for the CAP protocol in your firewall.  If it
is not there, it does not work.   Public, private calendars – don’t
mingle what the access control with CAP.  There are common ACL items
that can be defined common across the line.

We do have a good idea, on an application specific capability, such as
the VCAR proposal.  There are these “nn” at least policies.  There are
some hard ones, some easy ones that can be defined by grammar.

Whatever calendaring goes across the Internet can not be assumed to be
“trusted” – that’s not the Internet or IETF way.  We have to be sure
that our protocol is strong on security.

Paul’s gave a good example of using a travel agency to post my itinerary
back an entry on my calendar. It may be a personal travel agent. Does it
work with our proposal.  Groups are an option.  Can we do “groups” of
entities in our VCAR grammar.  You specify an authenticated user in the
VCAR.  The authentication goes back to a user; a process; a system.  The
authentication is I am Frank, not “Frank, a member of group ..” You
authenticate in as Frank, the process then goes and looks at the
Calendar Store and sees that Frank is a member of  … We would need to
have a “grant” for every user in the VCAR – not very scalable.  We
should be managing the “when” not the “who”.  Frank says we may need to
have “a user” or “a group”.  We let the CS take care of how to handle
the people.

Putting the URI in the VCAR solves the Admin issues, the group listing
issues, etc.

To define an authenticated calendar user that the access rights apply
to. The new VCAR keyword is “userlist”  and is URI .  A Grant or a DENY
should specify one entity.  A URI representing a user or a group of
users.  We need some help on the wording.  Entity, principle, user, or
userlist.  Get verbiage from Frank.  We want to be able to retrieve who
is the owner of the property.  Owner property should be human
readable.   This may end up looking just like an “attendee”.

In the travel agency example, how do I get the information we need to
grant us the permission to use the info in the calendar product.  It
could be a MIME object.  It could be a URL with a certificate
attached.    What is the simple approach.  What we need is the
authentication id from the travel agency.

“Act on my behalf “ on one calendar – how does that interoperate with
another calendar

Further discussion on security (Paul and Issac).  It appears that the
LDAP information does not need to be in the VCAR information.  What do
we do if there is no certificates or LDAP services, you need to hand
them a user id.  CRAMMD5 may be a security vehicle that can be used in
these instances.

What makes us go to a particular VCAR on a CS?  If we have the
authentication ID and it much match the VCAR id.

To get the user to authenticate to your calendar store – you pass them
the CALID and then the server passes back the authentication id or give
them a predefined one.  Then you have the VCAR definitions for the
individual or for the principal (the principal is a one to one mapping
or a group name that expands to a list of authentication ids).  You
specify a URI to a person or to a expanding group.  Do we need a URI
prefix.  Note:  X509 may look different organization to organization.

1. Exchange CAP address
2. Authentication ID or define one
3. You may at this point create a directory entry
4. Set up a VCAR for the individual with principle set to CAP-defined or
generic URI that expands out to a group or a drop down comes up where
you present names to the user for selection.

 We may not be interoperable across different domains.  As LDAP
implementations and deployments become more prevalent, we are doing this
and it may work better in the future.

 You basically have to have a local authentication id (a MUST) or local
user account in order for this to work.  Maybe what we say is we must
implement local – and in the appendix here’s what you do.

 How does the server understand and expand the group.  Get a CERT ID
from the other server  and add it to your directory.   Then you have
access to “look at a directory on the other server?”

 Addressing Model was addressed a little. Somewhere some changes will
need to be made to VCAR.

 Wednesday, March 10, 1999
 ---------------
 Today, we did a lot more work focusing on the draft.

 Set of commands: CS Command and CAL Command

 Commands:
 Abort          Authenticate
 Capability     Continue
 Create**       Delete**
 Disconnect     Generate UID
 Send data**    Modify**
 Move**         NOOP (ECHO data)
 Read**

 ** need to address issues

 Table of Contents of draft:
 -----------------------
 State Diagram
 Command Format/Reply Codes
 Multiple Commands in progress
 Implementation Issues: minimum props for comp

 Examples
 Create calendar
 Create component to multiple cal
 Change partstat
 Read events for a range of time
 Read Calendar (has query internal)
 Read and modify alarms
 Read timezones components

 Cal Store Props
 1. Time (UTC or localtime plus TZID) – this is not a floating time
 2. Max date
 3. Min date
 4. Time Zones (component)
5. Default VCARs
6. Cal Master

Cal Props
1. Children
2. Name
3. Schedulable Hours
4. Owners
5. Parent
6. Relative CalID
7. [Path??]
8. Created
9. Last-modified
10. [Who modified??]
11. Default language
12. Default character set
13. Preferred – TZID
14. Cal Master
15. Tombstone

 Discussion

Steve said he was going to work with John Meir on SASL (John is the
editor of SASL)

Steve said last time we decided to label commands – he wants everyone to
make sure it makes a difference in how you code things.  Paul and Doug
said we must always LABEL.  Do we want to allow commands to get stacked.

Other implementation issues:

What is the minimum set of events we send down?
There are component properties, parameters, calendar properties
What state does CAP take when it gets published and how do you relate it
to ICAL
We may need to modify ICAL in order to implement CAP
Part of CAP needs to say “these are extensions” of ICAL

Version of ICAL needs to say “Version 2.0” if you conform to CAP…

CAP is between client and a server. Do we combine CAP and IRIP?
Frank says it may be a bad technical design to combine CAP and IRIP as
implementation.  Doug said he thought this was the case in Redmond.
Frank says the architecture is you must implement IRIP if you implement
CAP.  This needs to be finalized.

Steve is assuming this will be a “State full, connectionless” process,
it hits the server, disconnects then sends things back.  This may not be
the case, but this is his thinking

General discussion about timezones.  Stationery resource has a location
specific timezone.  The semantics need to be very clear about what are
the preferred timezones for this calendar.

All examples done at this meeting are done specifying TCP (not HTTP) –
the reason was this was the expertise represented at the meeting

State diagram.

 CAPABILITY                                  +-----+
+-------+                                    |     | CAPABILITY
|       |                       +---------------+  |
|   +-----------+ AUTHENTICATE  |               |<-+
+-->| Connected |-------------->| Authenticated |<----+
    +-----------+     +---------|               |     |
         |            |         +---------------+     | command
         | DISCONNECT |                 | address     | completes
         V            |                 V             |
    +--------------+  |         +---------------+     | timed out
    | Disconnected |<-+      +->|  ReadyToSend  |     |
    +--------------+         |  +---------------+     | ABORT
           A                 |    |      |            |
           |                 +----+      | SENDDATA   |
           |              address or     |            |
           |              CAPABILITY     |            |
           |                             V            |
           |     DISCONNECT     +---------------+     |
           +--------------------|    Receive    |-----+
                                |               |<--+
                                +---------------+   |
                                               |    | CONTINUTE
                                               +----+

In the diagram, the items above in parenthesis are process Bubbles.
There is a re-entrant loop using a CS command at the CONNECTED piece.
Going to the AUTHENTICATED bubble, the Authenticate path is in the SASL
cloud.  There is another re-entrant loop using a CS Command on the
AUTHENTICATED portion.  Use a CAL Command or address going to the
READYTOSEND bubble.  If you need to, you can go back and reenter the
READYTOSEND bubble using the Address path.  There is also a re-entrant
loop using a CS Command into the READYTOSEND bubble.  Use caldata across
the senddata path to the RECEIVE process.  There is a re-entrant loop
into this bubble using CONTINUE.  You can go back from RECEIVE to
AUTHENTICATE on a COMPLETE OR ABORT loop.  You can go on an ABORT loop
from READYTOSEND back to AUTHENTICATE and on a DISCONNECT loop back to a
DISCONNECTED bubble or process.   You can also pass from CONNECTED to
DISCONNECTED.

General discussion about a normal State diagram.

After authentication, I get back a session handle.  Later to reconnect I
will pass back the session handle.  You must reauthenticate again.

General discussion about connect/connectionless.  We are doing a
“connected” protocol.

Examples:

Capability and NOOP –

We will treat NOOP as a CAP command

Note: Capability command will/may return different results based upon
whether or not you are authenticated.

Frank says we need to see CAPABILITY on the Send and Authenticate.  This
provides flexibility.  Discussion changed this to be use CSCommands
instead.

General discussion about CS commands and CAL commands.  Need to identify
the specific commands and map them to the diagrams.

NOTE: on section for naming in draft, make a statement that a relative
CALID can not begin with a colon.

EXAMPLES

Create Calendar:

Note: general command format:

Label = 1*8NUMBERIC

Generic command format: label[+] 1sp cmd *arg
Generic Response format: label 1*(response code [arg])

Min: CS is 60 chars (protocol minimum) [MUST] (the CAPABILITY command
must specify what it does – expose it)
Max: 1024

Note: Frank will contact some of the small footprint device
manufacturers to see if there is any limitation requirement on min/max
lengths or buffer limitations.

To keep it generic we need to have the CAP entries as parameters
i.e. Structure: Function/ACTION Object Container (Principle)

Do we want to create multiple VCALENDARS ?? good idea??

Notes: to specify a CS id, you need to enter the fully qualified calid.
Is the root a Calendar Store and that what we say.  The root is really
the calendar store and all other calendars are children of the root.
The VALUE is a CSID and the container is the name of the specific
calendar

We call root calendars “Top level calendars” and the parent of a top
level calendar is the calendar store.

CSID, relative CALID, CALIDs can be in the list of things

Draft Note: We need to step thru hierarchical calendars in the draft and
explain the relationships between individual calendars and calendar
stores.

Need to have a reply code for each

VCOMMANDS are inside an object

Code example: (after the authentication portion)

C: 10+ CREATE VCALENDAR cap://cal.example.com/ bill ://bobo.ex
C: .COM EX.EXAMPLE.COM
S: 10 60 fully qualified container id “cap://cal.example.com/”  Note:
(60 = you do not have permission)
S: 10 2.0 fully qualified container id and will vary
cap://cal.example.com/bill (Success)
S: 10 3.14 cap://bobo.exe.com/ unsupported function (creation of
calendar)
S: 1 6.1 cap://cal.example.com/ex.example.com  could not find the
calendar or calendar does not exist
C: 20 SENDDATA
S: 20 2.0.1
C: CONTENT-TYPE: text/calendar method=create,component=VCALENDAR
Xxxx
Xxx
BEGIN: VCALENDAR
VERSION 2.1
METHOD: CREATE
BEGIN: VCOMMAND
BEGIN: VCALENDAR
RELCALID:SOCCAR **
NAME:CHARSET=xxx;LANGUAGE:XX-XX:Bill’s Soccar Team **
OWNER:capcar:bill
OWNER: capcar:Sally
CALMASTER:mailto:[email-masked] **
PREFERRED-TZID:billzone (some new wacky thing)
BEGIN: VCAR
CARID:12345
GRANT;CN=”Mr Bill”:principal=capcar:bill;action=ALL;object=all
GRANT;cn=”Ms Sally”:principal=capcar:sally;action=read;object=all
END:VCAR
BEGIN:VTIMEZONE
XXX TZID:BILLZONE
XXX
XXX
END:VTIMEZONE
END:VCALENDAR
. (placeholder)
20 2.0 (container id) CAP://CAL.EXAMPLE.COM/xyzunreadable1234
20 6.2 (container id) CAP://CAL.EXAMPALE.COM/BILLxyzunreadable5678

** mantatory

Read command (with Query imbedded so Steve says):

Read events from t1 (GREATERTHAN OR EQUAL TO)19990310T08Z to
199903101900Z on two calendars

C: 10 READ VEVENT bill ://bobo.ex.com/sally
S: 10 2.0 cap://cal.example.com/bill (local calendar – good response)
S: 10 2.2 cap://bobo.ex.com/sally (partial success;will attempt after
SENDDATA or redirection referral)
C: 20 SENDDATA
S: 20 2.0.1 (start giving me MIME body and CRLF when done)
C: Content-type:text/calendar;method=read,component:VCOMMAND
XXX
XXX
BEGIN:VCALENDAR
VERSION:2.1
METHOD:READ
BEGIN:VCOMMAND
BEGIN:VQUERY
MAXRESULTS:9730842
MAXSIZE:1700000000
QUERYNAME:MyviewRange
QUERY: SELECT = DTSTART,DTEND,SUMMARY,UID;
FROM = VEVENT;
WHERE (DTEND >= T1 AND DTSTART <= t2);
ORDERBY DTSTART ASC, DTEND, UID, SUMMARY
END:VQUERY
END:VCOMMAND
END:VCALENDAR
.
c: 20 2.0 cap://cal.example.com/bill
content-type:multipart/alternative
(MIME SEPERATOR)
content-type:text/calendar;method:response;component=Vset;optinfo:version:2.1

BEGIN:VCALENDAR
VERSION:2.1
BEGIN:VSET
BEGIN:VEVENT
DTSTART:….
DTEND:…
UID:….
SUMMARY:…
END:VEVENT
END:VSET
..
..
END:VCALENDAR
(MIME SEPERATOR)
content-type:text/xml
blah blah
….
C: 20 2.0 cap://bobo.ex.com/sally
Content-type:text/calendar;method:Response;component:VSET;optinfo:version:2.1

Denied access to properties
BEGIN:VEVENT
RESPONSE-CODE:XX
END:VEVENT

DENIED ACCESS TO FULL EVENTS:
2.0
BEGIN:VCALENDAR
VERSION..
BEGIN:VSET
END:VSET
END:VCALENDAR

 Create an event on several calendars

C: 10 CREATE VEVENT bill ://bobo.ex.com/sally mailto: [email-masked]
irip://x.y.com/ralph
S: 10 2.0 cap://cal.example.com/bill
S: 10 2.2 cap://bobo.ex.com/sally
C: 20 SENDDATA
S: 20 2.0.1
C: content-type:text/calendar;method=create;component=COMMAND
BEGIN:VCALENDAR
VERSION:2.1
METHOD:CREATE
BEGIN:VCOMMAND
BEGIN:VEVENT
DTSTART:..
DTEND:..
SUMMARY:..
UID:XYZ1234
END:VEVENT
END:VCALENDAR
UID:XYZ1234
ORGANIZER:ALTREP=”mailto:[email-masked]”;ALTREP=”irip://cal.example.com/bill::cap://cal.example.com/bill

ATTENDEE:”mailto:[email-masked]”
ATTENDEE:ALTREP=”[email-masked]”;...cap://cal.example.com/bill
ATTENDEE:cap://bobo.ex.com/sally
ATTENDEE:irip://x.y.com/ralph
.
.
.
S: 20 2.0 cap://cal.example.com/bill xyz1234
S: 20 2.0.2 cap://bobo.ex.com/sally
S: 20 2.0 mailto: [email-masked]
S: 20 6.3 irip://x.y.com/ralph

Note: If there are particular events that should have appeared in the
set that you have been denied access to – they don’t count.  There will
not be a separate error message stated for each event that you do not
have authority for.

Open issue on syntax structure:

Frank discussion on commands:  we need to come back to this later and
ensure that we make the products.

Command = label[lcc] cmd *arg.crlf
        = shortlies/multilines

shortline=lable space cmd space cmdarg crlf

calid multiline = label space lcc cmd space cmdarg crlf  1contline

contline=lcc text crlf

Query return options (what it may look like):

Multipart
Text/cal
Bills cal
Text/cal
Sally’s call

Text/cal
Begin vcalendar
Bill’s cal
End vcalendar

All of these items will be discussed at the Minneapolis meeting and then
re-visited on the list for discussion.

Submitted by Pat Egen.

---

From: Doug Royer <[email-masked]>
Date: Mon, 5 Apr 1999 17:09:20 -0700 (PDT)

Small fix (I think)

> Date: Mon, 05 Apr 1999 17:42:16 -0400
> From: Pat Egen <[email-masked]>
> 
> ...

> Inheritance is not in CAP 1. There are no access rights unless you

Should be?

	 "Inheritance *is* in CAP 1 ..."

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL