ietf-openproxy
[Top] [All Lists]

Re: draft-beck-opes-irml-02.txt

2001-11-26 13:33:12

Andrew,

Section 3.7.2
i.      Should a web site be able to reject services that an end user wants
actioned? For instance if a rogue website wanted to download a virus laden
executable should they be able to explicitly prevent the download from
passing through a virus scanner? This is against the wishes of the end user.

Right, but what if a content owner offers a harmless file which a
specific virus scanner rejects for some reason? IRML can help in
detecting such problems. This does not necessarily mean that one
endpoint can prevent the service execution requests of the other
endpoint. The resolution of such conflicts would depend on the specific
application and also the local policy of the OPES intermediary. In the
virus scanning example, for instance, the ISP could notify the end user
that that the content owner wishes to prevent the execution of the virus
scanner on his content for some reason and then the end user could
decide whether or not to accept the content or not.


ii.     Can IRML from the origin server and the end user interact?
The assumption that you can combine the preferences of the origin server and
the preferences of the end user is wrong. The likely application of web
services for a web site is in the CDN, and for the end user the ISP. The
interaction of the two IRML documents cannot happen, the IRML is based in two
different trust domains. The only way for such preferences from the origin
web site to pass into to the end user trusted domain would be in the message
itself. All actions explicitly requested by an end point MUST be acted on.

I agree that if an OPES intermediary receives IRML rule modules from one
of the endpoints of a content transaction only, then there will be no
conflicts and thus all requested actions must generally be acted on.
However, in other cases, e.g. if an ISP also operates a CDN, OPES
intermediaries would receive IRML rules from both endpoints and would
have to deal with and resolve conflicts between the two endpoints - see
above.

iii.    Service uri's. Should they include the host identifier, or should they
simply be a service name that can map either to a local proxylet or a callout
service as appropriate? I was thinking that some sort of service discovery
system/protocol would be appropriate.

The predominant opinion on the OPES list used to be that service
discovery is out of scope for IRML. In particular, it was considered bad
to statically link an IRML rule to a specific service instance because
this would prevent OPES intermediaries from dynamically choosing an
appropriate service instance at run-time.

Section 6
iv.     Explicitly forcing the use of signed IRML may be wrong. Clearly I can 
see
the benefits for doing it, particularly if IRML is stored on public servers
and delivered over the public internet. But when you are providing services
for the end user as an enterprise or an ISP, the authentication of the end
user will be carried out in a different manner. Its likely that the ISP would
store the IRML on behalf of the end user so there will be no need for the ISP
to further authenticate the user document. The IRML documents are likely to
be assigned in groups, so the ISP may sign the IRML and the end user agrees
to be put into the group. Would the ISP need to reauthenticate its own
documents?

I agree that it may not make so much sense to mandate the authentication
of IRML rule modules authored by delegates who are in the same domain as
the OPES intermediaries that will process the rule modules. However,
whenever rule modules have to be transferred to a different domain (and
this may even be the case for rule modules authored by delegates), there
will be a need for authentication. We should probably rephrase the
corresponding passage in the draft to clarify this a little bit.

-Andre