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

From: [email-masked] (Steve Mansour)
Date: Mon, 22 Mar 1999 21:39:54 -0800

[email-masked] wrote:

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

Why?  You aren't suggesting a delimiter character are you? That would
imply some sort of structure. :-)

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.

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

fixed as we discussed earlier.

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

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

the wording was fixed.  I'm interested in the opinions of other as to
whether or not we should add the latency parameter to the other
commands.

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

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

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 19:40:29 +0000

Steve Mansour wrote:

>> Good choice until that last part.  You should preclude some
>> characters like
>> '/' or <CR>, etc.
>

Even if we don't have structure today, a delimiter permits us to *add*
structure later if it turns out to be useful.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: [email-masked] (Steve Mansour)
Date: Mon, 29 Mar 1999 12:21:01 -0800

> structure later if it turns out to be useful.

We went through that discussion a two of the editors meetings. The general
feeling is that it's a bad idea to put *any* sort of meaning into these
strings. Even a delimiter character.

-Steve