Subject: Montreal minutes - long document

From: [email-masked]
Date: Tue, 22 Jun 1999 18:20:12 -0400

Montreal CALSCH Interim Meeting: 6/14-16

Attendees:
Frank Dawson (Lotus), Pat Egen (Patricia Egen Consulting), Dave Crocker
(Brandenberg Consulting), Doug Royer (Sun), Steve Mansour (Netscape), Paul
Hill (MIT), Bob Mahoney(MIT), David Madeo (Morgan Stanley), Lisa Lippert
(Microsoft), Andre Courtemanche (CS&T), Bruce Kahn (Iris/Lotus), Richard
Shusterman (Netscape), Mario Bonin (CS&T),Gilles Fortin (Teamsoft) and Alex
Taler (CS&T)

General level setting and agenda bashing:

Discussion of outstanding to-do's:

Security and Authentication: Progress has been made.  Need to discuss as a
breakout.  One determination was using the IETF format, you state what you
expect the requirement should be for security.  As long we define what we

“feel” the security levels are it should be adequate.  We will also need to
talk about VCARs during security breakout.

SQL query and schema.  Doug has been asked to step back to work on a major
effort for his company.  Therefore, we will change from Doug to Steve to
work on the schema.  Frank and Doug to help out – 1 week delivery set.

Tombstone issues (Doug) – he did not remember it being assigned to him.
General discussion insued about whether tombstones were important.  We need
to mention the problem in the draft.  Actually it should be up to the
implementer to determine best way to handle.  You need to deal with this
issue.  Language in ITIP could suffice for how we handle this.  How long to
we keep around tombstones.  Lisa asked about exposure to the client – is
this what we need.  Steve says this may be part of the schema.  Steve will
take this on.  This is still open. Need to work on and put on the list.

CAP and ITIP relationship  - Alex posted on the list – discussion about
that posting.

Timezone – Alex has not had a chance to work on it yet.  Doug has looked
into Olson set of timezone and built an ICAL implementation.  Can we post
this idea to the list and see what happens.  Floating time will float.
This is timezones label and definition. During discussion on Timezones,
Dave says if we maintain the list (standardized not informational list) we
need to decide how we update this list.  Assign rules that IANA to make
additions, etc.  Doug has agreed to post this idea to the list.  (1 week).
(Doug)

Discussion on today’s topics

Steve ideas: In terms of where the draft currently stands:
– Authentication/Access/login – a ways to go
- Protocol commands – reasonable shape
- VCARs – needs work
- Need a common schema (need to fill in this section)

Frank suggested that we do some hallway discussions during Oslo.  Pat will
post this to the list to suggest see any of us to form these discussions.
(Pat)

"What is a User" discussion:

Paul Hill got up to detail his intrepretation of "what is a user".  His
example: username @ example.com

Example.com all “look like” domain names but could be Kerberos
Kerberos:   username/instance @ example.com

How do we define the instance –  slashes are legal (look at fax group for
ideas).  This structure binds well into SASL implementations.  It is a
subset of the URI definitions. TLS is where it does not map well.  Paul
showed how to get to this with X.509 certificates.  VCAR grammar shows who
can be defined, etc.  It’s an authenticated name that is trying to be
defined.  Example: Principle equals should be Username equals.  It’s more
information than we originally defined. How would you map this into a LDAP
URL.

Example: MS directory as user principle name attribute.  The laser working
group is discussing the same issue (per Lisa).  They are focusing on mail
usernames in LDAP.

Frank had said if we standardize this for LDAP how do we handle multiple
aliases. Paul suggested if you want that, keep it out.

The LDAP entry encapsulates all the information. Now how do you map this
into the certificates.  MS is putting the UPN in as the subject name. Paul
suggested two options.  Base it off the email or the subject.

Example: email (pbh @ mit . edu)  and upn = (pbh @ athena . mit . edu)

You may end up with multiple upn’s in some systems.

SASL systems usually use the simple username @ example . com.  RFC 822 use
brackets, etc.  So, his  proposal is to keep it as simple as possible.
Basically this is an opaque string and simple as possible.  Paul needs to
look at RFC 822 and SASL definitions to see how they work with our simple
name string.  Maybe all he needs to do is take out the confusing paragraph
in his proposal.  RFC 822 are not authentication identifiers.  Paul will
look how much of RFC 822 maps to authentication.  Paul will describe how
they are different and and then show "here is the ABNF".

Alex example: Identity issues (his item that was posted to the list on
6/11/99)

Having the identity known by the CS system, you can implement multiple
identities (group, projects, team, etc).  Use an identity command that can
be issued to do a task.

Example:  IDENTIFY proj1 @ foo. Com – in other words issue this command
after authentication, you can issue this command to do a specific.

Authentication - ……
…..
Etc.
2.0 user1 @ foo . com (this is the authenticated id that may not look like
anything you logged on as)
C: IDENTIFY userf @ foo . com  (this is a UPN)
S: 2.0
or
S: (no you can’t do this)

There can be multiple ways to get authenticated.  Once in however, they
should all map to one specific thing.  In CAP you can only authenticate to
one calendar store.

Auth1 = authentication id
Foo.com = realm
Kerb = mechanism

Using a table or map, store relationships.  The server gets the information
in the authentication step, the next ordered pair pulled from IDENTIFY

VCARs will always grant to a specific UPN.  You get the default UPN when
you authenticate.

Example:

Paul gave mappings showing that Identify command may not be needed.  He
thought the Identify command would be single value versus multiple
roles/identities.  I come in as Frank – then I become Frank the manager.
Mapping could be done from either multiple UPNs or Multiple auth ids.  Are
we going to allow someone to assume different roles/identities

Andre/Alex went thru an example that shows if you put in VCARs showing
different security mechanisms, what happens if the mechanism changes.  How
do you manage these ‘hard coded’ entries.  Their proposal of Identity is to
help solve this.

The table/mapping proposition is to have the triplet map to a UPN in the
table (daveUPN).  The VCAR would say VCAR (daveupn, request, grant)

Example mapping table:
- - - - - - - - - - - - -
Auth id, realm, type of auth       UPN – CS Unique User Identity
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mario, realm:cst, ker5               mariob/[email-masked]
Mb,otp                            mariob/[email-masked]
Mariobonin,digest MD5                mariob/[email-masked]
Davec,realm1,MD5                      [email-masked] (DaveUPN)
Davec,realm2,kerb5              [email-masked] (DaveUPN)
Davec,realm1,pop(plain old passwd) [email-masked] (daveUPN)

Paul showed how definition did not work.  Going thru diagram, he pointed
out that CMD5 may not work if Dave has not been defined to the IBM network.
IBM could give a certificate to a company in order that the CUA could
access the calendars.  The certificate schema’s are brief(crude) so they
may not have enough information for what we want to do.  Since the subject
name does not have the form for a UPN, do we want to use the mail id.  DN
and mail id are clear in the community.  The subject field has some
flexibility.  Put the CAP upn in the subject field and require a company to
issue a certificate for calendaring.  He says you should not need to the
table.  By the time you come out of SASL you should have the information
you need to build a UPN.

What do we do with just a password (POP)? The UPN becomes
[email-masked] and then we use the Identity command. Now that he has
the UPN he can see another system using CS&T using IMIP.

The role is a combination of the UPN and Access control rights defined in
VCARs.  Right now we define multiple calendars for a user as calids.
We need to ensure that a delegate or designate is identified somehow on a
calendar request – but also ensure that it shows that the name shows it is
the calendar of a manager even though it is a secretary that has made the
entry.  Somehow there is a string that identifies who the person is.

Andre’s proposition:  In the VCAR, put an entry/attribute that shows the
sent by so that the calendar says who it is.  The UPN is used to identify
access rights.  Carry the framework forward and tagging on strings that
show ownership.

Wherever access rights need to be tagged use the UPN.

Lisa said why don’t we keep CAP simple and add the server to server piece
as another protocol (Dave said X500 and LDAP is a good example of this).

Richard wants to know why we need identify.  Don’t we get all the
information we need from the authentication section.

We then formed the groups for breakout.

Security – Andre will lead.
Protocol/Data Recommendation – Steve will lead

Security Breakout session (notes provided by David Madeo, acting scribe)

Andre's agenda before we started talking
Statement of need
Use of SASL in CAP
The authentication process
Use of SASL in the authentication process-     authentication using
external realms-  use of the authentication id in CAP-  export control
implications-  SASL authorization id and its use
Transport level encryption
    use of SASL in negotiation of the transport level encryption
    minimum transport level security
    recommended transport level security
Impact of re-authentication during the course of a connection
    impact of the capability set
Usage of authentication information and user identity
    what is the authenticated user
    CS, Authenticated user, data ownership, and rights granting
    How is the authentication information used in the VCAR statement
    How does the authentication invormation used in the context of the
CALOWNER property
    Designate access to information
    Multi-realm authentication
    Fan out operation
    Security considerations
    Anonymous access
    Open Issues
    Glossary of terms
    bibliography

Actual discussion

1) Since we're using Mime objects for all get's and puts, it would be
nice to encrypt the entire blob of data, as opposed to encrypting the
transport channel.  For example, you don't trust your ISP.

However, since we're using Mime to encapsulate iCalendar this is a
problem.  The headers as well as the values would be encrypted,
there's no way to know what the blob is, or who it's intended for.

How do we move some of the header information out of the blob?
Perhaps the CS stores the data encrypted with the server certs on the
disk, so it's encrypted in the pipe with the user level
authentication.  Even if the CS knows how to decrypt the blob, it
won't know how to encrypt it again for retransmission.

This area needs more consideration.

2) use of TLS in SASL. We agree to the following

MUST implement SASL for authentication
MUST implement Digest md5 (des/triple des) for encryption during
  authenticationMUST implement DES-56 for link level encryption
SHOULD implement start_tls as a CAP command for link level
  encryption
Ability to have TLS within SASL while authenticating. What happens if you
start_tls twice and or if you have a link level, then do a start_tls?  It's
an error.

3) Definition of terms

We need to put these definitions in the top of the doc    -principal - we
all agree to not use this term    -user - is a person or a customer of
calendaring system. Should be     called Calendar User, a biological
person.
    -username - is the users name in a given realm.  They should be
     fully qualified and used as a UPN.
    -UPN - - UPN is used as an identifier of a Calendar User.  [rest
     is from Paul Hill] A UserPrincipalName is CAP's representation of
     a CU (Calendar User).  A user principal name strongly resembles a
     RFC 822 style email address and in some cases it may be identical
     to the user's email address.  It consists of a simple user
     identifier and a security context in the form of a DNS domain
     name. It may also have an optional instance. In it's simplest
     form it consists looks like [email-masked]. When using the
     optional instance it has the form user/[email-masked].
   - realm - collection of accounts which might include the users
     account.  The string may include (insert Andre's comments) not
     used except to complete a UPN.  In order to avoid namespace
     conflict, we suggest post fixing the realm with your registered
     DNS domain name (or one that you have the right to use) (eg: the
     foobar realm could be called @foobar.example.com).  Could be a
     hostname in the example of /etc/passwd realm

   - authentication id - a result of a successful authification
     composed of a tuple of username, realm, and authentication method

4) Reauthentication without going back to the disconnected state
   impact on the capability set

background: raised in MP.  see pg 14 in CAP.

MUST implement AUTH

The AUTH command should return the UPN to the client.

if the AUTH fails, you are dropped back to the connected state

potentially implementations should allow tuning to drop the     connection
(as opposed to the credentials which are already     dropped) for each
failure, or after 10 failures or whatever.

if you re-auth, you give up whatever credentials you have already,    and
"you bet it all". We need to do the same thing as SASL when you fail the
initial AUTH (andre will check on this)

5) Anonymous

# we agree it's a MUST implement, but it's suggested most
# implementations turn anonymous access off by default

Anonymous can be represented as VCAR(@,,).

We think we might be able to use the "@", since it's effectively a    null
username and a null realm, surrounding an "@".  This means it's    an
anoynmous user.

Either or:
   a) SASL has a generic way to perform anonymous binding
      - we'll then map it
   b) have a mechanism for anonymous binding

While some sites may not use this, we do need to define how you    specify
"anonymous" in the spec "Anonymous" can't be used, though    FTP uses it

6) Groups

As a user, we all agree, but as a developer, we all shudder.Types of users
and groups    any, including anonymous    any authenticated (they
authenticated somewhere, but I have no
      idea who they are)    any authenticated in a specific realm (eg:
@example.com means any
      authenticated user in that realm)    groups and/or dynamic groups
(regexp or LDAP expansion)
     individuals (specific UPN)

We don't want to overload groups and users in the UPN namespace. We could
create a seperate field in the VCAR to define groups affected. The
namespaces should not overlap, but perhaps we can use context to determine
if it's a UPN or an anonymous or group expansion in the VCAR definition.

    Case 1 -> Specific UPN for a single user
    Case 2 -> Anonymous (any, any authenticated, any authenticated in a
      realm)    Case 3 -> Expansion         Easily determine what sort of
query this is
     Regexp ->   [email-masked]
     LDAP URI ->  ldap://ldap.foo.com/cn=server developers, ou=Groups,
        o=foo.com      (Are there URI for regexp's and/or SQL queries?)
7) Hierarchy and inheritence      long discussion not worth recording

8) Error codes

Bruce raised the issue that we have a large number of root level error
classes.
10) multiple realms handling
11) UPN vs MAP table merge    CU      CUA     SASL               CS
user -> cua -> [authentication] -> server

At the end of authentication, you have an authentication id.

We need to get to a UPN:
    1) totally implementation dependant
       table or other mapping

implementation suggestions

       - Given an authentication mechanism, the UPN MUST always be the
       same independantly of the implemention
       - Given different authentication mechanisms, the UPN MAY be the
       same from all of them, but it does not have to be.
       - A server MAY choose to implement a mapping mechanism to map
       multiple UPN's to a virtual UPN, but it's an implementation
       detail.

       multiple credentials -> 1 UPN -> 1 
User

          credentials   UPN
          -----------   ---
       (1)    1          1  commonplace
           ----------------
       (2)    N              1  (many credentials for one user)
           N          1  (many credentials for many users) library
           ----------------
       (3)    1          N  admin wanting list of UPN's
           ----------------
       (4)    N          N

a) in all cases, bad passwd practices increase the complexity
b) in case (3), we would need the IDENTIFY command to pick one UPN over
another
c) if we allow case 3, CUA needs a way to handle multiple UPN's, or we need
to say that it picks the first one by default. It also implies a table
lookup.
d) if you pick (2) and (3), then you've essentially selected (4)

12) Do we need Identify commands?
    See above.

14) Should UPN be i18n?
    -VCAR can only be 7 bit ascii
    -If the ical data supports utf-8, then do you need to support
     utf-8 in the name? Small footprints still need to display ical
     language needs to be specified UTF-8 character set.
    -URL is usascii already
    -some authentication methods use UTF-8

    Final answer is ->
    -UPN is text, can be rendered in UTF-8, not restricted to usascii

16) Roles

Define Terms:
     Roles: We don't want to use this term
     Policy, a named collection of VCAR's
     Policy Statement applying a POLICY to a UPN(group?)

b) -There are 4-5 suggested policies which still need to be increased, and
fully fleshed out
     -Site defined policies which may not be transportable, but the
      policies should be extractable as a set of VCARS

c) The policy statement looks like this (in pseudocode)
     grant ACTONBEHALF [email-masked]
   Perhaps we want to expand this to include grant
     ACTONBEHALFandDESIGNATE [email-masked]
d) How an Admin works (this is all wrong and needs to be reworked
       mirror -
   a) admin authenticates as themselves
   b) specify a target of the bosses calendar (as designate)
           - needs to be specified
             every action needs a mirror pair of "as this person"
   c) server checks vcar
   d) calendar pops up
   e) inserts appt (CUA defines fields)
   f) server checks vcar
   g) server inserts appt
     (specify calendars by target, possible recommend a "policy"
     attribute to commands)

e) do we have additional icalendar fields
   Yes, such as
        updated by
        created by
   Or,
        modified by is a list with
          1 value -> created by
          2 values -> created by, updated by
          n values -> created by, first updater, second updater, .... n
           updater.
f) do we allow a user to remove all rights from a calendar, including their
own.            * The Cal property "Owner" should be a UPN      * We do not
allow the "owner" property of a calendar to be
       deleted or have the last value removed.

       There's an implied "owner" VCAR for the calendar store based on
       the Cal property "Owner" if you want to restrict the owner, you
       can put a specific VCAR denying them access.  Implementation
       specific if we allow a user to remove all access to a calendar.
       The calendar store owner can modify anything, but they can not
       lock themselves out.

Protocol Breakout session (Steve)

Transport and Application protocol commands.  Dave Crocker encourages us
that some things do not have anything to do with calendar stuff and we need
to differentiate between commands and responses.

Capabilities – page 20 (7.1.4) in draft.

All except Auth are application items vs transport.  Proposal is to take
AUTH out of the CAPABILITY mehtod and put it somewhere else.

General discussion of 1 or 2 ports for IRIP and CAP.

Another point that Frank brought up is the relationship of IRIP and CAP.
Is it one port or two.  There is a default port for CAP transport layer.
When someone connects, a CAP server listens for a specific port(s). If we
have the approach that IRIP to CAP is using the same transport commands so
that the IRIP commands are restricted to the port for IRIP and CAP
application port, then you can specify CAP alone or IRIP&  CAP commands.
It will come back with level of CAP and IRIP that are supported.

Note, a small profile device may want to only connect to a IRIP port.  It
is the responsibility of the sysadm to set up what a port does.

A scenario.  One server, one port.  Solution a – on firewall (server may
have two network cards).  So when client sends a request on one side IRIP
the other side has both CAP and IRIP.  All server implementations support
peer IP names.  In order to enforce IRIP only, require the server to look
at the other server to see what it supports – this would eliminate the MUST
support IRIP.

The simpler solution looks like one port listens for IRIP and one port
listens for CAP and we will allow CAP to issue IRIP commands on that port.
We want a clear description of what and how a server listens for IRIP
commands.

The group did not agree on two ports versus one.

Steve felt we may want to put in restriction TABLES  (similar to ITIP) –
good idea Steve. Go for it.

We need to also include ITIP extended  pieces within the document.  We need
a section in the intro describing the relationship of  ITIP and CAP.

Here we talked a bunch about agents etc.

Being able to support IRIP in CAP is a MAY
CAP alone –
After authentication, IRIP V.1 only
IRIP v.1 and CAP v.1

We have a major question: what is the difference between a CREATE and a
REQUEST.  What are the responses when you issue a CREATE.  There are 3
answers…

A data write command, request is an invitation, it’s fuzzy.

Dave suggested that a simple definition could be:  A CREATE is a write to a
database/store.  A request is a process or agent.

There is another entity that we have not modeled. You have the remote
store.  It’s a storage device – not a queuing device.  There is a storage
agent – it mediates.  CUA’s (user agents) – may have direct or indirect
access to the store.  Anyone can talk to the Storage agents which is in
charge of what you can/can not do.

(lisa drawing) of Dave’s idea.

(frank drawing)

This is a scheduling protocol:

                   iTIP Semantics/Workflow:
               - - - - - - - - - - - - - - - - -

Organizer           Attendee1      Attendee2
- - - - -- - - - - - - - - - - - - - - --- - - -

- - Request --   > - - - - - - - - - - - - - - -- - - - -  >
< --  counter
- - Request1 - - > - - - - - - - - - - - - - -  - - - - -  >
either of
- - Decline Counter

What it appears we’ve moving to is we have three things – Transport,
Calendar Access methods and iTIP.  The calendar access and manipulation
methods also include the scheduling methods.

CSTP – calendaring and scheduling transport (which are probably SENDATA and
AUTH) and we can send ITIP on this transport.  See diagram using this link:
http://www.egenconsulting.com/ietf/cstp.gif

Based on this we may not need two ports.  As long as we identify thing
appropriately, the server/queue should be able to determine what do to.
However, if we have them on two ports, we may be able to handle the “send
iMip to a server that does not support ITIP”.

At a minimum – calendaring command set and scheduling command set – there
are some differences that are appropriate to each.

We may need to have three RFCS (SENDDATA, Scheduling Protocol, CAP).  This
is not a wildly accepted idea.

Discussion on how to implement an inbox for incoming iTIP messages.

Frank example:

BEGIN:VCALENDAR
 METHOD:READ
  BEGIN:VCOMMAND
  BEGIN: QUERY
    SELECT VEVENT:*
    FROM VSCHQUE
    WHERE METHOD = “REQUEST”
  END:VQUERY
 END:VCOMMAND
END:VCALENDAR

Or

FROM VSCHQUE, VEVENT
WHERE OR PARTSTAT = NEEDS-ACTION

Cool idea:

Sav
e the CCS method value in the calendar components that are manipulated
by the CAP method.  e.g. a CREATE or a VEVENT will yield a VEVENT calendar
component with a METHOD: CREATE

This cool idea may mean we have to complicate our query stuff.  Possibly,
but it may just mean more wording.

Wednesday Protocol breakout session:

Statement: Proxy is not part of version 1 of the draft.

Go over Steve’s thoughts regarding our new process.  Show the new model,
which includes a scheduling message inbag:

                - - - - - - - - - - - - - - - -  -
                |   ( TZ)           CAL           |
                |           |----------------|    |
                |  |Props|  |          (E)   |    |
                |           |          (TD)  |    |
                |           |          (J)   |    |CS
                |           |         (VCAR) |    |
                |           | [Prop]         |    |
                |           |       (Schmsg) |    |
                |           |----------------|    |
                |---------------------------------|

Next we went through a series of events.

(example drawing)

We are proposing to store methods with to-dos, journals and events.  Key
question becomes: do we use one schema vs two to get an event into a
calendar.

We should be able to modify events using the method.  When you are done
with a modify, be sure to make the label set as Modify or new Create.
Table is going to have a method and you can implement them whatever you
want.   Select * from VEVENT where method = CREATE.  Keep it in the VEVENT
queue

We could define that if you Select from whatever queue, by definition you
want everything except CREATEs.  Even if you implement it as the same
queue, you get the same thing.  Make the queries compatible then we can
call the queues whatever you want.

Model is that sch events appear separate from cal events – to query from
the VEVENT queue where method does not = CREATE that will make clients
compatible.

Doug and Lisa disagreed on how we do the Query/Select on the queue.  We
need to write this up and put it on the list.  Who will write up this
section. Need an assignment. Lisa and Alex will work on this.

The more we talk about scheduling the more we see the fact that there needs
to be a person (i.e. human) sitting between the scheduling queue and the
calendar.

Alex brought up the issue of identifying the sender of data in the
scheduling queue.  It was not agreed that this information was necessary,
or how it could be stored.

Action item:  Further discuss Alex’s question. He will prepare a comment
with Lisa and put it on the list for discussion.

Fan-out discussion.    When you separate data access commands from
scheduling commands, you can be explicit about what can have IMIP commands
or not.  For example the data access commands can only go to data (Create,
modify).  If a CS can do something with a request it does.  If not it
rejects.  It is hard to accept IMIP commands in data.

Something we agreed upon.  On the target you can specify calendar store ids
that do not exist on the currently created CS and calids.  Example – a
firewall proxy.

If you specify calendaring commands over the transport, you must specify
only a CAP URL for the target property.  If you are using scheduling
commands over the transport, you can specify either cap or iTIP URLs for
the target property.  The CS in the latter case may provide for fanning out
of the command to targets not located on the CS where the cua is not
authenticated.  In other words the CS associated with the current cap
session.

Calendaring methods can only take calendaring commands helps to cement this
understanding.

Action item: We need to come up with a standard way or process of handling
the queue (the VSCHEDULE “bag”).  We need some examples that show how you
process each ways for processing the vscheduling queue.  How do you get
them out.  How do we create an ITIP process.

If we get a refresh, and the addresses are ITIP URL form, we can use CSTP
and send a request to the server.  We get a refresh.  We read for all the
VEVENTs that equal refresh and feed them to another query where method
equals request.  We get that info that looks for refreshes

Problem/Example: show CAP command(s) to query to ‘VSCHEDULE bag’ for any
VEVENT refresh scheduling methods.  Read the corresponding VEVENT
description and send back to the originator of the request.

Answer (one way of handling):

1.Process the vschedule bag
2.Read VEVENT bag with a VQUERY for "METHOD=REFRESH" FROM vevent selecting
UIDS, attendee
3.Generate second query, read the VEVENT descriptions associated with the
UIDS from item #2 above
4.CUA reformats VEVENT(s) descriptions into an iTIP request/publish.
5.Filter out those REFRESH from unauthorized attendees.*
6.CUA issues a REQUEST/PUBLISH schedule command over CSTP to targets from
REFRESH

*no attendee for PUBLISH.  This step for REQUEST type vevents.

Example/flow:
Flow of events for a NEW Request sitting on a queue – work the flow:

We are changing the new method request to a CREATE. Sometimes it may be a
MODIFY

1.Query and read  sched queue for request
2.Decide: Accept
3.Create VEVENT on main calendar
4.Delete req from scheduling bag

At this point CAP is done; the CUA needs to send a reply to originator of
request.

What is the ‘decide’ is decline:

Example:

Request for new event declined RVSP true -(this is a “don’t” bother me vs a
“marked” for delete)

1.Query/read request from sched bag and check to see if UID exists (no)
2.Decide ‘decline’
3.Create VEVENT in calendar with ‘something’ flagged as decline
4.Delete request from sched bag
5.Send reply to originator (don’t do this step if RSVP = false)

Example:
Request for existing event that has already been declined: (RSVP = true)

1.Query/read request and check if UID exists (Yes)
2.Decide to decline again
3.Delete request from queue
4.Send reply to originator

Example:
Multiple request, same UID, RSVP = True

1.Query/Read REQUEST from sched bag
2.Process in sequence order as appropriate for CUA. For example: Sort by
UID, recurrence id, sequence id, timestamp
3.Check to see if UID exists.  If YES, check seq number of new item
 against stored
4.Process in sequence order for a

We need to do some more documentation about the fact that what is not in
ITIP is what you do to the store.

Example:
Sending a counter - Note: When a counter proposal is sent out there is no
need to keep the counter around.

1.Query/read sched bag where method = counter
2.Check to see if UID  etc
3.CREATE as originally presented in CS
4.Decide to Counter
5.Generate and send COUNTER

When we counter we need to say we have a Counter Pending.

Should there be a sort order for all UID, Recurrence-ID, Sequence, Dtstamp:
Request (invite, reschedule, confirm, status-update, refresh-ack)
Add
Reply
Publish
Cancel
Confirm
Refresh – 8
Counter
DeclineCounter

1. Sort-by:
-UID (Ascending ID)
-Recurrence-id
-Sequence
-Dtstamp

2. No other query sort-by (i.e. necessary sort order) for methods.

If you sort in this order you will get the results you want

Final closing: DRAFT editors assignments

Frank:  IANA stuff, VCAR, iCalendar differences, Other section, finding CAP
servers
Doug and Steve – SQL schema
Alex – security, UPN, scenarios
Steve – editorial comments/changes; system model, restrictions
Paul Hill – security (work with Alex)

Email addresses:
[email-masked],[email-masked],[email-masked],[email-masked],lisal@micr
osoft.com,[email-masked],[email-masked],[email-masked],[email-masked]
,[email-masked],[email-masked],[email-masked],[email-masked],Fran
[email-masked],[email-masked]

---

From: John Stracke <[email-masked]>
Date: Sun, 27 Jun 1999 17:01:53 +0000

[email-masked] wrote:

> name string.

The only problem with opaque strings is that they can't be *completely*
opaque; you have to define what characters are illegal (so that the parser can
spot the end of the string), and, ideally, include a syntax for expressing
those characters when necessary.  If we use URIs, then we get both of these
for free.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/