Re: IRIP version 4 (Part 1)

[sman@xxxxxxxxxxxx (Steve Mansour)]

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

Bruce_Kahn@iris.com wrote:

> 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.)

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?

> 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.

it is?

> 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?

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?

> 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!

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.

> 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?

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
> 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).

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?

> 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.

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?

> Ok, just how does the sender indicate their desired time limit?  I dont see
> 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
> to override or disobey this based on the receivers admins options??

I don't know what you mean here?

> 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?

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.

> 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?

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.

> 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?

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?

> 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!!!)

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.

> 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.

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

> 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.

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.


> Under 2.2 Calendar Address:
>
>     [<scheme>://<host>:<port>/]<relativeCALID>
>
> Should be:
>
>     [<scheme>://<host>[:<port>]/]<relativeCALID>
>
> to properly indicate that the port is optional.

fixed.

more comments to follow.

-Steve
begin:vcard 
n:Mansour;Steve
tel;fax:(650) 937-2103
tel;work:(650) 937-2378
x-mozilla-html:FALSE
org:Netscape
version:2.1
email;internet:sman@netscape.com
title:Judge, Jury, Executioner
adr;quoted-printable:;;501 East Middlefield Road=0D=0A;Mountain View;CA;94043;
x-mozilla-cpt:;-12672
fn:Steve Mansour
end:vcard