Re: IRIP version 4 (Part 1)

[Doug Royer <Doug.Royer@xxxxxxx>]

> From: Bruce_Kahn@iris.com
> Date: Mon, 15 Mar 1999 05:15:19 GMT
> 
> ...
> 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? 

Retrieve a reply that was delayed.

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

No.

> Also, how does my CUA speaking iRIP know how many there are (ala POP3's or
> IMAP's LIST command).

When EMAIL is queued - can you tell? - No.

The primary usage for iRIP is CS <-> CS, although there is nothing
from keeping the CUA from using iRIP.

>  In POP3 I can do a LIST and then RETRieve just msg 3 of 30 if I
> wanted to.

iRIP servers are not alternate storage systems for CUA's. They simply
allow you to work out through a firewall or disconnected system. They
queue the calendar data in ways that are compatible with the iCalendar
objects.

> This new ability would increase the complexity of your Send
> state but not by much.  It would however make the UI more user friendly.

However what you are describing are CUA needs. I would suggest they
may be out of scope for iRIP.

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

Unless I miss your point, 'ICALDATA:<timeout>' ?
If its the same timeout that goes with ICALDATA, no - they would
not be compliant.

> 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 Receive 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 don't understand the above question.

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

Yes - and I thought there was some kind of resource limit error code(?).
 
> 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!!!)

There is a response for each RECIPIENT.

> 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 addressed by a reply codes of abort not in progress and
abort successful.

A sender would get an:

	abort-code
OR
	It will get a non-abort reply code
	AND an abort reply code.

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

1) Orthogonal - No such limitation. A progress bar can be updated
   by the code that is getting data. Or you could thread your app.
   
2) iRIP is designed for CS <-> CS communications.

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

Its an URI/URL, so it has the same ability and problems.

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

Three possabilities:

	1) You get your data before timeout.
	
		Not an issue.
		
	2) You get the continuation request.
	
		Not an issue.
		
	3) You get nothing.
		
		The sender decides what to do:
		
			a) Wait longer.

			b) disconnect.
			
I don't think the draft addresses that.

> Under 3.1.3 CAPABILITY:
> 
> 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

The same thing you would do with any other non-compliant server - you best.

> Just what precautions should 'experimental' or non-standard values take in
> order to avoid possible name collision w/future "standard" names?

None - standardize or register them! 

The fact that there is no way to keep X- names out of the way
forces them to be registered one way or another.

-Doug
-------------------------------------------------------------------
Doug.Royer@Sun.COM		http://playground.sun.com/~dougr
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL