Re: IRIP version 4 (Part 1)

[Bruce_Kahn@xxxxxxxx]

Here are some comments/questions about this iRIP draft.  They are in order
of the draft contents to make citations easier.

First off, how about a senders and receivers state diagram instead of just
a receivers?  That way there could be consistant terminology used when
discussing what mode a sender or receiver are in (esp. since you allow role
switching.)

Under 2.1 Protocol States:

1. begin sending an ITIP message to the receiver by issuing the
   RECIPIENT command,

This is inconsistant w/the state diagram.  According to it, the sender must
issue a RECEIVE command first.  Perhaps you meant to say RECIPIENT takes
you from Authenticated to Send modes and then further RECIPIENT values can
be sent (or ABORT or just a simple ICALDATA if only 1 RECIPIENT).  Yes?

2. re-authenticate as a different calendar using the AUTHENTICATE
   command,

What happens if the reauthentication fails or the attempt is rejected by
the CS?  What is the current mode?  I'd suggest a harsh penalty like CS
disconnects the user to avoid any loopholes or repeated hack attempts on a
single connection!

3. request a queued ITIP message for the authenticated calendar using
   the DEQUEUE command,

Is this intended to allow a CUA to attach to the CS over iRIP and
"retrieve" a calendar entry?  I think what is somewhat confusing to me is
the use of Send and Receive as "back to back" states in the state diagram.
In the "Send" case it is really a "Pre-Receive" case as the CS is not
"sending" anything back (except responses to RECIPIENT or ABORT commands).

Is the intent to keep a simple state diagram?  If your #3 above is intended
for the use I asked about then perhaps you may want to consider separate
Send and Receive parts of the diagram that do not lead into each other.
The "Send" mode would be quite simple really and you'd have to rename your
current "Send" to "Pre-Receive" or something similar.

Is there any way to select which iTIP msg to "dequeue" if there are many?
Also, how does my CUA speaking iRIP know how many there are (ala POP3's or
IMAP's LIST command).  In POP3 I can do a LIST and then RETRieve just msg 3
of 30 if I wanted to.  This new ability would increase the complexity of
your Send state but not by much.  It would however make the UI more user
friendly.

If the receiver indicates
that the request could not be completed in the time specified by the
sender the protocol enters the Idle state.

Ok, just how does the sender indicate their desired time limit?  I dont see
anything to do this on first pass.  Also, will the receiver have the option
to override or disobey this based on the receivers admins options??

At this point the sender
must decide how to proceed. If the sender issues the CONTINUE command,
the command in progress continues and the session returns to the
Receive state. If the sender issues the ABORT command the command is
aborted and the session is returned to the Authenticated state.

A couple ones here too.  W/o diving in further in the draft, just how will
the receiver tell the sender just how much or who was done and who was not?
Is the response along the lines of "Still working to save this out to 3
more users" or just "Not done yet, do you want me to continue?"    If the
mode is returned to the Recieve state, does the time limit again get used
(ie: Wait another minute for the receiver to complete??) or is it an
indefinite return until completed?

You dont have the ability of the receiver to fail out and have the mode
reset to Authenticated.  An example of this would be if the receiver ran
out of disk space or someone calendar became corrupted and it was unable to
complete the transaction.  Or are you considering this as "completed" but
just unsuccessful?

Is there any way for the sender to find out which RECIPIENTs were completed
and which were not??  For example, I send to 10 RECIPIENTs but for some
reason the server can only complete 6 of them.  It would be really really
nice to know who completed successfully and who didnt so I dont have to
redo the entire operation and double book something (or so I could DEQUEUE
the entry from those successful ones until it works for all 10!!!)

A sender can abort an operation in progress while it is in the Receive
state by sending an ABORT command to the receiver.

There is a window of opportunity for the receiver to actually complete the
receive before it realizes that the sender sent an ABORT.  (Or the receiver
may not poll for the ABORT often enough, etc).  You should codify the
proper behaviour for this senario.

Issuing the DEQUEUE command changes the protocol
to the Receive state. The receiver replies with a single queued [ITIP]
request or a status code to indicate that there are no more queued
requests for the authenticated user.

Poor choice of actions.  This prevents a CUA from properly indicating
progress as it can only say "Im getting another iTIP msg of some unknown
quantity" (ie: the candy cane progress bar) instead of the actual progress
bar.  See comments above about POP3's LIST.

Under 2.2 Calendar Address:

    [<scheme>://<host>:<port>/]<relativeCALID>

Should be:

    [<scheme>://<host>[:<port>]/]<relativeCALID>

to properly indicate that the port is optional.

    <host> is address of the computer on which the IRIP server is
           running. This is also called the Calendar Store ID or CSID.

Can I specify an IP address or must it be a DNS name??  Id think it would
be odd to have a CSID of 128.221.2.45 instead of calstore.dg.com.  (The
term "address" above conotes IP to me but maybe you are using the RFC 2038
terminology.)

    <relativeCALID> is an identifier that uniquely identifies the calendar
           on a particular calendar store. There is no implied structure in
           a relativeCALID, it is an arbitrary string of charac

Good choice until that last part.  You should preclude some characters like
'/' or <CR>, etc.  Perhaps you want to tighten this sequence up a bit to be
only more like the RFC 2038 text that describes HTTP URLs, etc.  That way
we wont get raw Kanji, etc that makes parsing nearly impossible.

Under 2.3 Bounded Latency:

[IRIP] is designed so that the Sender can either obtain an immediate
response from a request or discover within a known amount of time that
the request cannot be completed...

Not quite.  "Cannot be" is very different from "has not yet been".  Be
careful w/absolutes like that since it may just be a server load issue,
etc.

When the Sender initiates a command
that the Receiver cannot complete within a given amount of time, the
Receiver can return an error code to the Sender indicating this
condition.

This is only true of the ICALDATA command from what Ive seen.  Its not true
from the RECIPIENT, AUTHENTICATE, or SWITCH commands.  Also, what is "a
given amount of time"?  Are you predetermining the min. response times or
just assuming its "built in."?

The ABORT command causes the Receiver to discard the current
command and return to the Authenticated state.

Pardon me??  Discard what command?  Do you mean discard the ICALDATA??  If
so, for all RECIPIENTs or just those not yet completed?  Or do you really
mean "abort the current command"?  What should be the proper receivers
behaviour on an ABORT for RECIPIENTs that it has already processed?

Under 3.1 Commands:

  What good is the CAPABILITY command in the Send state?  This should be
restricted to the Connected and Authenticated states (since it could vary
based on if the user is authenticated or not).

  What about some command  to enable TLS encryption or authentication of
data ala StartTLS of LDAP & IMAP (or STLS for POP3)??!  This would be good
so we could avoid having irip: and irips: and taking up 2 TCP/IP ports.  Be
sure to add the CAPABILITY command to the new modes for this case or better
clarify that the results for a given mode (ie: Connected mode but w/ or w/o
TLS could yield different values! See LDAP RFC for examples using SASL).

  Your state diagram at top has SWITCH valid in the Connected state but
your command table does not.  Pick one.

A response MAY include an [ICAL] object.  This is followed by a
<CRLF>.<CRLF> and a reply code.

If there is no iCal object then MAY or MUST there be a <CRLF>.<CRLF> before
the reply code?  Clearly state when that sequence will or will not be
there.

Under 3.1.1 ABORT

The ABORT command is issued by the sender to stop an ICALDATA request
from being processed further.

Not 100% accurate.  ABORT can be used in the Send mode to abort the process
moving into the Receive mode via the ICALDATA.  It can also be issued in an
attempt to end a DEQUEUE command (w/o being in the Idle mode).

According to the text the general format of commands and arguments is:

<command> [arguments...]

Howeve the example under 3.1.1 has:

S: ICALDATA:10

Note that there is a ':' instead of a LWSP as semi-expected.  I didnt check
the BNF later in the draft yet so this may be legit although Id recommend
LWSP be used as the delimiter for commands so parsing out a command is as
simple as looking for the 1st LWSP or the terminating <CRLF>

In that same example is the line:
<10 seconds elapse...>
R: .

This gets back to is <CRLF>.<CRLF> always there before a reply code or not.
Not clear if this is on purpose or residual so Im flagging it.

In the example you see:
>R: 2.0.2 irip://cal.example.com/abc
>R: 2.0.2 irip://cal.example.com/def
but later in 3.1.4 you see a different argument to the reply code of 2.0.2:
>R: 2.0.2  Reply Pending
so Im curious which should be used and if they follow the iCal/iTIP format
for reply codes.  (Need that online draft handy!)

The Receiver will issue the 8.2 reply code if it receives an ABORT when
the ICALDATA command is not in progress.

  Make that ICALDATA or DEQUEUE commands.  The text talks about returning a
reply code of 8.2 when there is no ICALDATA (or presumably DEQUEUE!)
command in progress.  I infer from this that 8.2 is "Inappropriate command"
or something like that.  However when I look it up below it is defined as "
ICAL OBJECT TOO BIG".  Seems to me that this description is wrong or, more
likely, there is just a need for a new reply code meaning "Inappropriate
command".  This reply code could also be used for DISCONNECT in the
Send/Recieve modes, etc.

Under 3.1.2 AUTHENTICATE:
  If we add some form of "StartTLS" command then dont forget to update the
text here to allow for it before or after authentication takes place.

  The text indicates that the reply code of 6.1 is to be used for
mechanisms that are not supported.  However I dont see this listed in the
table of reply codes later on.  If this is not in iCal then dont forget to
add it here.  Othewise, never mind.  (The same applies to the other reply
codes expliclty listed in this block of text; 6.x family)

  As before, explicitly declare what the behaviour is to be when
reauthentication fails (ala LDAPs RFC or was that LDAP w/SASL?)

Under 3.1.2.1 Authentication with Proxy Access
  You use the term "caladdress URL" or "caladdress" but elsewhere you refer
to CALID.  Stick to one format.  Also, are the allowed values
relativeCALIDs or Qualified CALIDs?

Under 3.1.2.2 Selection of an Authentication Mechanism:
>There is no
>minimum level of security which an [IRIP] compliant server is required
>to suppot.

Why is not at least SASL Plain not a minimum supported mechanism (w/ or w/o
TLS)?  This is _not_ to say that it cannot be 'disabled' by the admin's
config or somehow otherwise toggled on/off.  However, w/o some minimum
required mechanism then you have a very very slim chance of some form of
interop!

>This may result in iRIP servers which are unable to talk to
>each other through lack of a common mechanism.  This issue is covered
>in more detail in the Security Considerations section of this
>document.

Agree'd to the first part.  However looking at the 5.x section on security
I only saw talk of Spoofing, Eavesdropping and Connection Flooding.  No
direct discussion of interop problems due to no common authentcation
mechanism that I could see.

Under 3.1.3 CAPABILITY:

>The CAPABILITY
>command can be issued in any connection state.

Its not that useful between RECIPIENTS and ICALDATA, etc really.  A sender
should use this command to get info in advance so that it can better work
with the receiver and do the right stuff.  KISS and just make it available
in the Connected and Authenticated states.

The response is to be of the format "<name>[=<value>]" but is the = of any
real use?  Why not just use LWSP (1 or more) as the delimiter (ala IMAP)?

The sample after the table is incorrect based on the text.  The relevant
description of the response is
>The server must return a CAPABILITY response
>with "IRIPrev1" as one of the listed capabilities.
and
>The format of the capabilities response is a series of lines with the
>form <name>[=<value>]. Each name-value pair is delimited by a <CRLF>
>character sequence.
Hence, the first 2 examples should start like:
S: CAPABILITY
R: IRIPrev1
R: AUTH=KERBEROS_V4

The table clearly states the # of times a response may occur.  What should
the sender do if this rule is violated?  For example:
S: CAPABILITY
R: IRIPrev1
R: AUTH=KERBEROS_V4
R: IRIPrev1

or

S: CAPABILITY
R: AUTH=KERBEROS_V4
R: .
R: 2.0

Just what precautions should 'experimental' or non-standard values take in
order to avoid possible name collision w/future "standard" names?  For
example, Vendor A wants to create and use a new value "FOO" to make their
CUA and CS work "better".  Just how do we avoid their 'extension' FOO from
conflicting with iRIPrev2's new FOO?  There may be no safe answer here as
it gets into "X-" vs some other mechansim, etc...

Under 3.1.4 CONTINUE:

  Why not use a LWSP as the delimit rather than the ':'.  (Same discussion
as for use w/ICALDATA above.)

  The example does not jive w/the discussion of ICALDATA that follows.
According to ICALDATA, the response should be MIME encapsulated iTIP
message but the example just has:
S: CONTINUE:10
R: BEGIN:VCALENDAR
...
(no MIME encapsulate, just raw iCalendar/iTIP)

Under 3.1.5 DEQUEUE:

  I just realized that there is no latency option for this command hence
the state diagram is a bit misleading for this command as the sender would
never be in the Idle state for this command, they are always in the Receive
mode until it completes.  I appreciate the KISS on the state diagram but
its not totally accurate (</nitpicking>)

Under 3.1.6 DISCONNECT:
>It can be sent from any state.

Not true.  The state diagram has it only valid in Connected and
Authenticated.  If in the Send, Receive, or Idle states the sender must
ABORT first and then DISCONNECT.  Pick one be consistant.

Under 3.1.7 ICALDATA:

The line:
R: <MIME encapsulated ITIP Message>
is misleading since prior (and later) examples show just "R: ." and "R:
2....." lines w/NO returned MIME encapsulated iTIP message.  Which do you
intend; mandatory iTIP message as a reply or optional?  Later text implies
its optional but is phrased such that the entire reply (iTIP message, CRLF
. CRLF and reply code) is optional:
>The receiver
>reply may optionally contain an ITIP message followed by the special
>sequence <CRLF>.<CRLF> followed by a reply code for each of the
>recipients.
(Rephrase so its clear that just the iTIP message is optional please)

Also, the example format shows:
R: .
R: <reply code>
but MANY of the examples in the draft return several reply codes.  Just
what is the proper behaviour: 1 reply code total or 1 reply code per
ATTENDEE/CALID??  The last text of the 3.1.8 section covers this but it
should be in this section too or in place of in 3.1.8.

There is no new reply code for "Unable to process" or "Unable to accept or
queue" for a particular CALID.  An example would be an employee whose left
the company but they do not have a forwarding address and wont want to
queue it up for no reason (or just a bogus CALID that has a typo, etc).
Actually I see later this is described as 5.3 (under 3.1.8) but its not
defined anywhere in the draft.  However this code is for the RECIPIENT
command and does not really cover the "Unable to accept or queue" for some
CALID that it thought it could queue for.

Under 3.1.8 RECIPIENT:

  There is mention of a reply code 5.3 for "unknown" CALIDs but its not in
any table in the draft.

Under 3.1.9 SWITCH:
>After a switch command is executed and the
>new Sender authenticates, all queued commands that the new Sender has
>queued for the new Receiver will be delivered.

Whoa folks! This is at odds w/the state diagram and all prior text.  There
has been no mention of automagically processing queued "commands" (I assume
these to be iTIP messages really as opposed to iRIP commands).  Where did
this concept magically spring from??

>The Sender must be in the
>authenticated state before the SWITCH command can be used.

This does not jive w/the state diagram or prior text that claim SWITCH can
be done in either the Connected OR Authentiated states.

Time to get some rest before tomorrows sessions so Ill send comments on
Sections 3.2 and later sometime tomorow (I hope).

Bruce