Subject: Re: Fwd: I-D ACTION:draft-stracke-calsch-crisp-00.txt

From: [email-masked]
Date: Thu, 17 Aug 2000 12:10:44 -0400

Doug asked:
>What is "an iTIP service provider for CAP servers" ?

An iTIP service provider is a task/process/library/module that services 
the iTIP needs of its caller/user.  In this case, it could be that the CAP 
server does not need to do any iTIP work of its own, it would just "load 
and use" the CRISP server to do any iTIP work for it. 

This is difference between being a simplified iTIP (nee iRIP) gateway INTO a CAP 
server/service and an "iTIP service provider" FOR a CAP server/service.

The former is inbound oriented, the latter is outbound oriented.

>What is "iMIP bridging" ?

Pardon that phrase; its my mental notation for trying to categorize the 
boundaries of a CRISP servers functionality.  Taking a step back to 
clarify this a bit. 

Doug wrote "CRISP is a CAP server that is limited to iTIP functionality." so this implys it supports all iTIP bindings: both iMIP and iRIP.  As 
such CRISP could be construed as "the iTIP engine or gateway" for a CAP 
server.  However Im getting the distinct feeling (at least from Doug) that 
CRISP is intended ONLY for iRIP ("It is in response to several peoples desire to keep iRIP alive." plus its name"CAP Realtime iTIP-based..." )  As such, a CRISP server 
does not deal with any iMIP messages.  If that is so, then the text should 
be updated to reflect the iRIP only focus so that someone does not get the 
mistaken impression that CRISP "can do iMIP" since iMIP is a binding of 
iTIP.

<DIGRESSION FROM CRISP>
>Who ever said that iRIP could not do iMIP? 

I claim that they are separate critters: iMIP is "store and forward" (aka 
email) and iRIP is "realtime" (aka HTTP like).  As such, once an "iRIP 
server" passed the request to an "iMIP server" (ie: a fallback of some 
kind) then iRIP is no longer being used, iMIP is.  So its a bit of a 
strech to say "iRIP can do iMIP"...  I guess one could build a "realtime" 
server over email but I think they'd have a hard time convincing customers 
it was "realtime".

>So what is the difference?

Whats the difference between store-and-forward and realtime sending of 
data?

I wont get into the addressing issues between CAP & iTIP; they've already 
been raised at least once before...
</DIGRESSION>

John:  Care to clarify the air or do you prefer to watch Doug and I 
discuss this further??

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: Thu, 17 Aug 2000 10:08:06 -0700

[email-masked] wrote:
> the iTIP needs of its caller/user.  In this case, it could be that the
> CAP server does not need to do any iTIP work of its own, it would just
> "load and use" the CRISP server to do any iTIP work for it.

Okay - where in CRISP does it say that? Or what in CRISP makes
you think that is what it is?

> This is difference between being a simplified iTIP (nee iRIP) gateway
> INTO a CAP server/service and an "iTIP service provider" FOR a CAP
> server/service.

I have not seen any such proposal on this list.

> Doug wrote "CRISP is a CAP server that is limited to iTIP functionality."
> so this implys it supports all iTIP bindings: both iMIP and iRIP.  As
> server.  However Im getting the distinct feeling (at least from Doug)
> that CRISP is intended ONLY for iRIP ("It is in response to several
> peoples desire to keep iRIP alive." plus its name"CAP Realtime
> iTIP-based..." )  As such, a CRISP server does not deal with any iMIP
> messages.

I'll answer as many differant ways as I can because I still am
not sure why you think that CRISP would do more than CAP or iRIP.

CRISP, CAP, and iIRIP servers do not not act as an MTA and gather
iMIP messages. CRISP and CAP servers can generate iMIP messages.

You can not send an iMIP message to: CAP, CRISP, or iRIP servers.
As they all (at least) support iTIP. None of them support iMIP being
sent directly to them.

I don't recall if iRIP could generate an iMIP message.

So both CAP and CRISP servers do deal with iMIP - generate only.

>  If that is so, then the text should be updated to reflect the
> iRIP only focus so that someone does not get the mistaken impression that
> CRISP "can do iMIP" since iMIP is a binding of iTIP.

Nether could iRIP. So why do you think that CAP or CRISP could?

> kind) then iRIP is no longer being used, iMIP is.

iRIP never specified how the data would get to the end user.
I don't recall it ever saying that an iRIP server would pass
the request to an iMIP server (By that do you mean MTA?).

>  So its a bit of a
> server over email but I think they'd have a hard time convincing
> customers it was "realtime".

I don't recall CAP, CRISP, or iRIP saying that. I did not mean
to say that. Are you asking for that to be added to CAP/CRISP?

> Whats the difference between store-and-forward and realtime sending of

I see you as asking: "Something that no one has talked about or
posted - does crisp do that?".

-Doug