Re: IRIP version 4 (Part 1) c II

[Bruce_Kahn@xxxxxxxx]

Steve asked:
>>> The current text reads: <relativeCALUID> is an identivier that uniquely
>>>identifies the calendar on a particular calendar store. There is no
>>>implied structure in a relativeCALID, it is an arbitrary string of 7-bit
>>>ASCII characters. It may refer to the calendar of a user or of a
>>>resource such as a conference room. It MUST be unique within the
>>>calendar store. It is recommended that the relativeCALUID be globally
>>>unique.
>>
>>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.
>
>right. In CAP we said they have to be us-ascii characters. iRIP
>addresses need to be consistent in form with CAP addresses. 

This goes along w/the previous reply (too quick to hit Send today)...  There is a larger world out there than just us US-ASCII speakers (its true!).  

Since you cannot allow some stuff like <CR> and <LF> in the relCalID you are faced w/2 possible choices to follow:

1: The URI RFC(s) allow for encoding rules of what we call the relCalID.  The MIME world has the concept of RFC 2047 encoding DBCS/MBCS info (ie: Kanji in the RFC 822 phrase part).  By utilizing these you provide the creator fo the relCalID w/a very robust set of ways to name the relCalIDs.  This is a nice thing to do if humans are ever to read/enter/modify relCalIDs by hand since it can easily encode their language specific info.
2: The RFC 822 approach of restricting the allowable characters to _printable_ US-ASCII.  This is the KISS approach and is probably best taken when humans are not going to be actively involved in reading/entering/modifying relCalIDs.

Im open to suggestions on which is a more preferable course to adopt...

>>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."?
>
>all very good points. Several problems here. First you point out that commands such as
>RECIPIENT, AUTHENTICATE, or SWITCH do not have the parameter to bound
>the latency of the reply. Second, the "given amount of time" was poor
>wording. It should read a "specified amount of time".
[Snip]
>I'm interested in the opinions of other as to whether or not we should add the latency parameter to the other commands. 

Actually I can see the RECIPIENT command taking some time to complete if the calID is for a different CS (ie: the current CS is cal.bar.com and the calID has a CSID of cal.foo.com!).  No good solution comes to mind now on how to best alleviate this since a relCalID can be anything (unless you make it RECIPIENT timeout [calID | relCalID] but that is UGLY!!).

Also be careful of using "specified amount of time" for commands that dont have this ability.  I can see its use on RECIPIENT of you are to allow iRIP addresses that are for different CS's but it gets ugly if you try (ie: each RECIPIENT on the _same_ CS has a different timeout value!).  By your text Im not sure if you plan to add some timeout value to the AUTHENTICATE and SWITCH commands.  I can see this being implementation dependent and adjustable (ie: 5 min on slow 14.4 dial up links but 1 min in a 100Mb LAN) so caveat editors...  Perhaps a recomendation to implementors on this issue is in order.

>>>  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?
>
>Currently it is not specified.  Suggestions are welcome. 

Given the change of streaming results as they are ready instead of the former pending all results into 1 massive response I think that the expected behaviour of ABORT is terminate the ICALDATA command (unless its useable elsewhere in the state machine), return any pending results that are queued still and to not process other RECIPIENTs.  Those that have completed are considered just that, completed.  Since the sender will have that info available it can do what it wants (ie: retry the uncompleted ones later or "undo" the ones that completed, somehow).  The KISS approach allows the sender to decide what course of action it wants to persue since it did issue the ABORT.  (No need to waste more cycles undoing work that the sender may not want undone...)

>It is hard to roll-back ITIP messages. In fact, it is impossible.
>Suppose I've sent one REQEUST method to a remote site. Suppose it takes
>a *long* time. As I'm sending the REQUEST to another site, my latency
>time runs out, and the sender tells me to ABORT.  What do I do? There is
>NO way to undo the REQUEST method already sent to the remote site. There
>is no ITIP method that can be used to say "ignore the last thing you
>got". 

Sure, but a second iTIP message to the same RECIPIENT w/updated info or different METHOD: will achieve just that.  Thats just how the iMIP binding handles it right; 2 separate iMIP messages.  There is no iTIP message for what you want, its all in the data that gets sent in the iTIP message.  As I noted above, its simpler if you let the sender decide if they want to recind the sent iTIP/iRIP messages or not.  If so, it can follow the basic method outlined in the iTIP RFC (and exampled in the iMIP RFC I think).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...