Subject: Re: IRIP version 4 (Part 1)

From: [email-masked]
Date: Mon, 15 Mar 1999 05:15:19 GMT

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

---

From: [email-masked] (Steve Mansour)
Date: Sun, 21 Mar 1999 23:18:21 -0800

I'm going to do this in installments since you have so many comments.  Here's
the first batch.
-Steve

> discussing what mode a sender or receiver are in (esp. since you allow role

hmm... the state diagram describes the state of the connection, I hadn't really
thought about it from a sender versus receiver point of view. Could you be more
specific about how it would change?  Maybe you could do a little subset from
the sender's point of view, then from the receiver's point of view so I could
see how they differ?

> This is inconsistant w/the state diagram.

it is?

> According to it, the sender must

Yes. That's how I read the state diagram. The boxes represent the state, the
command name in caps cause the state to change. So, when you're in the
Authenticated state, and you issue a RECIPIENT command, you move to the Send
state.  Further RECIPIENT commands keep you in the Send state.  ABORT takes you
back to Authenticated. ICALDATA takes you to the Receive state.

Is this clear or do we need to add something to the text?

> disconnects the user to avoid any loopholes or repeated hack attempts on a

good point.

I've added this under the Security Considerations. Let's talk about it if you
think it should be a requirement for a conforming implementation.

> "retrieve" a calendar entry?

Let's clarify some things. In iRIP, the DEQUEUE command can only retrieve or
pass along queued iTIP messages.

> I think what is somewhat confusing to me is

Why?  I authenticate to a particular calendar address (remember, we don't know
about calendar users in iTIP, only about calendars).  Once we have establised
the calendar, all we need to do is tell the receiver we wish to DEQUEUE. It
will then return any queued message for the calendar to which we have
authenticated.  If there are no queued messages then it returns an appropriate
response code.

I'm missing the issue here?

One issue I see is the details of how to authenticate to a calendar. I
discussed this a little with Paul Hill. It will be addressed.

> Is the intent to keep a simple state diagram?

Well, yes I want the state diagram to be as simple as it can be. But this
seemed like THE way to do it. You want to suggest something else?

> Is there any way to select which iTIP msg to "dequeue" if there are many?

currently, no.  Is this important to you?

> your Send state but not by much.  It would however make the UI more user

We *can* do this. But remember that IRIP is meant to be a server to server
protocol. On things like the DEQUEUE command, I don't really see the user
getting involved. I would just see one server periodically picking up any
messages that were queued for it.

Can  you give me a scenario of what you're thinking?

> anything to do this on first pass.

right. Looks like the DEQUEUE command needs an optional latencyTime parameter.

> Also, will the receiver have the option

I don't know what you mean here?

> the receiver tell the sender just how much or who was done and who was not?

I still don't see the problem. Who cares how much was done? A sender's mission
during the DEQUEUE is to simply dequeue messages for the authenticated store
until there are no more.  The server doesn't report its progress to anybody. I
think of it like an smtp server passing mail from one server to another. They
don't really ask each other how many total messages will be transferred or how
many octets will be sent. They simply send it all til they're done.

In iRIP, if an ABORT occurs during a DEQUEUE, the sender will have to ask for
queued messages again some other time.  As far as "who" was done, there is no
"who". There are simply messages stored up for a particular calendar.

Can you articulate the issue some other way? I just don't see it.

> indefinite return until completed?

I cannot imagine a scenario where these messages are applicable. IRIP is server
to server. I just don't see a message to a user coming into play here.  Or
maybe you're envisioning a use for IRIP that I just haven't thought about.

> complete the transaction.  Or are you considering this as "completed" but

Couldn't the receiver simply send a response code to indicate "completed but
unsuccessful". Perhaps we simply need to clarify the response codes better.  We
currently don't have a response code for "receiver out of storage space".  But,
as another example, we do have 8.2 - ICAL OBJECT TOO BIG.  I suppose we should
state more clearly what happened on the receiver when these response codes are
returned. In the case of 8.2 I would assume that the receiver did not store the
ical object.

Would this sort of clarification deal with your issues?

> the entry from those successful ones until it works for all 10!!!)

The sender of an IRIP message will always know what happened. When a message is
sent (or fanned out) there is a separate response code for each calendar to
which it is sent. Sometimes the response code will be 2.0.7 - QUEUED.  Is that
a successful completion or not? Who knows? It simply means that the message was
successfully queued for delivery. So, you know as much as you can.

You will also know exactly which messages were not delivered in any form. Check
out Example 6.4.1 which shows how you can cancel the delivery of a message
because one of the recipients was found to be invalid.

> proper behaviour for this senario.

That was covered in the ABORT command description. Have a look. Let me know if
it's not sufficient.

> bar.  See comments above about POP3's LIST.

POP was meant to talk to an MUA. IRIP is to send messages between servers. If
this were a CUA to CS protocol, we'd have to deal with the problem. But I don't
think we do.

> to properly indicate that the port is optional.

fixed.

more comments to follow.

-Steve

---

From: [email-masked] (Steve Mansour)
Date: Tue, 23 Mar 1999 08:34:54 -0800

> as for use w/ICALDATA above.)

already fixed :)

> (no MIME encapsulate, just raw iCalendar/iTIP)

good catch.
fixed.

> its not totally accurate (</nitpicking>)

I see what you mean.

Any suggestions on the state diagram?

> ABORT first and then DISCONNECT.  Pick one be consistant.

Right. People were loud and clear about the one to pick: DISCONNECT can happen
anywhere. The problem was simply that the character drawing of the state
diagram gets too ugly. It seems to me we have the following choices:

   * Just before or after the state diagram we can note that DISCONNECT can be
     issued from any state even though it is not shown in the diagram.
   * we can remove the state diagram altogether
   * someone can dream up an inspired solution.

Currently I've added the note to the text.

> (Rephrase so its clear that just the iTIP message is optional please)

It now reads:

     The receiver reply MAY contain an [ITIP] message. The reply MUST
     contain the special sequence <CRLF>.<CRLF> followed by a reply code
     for each RECIPIENT.

> should be in this section too or in place of in 3.1.8.

I'm hoping the phrase above covers this for you. In particular "... followed by
a reply code for each RECIPIENT.  The RECIPIENTS may be different from the
ATTENDEEs in the ICAL body. In fact, in the case of a PUBLISH, there are no
ATTENDEEs.

> CALID that it thought it could queue for.

This has been a constant area of confusion. There are reply codes defined in
iTIP.  This draft was intended to list those reply codes needed that were not
specified in iTIP. Even though we were pushed that direction in the beginning,
it's probably a bad idea. We should probably just repeat the iTIP error codes
in this draft and add the ones we need so that implementers can refer to one
table of reply codes.

What do you think?

>   There is mention of a reply code 5.3 for "unknown" CALIDs but its not in

it's in ITIP

> this concept magically spring from??

hmm... That was the sole purpose for the SWITCH command. It's mission is this:

Company A's irip server can connect to Company B's irip server. But, due to
firewall issues B cannot connect to A. So, the two companies establish a trust
relationship between each other. Irip messages sent from B to A are queued on
B.   A periodically polls B to collect queued messages. After A connects to B,
A issues the SWITCH command.  Anything queued is then transferred from B to A.

Do you see another use for the SWITCH command. Could you give me an example?

> be done in either the Connected OR Authentiated states.

That's not the way I read the state diagram. I read it SWITCH can be executed
from either the Authenticated or Connected states. But in either case, after
SWITCH is executed, the connection state goes to Connected.

What is confusing you here?  I'll try to clear it up, but I don't see the
problem.

-Steve