Subject: Re: IRIP version 4 (Part 1) - DEQUEUE

From: [email-masked]
Date: Sun, 21 Mar 1999 19:55:19 GMT

Doug replied (in part):
>> 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.

1: The progress bar is not a progress bar if the sender CS has NO (zero,
NIL, NULL) ways of knowing how may other entries are available; all a
process can do is say "Processing yet another reply...".

If I send a reply to a message, can you say w/ANY certainty (luck excluded)
that it is "reply 1 of 32"??  I doubt it.  If you can, you should get your
own 1-900 #.

The suggestion of a LIST, COUNT or DEQUEUE_COUNT command that simply
returns a response code and numeric value still stands.

2: Correct, it was late and I misspoke.  iRIP is CS<->CS (of course my CUA
could have a CS built in as per Franks comments of long ago :^) )

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Mar 1999 13:06:52 -0800 (PST)

> From: [email-masked]
> Date: Sun, 21 Mar 1999 19:55:19 GMT
> 
> Doug replied (in part):

If you can tell me how many email you are going to get today,
then I'll believe this is achievable in calendaring :-)

> returns a response code and numeric value still stands.

What if 1 more is queued after you ask (from another thread, or
perhaps someone has pushd iCalendar data for you and you have
to poll for it) ?

-Doug

---

From: [email-masked]
Date: Tue, 30 Mar 1999 04:16:33 GMT

>then I'll believe this is achievable in calendaring :-)

I can tell you as soon as my POP3 or IMAP client attach to the server and
begin to pull it down each time... :^b

>perhaps someone has pushd iCalendar data for you and you have

Sounds like you are fishing to see how I implement my CS.  To date there is
no discussion in the architecture of in iRIP/iTIP/CAP about exclusivity of
access to a particular calendar at any given time like you get in, say,
POP3 while retrieving email.  I think this is an oversight that we probably
need to address somewhere before we get to RFC w/iRIP and CAP...  Thanks
for helping to tickle my gray cells on this issue (it was one of the ones I
sent in those series of blank emails last week)!

I can however tell you when my POP3 or IMAP client are retrieving email
exactly how many msgs they expect to pull down that time.  Whether or not
they 'repoll' for any new msgs depends on the way we handle this
exclusivity issue...  If I recall the older NOOP command from somewhere
(ICAP??) was used to achieve this.  Then again the sender could simply ask
"Any new/more msgs for me" when its done it if was that paranoid.  There
are simple solutions to these kinds problems... ;^)

Bruce
<missing .sig file on laptop; sigh>

---

From: Doug Royer <[email-masked]>
Date: Mon, 29 Mar 1999 21:58:58 -0800 (PST)

> Date: Tue, 30 Mar 1999 04:16:33 GMT
> 
> Doug replied:

Thats an implementation detail - I just do not see it as a protocol issue.

FTP for example can show you has codes as the data is transfered.
It has nothing to do with the protocol. It has to do with the
implementation of the client. I see CAP the same.

> Sounds like you are fishing to see how I implement my CS.

No.

>  To date there is

Even if that is added, I do not think we are talking the same 'stuff'.

You still can't tell how many messages are QUEUED for delivery
with POP or IMAP. You can only tell how many are in your INBOX at
the point in time that you ask. Not the same issue.

iRIP in this role is like an RFC-821 (not 822) MTA.
CAP is like IMAP and POP.

You can ask CAP how many appointments you have.
You can ask IMAP and POP how many messages you have.

You can not ask your MTA with POP or IMAP how many messages have not
been delivered to you INBOX and are still queued by any MTA.

The model for an MTA and iRIP are not the same in another way.
SMPT (rfc821 for the most part) is allowed through the firewall.
That's why we have spam (plus the fact that connections are
not authenticated).

iRIP across a firewall tries to deal with those issue in two ways:

	1) You can not allow any iRIP into your site:

	   And you can poll a trusted site and ask for any
	   items queued for your site. Not something most CUA's
	   would be doing. More like a Calendar Transfer Agent (CTA?)
	   A CTA could be part of the CS. No CUA involved in
	   the transfer.
	   
	   Or you could poll a non-trusted site and take your
	   chances and hope its not calendar spam. No CUA involved
	   in the transfer.
	   
	2) You can allow iRIP through the firewal:
	
	   In which case the CTA at the sending side would contact the
	   CTA at the receiving site and transfer data. Again - No CUA
	   involved.

Or you ~could~ use iRIP in the CUA. Why not use CAP?
CAP is designed for (CUA <-> CS) . iRIP is designed for (CS <-> CS).

Or your CUA could act as a CTA. However the issues and problems from
a local CUA to remote CTA(CS?) are not exactly the same.

CAP is how CUAs should talk to CS's. In CAP a user authenticates
to a CS.

iRIP is how CS's should talk to CS's. In iRIP a CS authenticates
to a CS (trusted or not). Without any of user credentials.

-Doug