Re: IRIP version 4 (Part 2) - Bidirectional queuing

[Bruce_Kahn@xxxxxxxx]

Doug replied (in part):
>> Under 3.3 Bi-Directional Queue Operation:
>>
>> Another example of why 2 servers may not be able to immediately
establish a
>> session is that the admin has configured some policy to prevent this.
>> For example, in some European countries a modem connection may be long
>> distance and they want to restrict these kinds of connections to being
>> at night only.  As a result, the requests get queued until evening
before
>> being pass along; there may be no intermediate 3rd host.
>
>Not the same issue. Then is just a disconnected host.

Not really.  The host can connect to others locally, over WAN, etc but it
cannot (due to policy rules) connect via dial-up at certain times.  This is
not the same as disconnected; more like "intermittantly connected" and to
just some hosts, not ALL.

This system exists now and has for years; its been in Lotus Notes for many
releases now and for this exact reason.  The intent of this is to educate
that bi-directional queue operations do not always require a 3rd host to be
involved; there can be other reasons.

>> Hmm, just what would prevent server katt.pcweek.com from authenticating
to
>> the server C.foobar.com and then doing DEQUEUE irip://B.foo.com/... and
>> sucking down data that it should not have access to?
>
>There is no such thing as an internet authentication entity.
>If you don't trust them, take them out of your trusted host file.

Nowhere is this concept of a "trusted host file" described or related to
the DEQUEUE command.  The command clearly indicates what calendar address
the currently authenticated user wants to DEQUEUE from.  I take it from
your reply that you assumed that you have some mechanism (OOB?) to convey
this trust and use it.  Or that the sender would not attempt to access a
calendar address it did not have the rights/trust to access....  (Didnt see
any reply codes that reject you w/insufficient trust or rights either for
that matter).

>> There seems to be no restriction or control over what CALID a sender
>> can DEQUEUE to in the queueing model.  Am I missing something or did
>> noone else notice this?
>
>Only to the authenticated entity. Perhaps its not in the draft.

There is nothing in the current draft to map or connect the currently
authenticated user/CS w/the calendar address specified on the DEQUEUE
command.  Even w/in an organization trust is not a blanket option (How many
people in Microsoft are trusted to see Bill Gates's calendar for the
day???) so saying "If A trusts the user and B trusts A then B will also
trust the user" is not a safe train of logic to follow.  (Just ask Bob or
Paul).

I dont know if Bob or Paul have no concerns w/this but I still do...
Paul??  Bob??

Bruce