Thoughts/questions on CIP

[Bruce_Kahn%IRIS@xxxxxxxxxxxxxxxxx]

  To:   ietf-calendar @ imc.org @ IRISNET
  cc:
  Subject:  Thoughts/questions on CIP


  These snippets and comments/questions are based on the text of
  http://www.imc.org/ietf-calendar/draft-ietf-calsch-cip-00.txt .  There
  may be some overlap with those questions/comments made by others earlier
  but I have not seen any that I think are overlaps yet.

  From the top...

  Abstract
  ...
  CIP is one of three standards under development by the
  Calendaring and Scheduling Working Group of the IETF. The
  other two are the Core Object Specification (COS), a standard
  data format for representing scheduled events, and the
  Calendaring Access Protocol (CAP), a standard mechanism that
  scheduling user agents may use to access user calendars
  (analogous to POP).

  Is that CAP or ICAP?  I do not see any refs to COS and CAP on the
  CalSched web site or on any postings.  If these are the other efforts
  that we are working on then we need to include some form of reference to
  them below or on our WG's web site.  Perhaps we need to categorize the
  efforts in progress under these headings (ie: ICAP & Alex's proposals &
  Frank's proposals are under CAP, vCalendar 1.x under COS, etc).

  1.4 Commands and Responses

  The CIP session begins when the client initiates a connection
  with a CIP server on port IANA registered port xxx. The server
  responds to the client connection with the following statement
  containing the name of the protocol - "CIP" - a version number
  and the DNS name of the server:

  S: OK CIP 1.0 hostname

  Since you have introduced the concept of a "unique server identifier" you
  should probably have that value returned instead of the DNS name since
  that is the name/identifer that the client is expecting.  You could allow
  for a response in the format of:

  S: OK CIP 1.0 DNS_hostname ( unique server identifier and other assorted
  stuff like vendor ID, etc)

  1.7 Event Identifiers

  In order to manage events easily, each event that is sent or
  referred to with CIP has a unique event identifier of the form
  local-event-id@server-id. Server-id is the server identifier of the
  CIP server that owns the event. Local-event-id is a local identifier
  assigned by that server.
  ...
  Event identifiers are used in several places. In the SENDEVENT
  command, they are stored in the UID property within the
  vCalendar representation of the event. In the RESPOND
  command, one of the parameters is the event identifier of the
  event being responded to.

  The problem w/these two is that it now no longer allows for the vCalendar
  system to make the UID anything it likes (ie: clsid:...).  This forces
  all vCalendar writers to make UIDs that are event-id@server-id and that
  is not part of the current vCalendar spec so this may not hold up for
  'gateways' of vCalendar content from true vCalendar based systems (or for
  those true vCalendar apps that users may want to use in conjunction w/CIP
  work).

  1.8 Event Versioning

  In order to manage multiple versions of events, each CIP server
  must assign an event version to each event it owns. This version
  number is a monotonically increasing positive integer, starting at
  1 when the event is created. Whenever the server changes an
  event, it increments the event's version.

  First, this also violates the use of SEQUENCE from vCalendar since by
  default it is 0.  This also may cause problems as mentioned above with
  UID (WRT to true vCalendar writers).

  Second, be more precise in identifying 'the server'.  This should be the
  'the CIP server that owns the event', not any 'server'!

  If the version reaches 2^^31 (two to the thirty-first power), the
  event SHOULD be cancelled and a new event created. This
  avoids problems caused by wraparound. Of course, this should be
  very rare.

  How about a 'Replaces: UID-replaced' addition to vCalendar so that this
  'follow on' case can easily be linked/tracked in those systems that grok
  wraparound handling.

  1.9 Contacting Servers

  In order to establish a connection with a CIP server, a CIP client
  must map a server identifier to an IP address. Instead of
  performing a simple DNS host name resolution, a CIP client
  MUST use the technique described in RFC 2052 (DNS SRV) [3]
  to locate a server with service equal to CIP, protocol equal to
  TCP, and name equal to the server identifier. If no SRV record is
  found, this technique backs off to a simple DNS host name
  resolution of the server identifier. Once an IP address has been
  found, a TCP connection MUST be opened to a port number that
  will be assigned later by the IANA. This mapping process MUST
  be followed every time a CIP client tries to connect to a CIP
  server.

  This is way too much for the simple PIM -> something else case (ie: PIM
  -> PIM, PIM -> laptop, etc).  I dont have much IRDa experience but it
  seems that this wont work for IRDa users (ie: laptops in a meeting room
  together w/o a network!).  If so, this "lightweight" protocol wont be
  very useful for 'nomadic' or disconnected users.

  2.1 AUTHENTICATE Command

  C: AUTHENTICATE authenticate_code authenticate_data
  ...
  Command completion response of OK or NO only. For security
  purposes, it is not a good idea for the server to return any
  additional information for a failed login.

  A way for client/server to 'negotiate' what stength/authentication schema
  to use would be really nice.  That would allow them to find the
  'strongest' or more desirable authentication allowed by each (ala SSL
  negotiation).  This feature is not a must but having a response code to
  allow the client to 'fallback' to a less strong authentication schema
  would probably be in order in any case.

  2.2 SENDEVENT Command
  PERMDENIED - This response is given with a user name when
  the SENDEVENT failed due to access control restrictions
  imposed by an attendee.

  This implies there should be a TEMPDENIED.  There probably should be (ie:
  the calendar store for that user 'needs work' or 'is temporarily
  unavailable for some reason').

  Completion Codes:

  003     Not all attendees received the event
  ...
  C: SENDEVENT +
  C: DTSTART: 19961231T2000-0500
  C: DTEND: 19970101T0600-0500
  C: DESCRIPTION: New year's eve party in New York. The Big
  2000!
  ...
  S: * NOTFOUND <president@whitehouse.gov>
  S: NO 000 Not all users are present on this server.

  Your completion code does not jive with the completion code text
  description for what happened.  The server should respond with 003 since
  some invitee's DID get the invitation (hence the command was partially
  completed).  Otherwise the client may see the NO and think that the
  request was rejected when it was not (for all invitees that is).

  A nit with your description and DT's: your dates are for New Years Eve,
  1997, not for 2000.  :^^)  Also, be careful that your text does not wrap
  lines as some may take that as there being some implicit CRLF in the text
  (but in vCalendar, you cannot do that w/o doing some line folding which
  you didnt do).  Perhaps removing the last part would fix that and my nit.

  If you are using vCalendar in your examples then you should have the
  begin and end markers as well.  ie:

  C: SENDEVENT +
  C: BEGIN: VCALENDAR
  C: BEGIN: VEVENT
  C: DTSTART: 19961231T2000-0500

  (dont forget the end markers too).  If you are going to prohibit the
  exchange of ToDos or multiple events in one SENDEVENT then you should
  explicitly state that.  I see no reason to prohibit them since any client
  should be able to grok the response codes (although deciding which Event
  or ToDo that the response goes to could be a bit tougher than for single
  Events/ToDos).

  2.3 RSVP Command
  The client is not required to send all of the information which
  constitutes a full event, only the information to be updated in the
  original event.

  This is not good enough.  There is info that is not modifiable by the
  invitee but MUST be used (if vCalendar is the underlying data format), in
  particular UID.   You should be more liberal in allowing the invitees
  system to decide what information must/should go back (esp. if you may
  allow different underlying data formats to be used in place of
  vCalendar!!).  The requirement for the client is that it should send all
  the necessary data needed to match the original request, based on the
  underlying data format used (in case we extend the data formats beyond
  just vCalendar).

  CONFIRMED - Can be sent by the server to indicate that other
  attendees have confirmed the meeting it was last updated or
  received by the attendee performing the RSVP.

  This text is a bit disjoint in the middle of the second line.  Perhaps it
  should be:

  CONFIRMED - Can be sent by the server to indicate that other
  attendees have confirmed the meeting since it was last updated or
  received by the attendee performing the RSVP.

  Also, there is no real way to know when the responding client acutally
  did receive the request so that last part is not really feasible.   I do
  not think that it is really any one elses business to know that other
  attendees may have confirmed (what about declined?!?) recently;
  especially if they are not being told who did, just that other(s) have.

  You do not have any response codes for NOTFOUND, PERMDENIED and
  TEMPDENIED (my addition from above).  They are necessary in case the
  organizer is no longer on that server (and left no forwarding address) or
  the organizer has updated their access controls to prohibit access by an
  invitee.  These are necessary for the case where there is some lag in
  time between the invitation and the response.

  2.4 FREEBUSY Command
  We should attempt to use the same free time format for ALL of the
  protocols we agree upon.  This will allow a better degree of
  interoperability between all the implementations (and simplify the
  addtion of more complex protocols).  I vote for the format described in
  Frank Dawsons proposals that are currently on the table.

  S: "." CRLF
  Why does the server end with a "." instead of just the normal completion
  code/response line?  Or should the normal response line be also required?
  There may be cases where it is not possible to do lookups for all the
  invitees listed in the data (see the president@whitehouse.gov example
  elsewhere in the draft).

  Again, you do not have any response codes for NOTFOUND, PERMDENIED and
  TEMPDENIED (my addition from above).  They are necessary in case there
  are invitees that do not exist or that are blocking the clinet from doing
  a free time lookup on their calendar (ie: Bill Gates or Ray Ozzie come to
  mind).  If we do not allow for free time lookups to be formatted ala
  meeting requests (ie: requests to a.com only contain user identifiers for
  a.com) then NOTFOUND is not necessary (but the others still are).

  A typo in your first scenario:
  C: SENDEVENT+
  should be
  C: SENDEVENT +

  Also, you should really put in some bogus numbers for your examples (ie:
  UID: 123456789@a.com) instead of just "unique identifier for event".

  Your first example response contains:
  C: ATTENDEE: Bob SystemB <bob@b.com>
  C: STATUS:  CONFIRMED
  but that is not in proper vCalendar format.  You should really have:
  C: ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED: Bob SystemB <bob@b.com>

  Editorial nit: Your second scenario needs a separator from the RSVP
  example above it.

  Your description of the scenario of scheduling a meeting using Bill and
  Mary needs some more 'meat' on it.  You do not make it clear initially
  that Bill is using his PC to schedule the meeting on both his calendar
  and on Marys'.  This makes the first part of the example a bit confusing
  the first time it is read.  It also implies that CIP can be used as a
  calendar access protocol which is not a good idea if we want to keep them
  (Interop vs Access) distinct.  Unless others mind, I would suggest you
  have Bill fail anonymous access to Marys' server and then have him
  authenticate and retry.

  In Marys' reply, you need to include a RESPONSE-SEQUENCE: 1 as well.  The
  extra server response line in her RSVP example:
  S: * CONFIRMED bill@abc.com
  does not belong (since the RSVP did not include Bills information AND it
  could be considered a security leak!)

  7.0 Open Issues
  Should update numeric result codes so they're more consistent.
  One possible solution is to adopt the HTTP schema for assigning numbers.
  The MSB value is used to give a basic class of error/status (ie: 1xx =
  temporary ok  status, 2xx = final ok status, etc) and the rest of the
  code is a particular error (ie: 404 = URL Not found, 503 = Internal
  Server error, 200 = Ok, etc)  I can hear the "No" replys now but it works
  well for HTTP as it allows both humans and apps to easily tell if there
  is a problem or not.

  Should say that each event is owned by a single server.
  You should say that it is owned by the Originators 'main' server (in case
  there are 'mirrors' or clusters of servers that the originator uses).

  I wont get into the other Open Issues for now as Im sure there is lots to
  cover with the stuff that has been covered...

  Bruce
  INet: Bruce_Kahn@iris.com