Subject: Re: IRIP version 4 (Part 1) c II

From: [email-masked]
Date: Wed, 24 Mar 1999 20:26:46 GMT

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: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Mar 1999 14:24:53 -0800 (PST)

> From: [email-masked]
> Date: Wed, 24 Mar 1999 20:26:46 GMT
> ...

Item (2): Only the header names, not the values:

	From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <[email-masked]>

However that's not an URL and not how they are encoded.

I vote for RFC1723 (or the appropriate replacement).

-Doug