[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IRIP version 4 (Part 2)
Continued from section 3.2 Fanout and Queued Transactions
Under 3.1.9 SWITCH:
There are a few references to the "greeting message" but there is no
clear description of it or its format. Is it like IMAP or POP3 or just a
reply code or some arbitrary text sequence??
Under 3.2 Fanout and Queued Transactions:
>A trusted relationship between two IRIP servers means that one server
>can queue transactions for the other server and deliver them some time
>later. If IRIP server B trusts A, then A can queue requests for B. If A
>does not trust B then B cannot accumulate requests for A.
Why cant there be a queue between non-trusted hosts? This happens for
stuff like SMTP mail so what is wrong w/it here? Affraid for data
integrity? Some other motiviation?
>In IRIP the reply code to the RECIPIENT
>command indicates whether or not a reply will be made in real-time.
>This allows the sender to abort the request if necessary.
Upon further reflection I dont think this is 100% guaranteed. For example,
Server A establishes a link to Server B to do fan out and reflects this in
its RECIPIENT reply code. The sender then begins to send ICALDATA. In the
mean time, Server B goes down (or the link to it is lost, etc). There is
now no way that Server A can return a real-time reply apart from saying
"Sorry but Ive had to queue this up for Server B".
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.
>The firewall in
>front of B.foo.com prevents external connection on the IRIP server
>port. Similarly, the firewall in front of D.bar.com also prevents
>connections on the IRIP server port.
Be sure to clarify that the firewalls are prohibiting INBOUND iRIP
connections, not OUTBOUND. Otherwise you would need to be using some
protocol proxy as well (ala SOCKS).
>A trust
>relationship between the intermediate IRIP server and the endpoint
>servers (B.foo.com and D.bar.com) is desirable but not required.
This conflicts w/your original assertion above that I already challenged...
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 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?
Under 3.4 Reply Codes:
>In addition to those defined in [ITIP], [IRIP] defines the following
>error codes:
[Snip]
>2.0 STATOK Operation was successfully performed.
Actually, isn't 2.0 already defined in iTIP? (Its not new to iRIP.)
>2.0.4 WILL-ATTEMPT The specified Calendar is not here
> but An attempt will be made to deliver
> the request or reply to the Calendar
> anyway. There is a trust relationship
> between this IRIP server and the
> IRIP server for the target calendar.
>2.0.5 TRUSTED-WILL-QUEUE The specified Calendar cannot be
> contacted directly and a trust
> relationship exists between this server
> and the server on which the Calendar
> exists. The request or reply will be
> queued and delivered to the target
> calendar when its IRIP server contacts
> this server and issues the SWITCH
> command.
>2.0.6 WILL-ATTEMPT The specified Calendar is not here
> but an attempt will be made to deliver
> the request or reply to the Calendar
> anyway. The
The meaning of 2.0.4 and 2.0.6 are the same. Looks like some oversight in
the editing process or merging of some comments.
The descriptions for these reply codes explicitly indicates that there is
a trust relationship or not w/the remote host. Does this need to really be
done? If so, then we need to have some 'non-trusted' equivalents!
There appears to be some missing text for the last part of 2.0.6; the
dangling The.
>8.3 DATE TOO LARGE A DATETIME value was too large to be
> represented on this Calendar.
Make this more generic to be more like "Date out of Bounds" to indicate
that a DATETIME value was before the MINDATE of the server or after its
MAXDATE (since these are now required capabilities). ("Too large" implies
> MAXDATE or you are a Un*x programmer). You could then merge it with 8.4
which has a better description.
There is no 10.3 reply code but there is a 10.4 and 10.5. What happened to
is? If its gone, move 10.5 down to be 10.3, otherwise add it back into the
table.
I dont have iCal handy to refer to it but does:
>10.1 REFERRAL Accompanied by an alternate address.
really belong in the 10.x class of reply code? Isnt it more appropo to be
in the "FYI" category rather than a "Severe error" category (ala 10.4 Quota
exceeded)?
Under 5.1 Spoofing:
>The [ITIP] paradigm allows any modifications to data by its Organizer,
>which maps to the [SASL] authorization identity.
I must have missed this discussion on how my SASL authId got mapped to an
iTIP property. Can somone point me to where this is discussed.
>This means that
>authorizing with appropriate identities over [IRIP] will allow read and
>write access to any item in the Receiver's database.
Id say that the "will allow" is really "may allow"; subject to some
policies or other ACL mechanism. If an authId is not the Organizer, they
should not have any access to some other Organziers entries.
>The choice of accepted authentication mechanisms can reduce the
>security risk. The ANONYMOUS mechanism allows a greater level of
>interoperability, in that any Sender can connect anonymously, but
>greatly increases the security risk for the same reason.
It makes sense to expressly preclude _any_ anonymous user (if permitted
into an iRIP server) from doing any modifications to existing entries. I
cannot think of any scenario where Id want to let any anonymous user to be
able to drop stuff onto my calendar but maybe others can. The only action
I can think of that I may actually like to permit would be busytime
lookups... Should tightening the noose around what an anonymous user can
do be part of iRIP? Ill defer to Bob or Paul on the security aspects of
that...
Under 5.3 Connection Flooding
>Servers should be configurable to timeout unused connections.
Since you raised the issue, just when is an iRIP connection considered
"unused" and timed out? Is there such a critter as an idle iRIP connection
that an iRIP server can close down? Is there any way for an iRIP client to
keep a connection alive w/o doing actual commands like RECEIVE and then
ABORT?
Under 6.3 Fanout Requests:
It would be helpful to readers to see a 'failure' case as well. How
about an example of failing for some reason (ie: over quota, etc).
Under 6.3.2 Referral On Fanout:
The text in the draft said that for referrals and some other error cases
no ICALDATA would be handled for the failed RECIPIENT. Given that, why
does the sender S need to ABORT the sequence when it gets the "10.1
irip://E.xyz.com/david99"? It should consider it an automatic failure and
just issue a new RECIPIENT w/the referral address. Or did I miss a reason
for having to ABORT and restart this all?? (This was done in a later
example).
In the example under 6.4.1 the text says:
>This request will
>be delivered the next time the IRIP server on D.bar.com connects to the
>IRIP server on B.foo.com and issues a SWITCH command.
Now Im curious how the iRIP server D.bar.com will know to retrieve
(DEQUEUE) requests for irip://D.bar.com/david unless it polls for all
calendars on B.foo.com or the authID used on the SWITCH is that of
irip://D.bar.com/david. Just how does D handle DEQUEUEing for several
calendars on it from B??
Ive sent editorials OOB but I think we have some stuff to chew on for now.
Bruce