Andre
More comments inlined. I'm straying a little from your draft now.
On Tuesday 27 Nov 2001 9:59 pm, you wrote:
Hi Andrew,
Why should the web service protection be singled out over a virus checker
application running on the end users machine?
I think there are differences between locally executed service
applications and network service applications executed on OPES
intermediaries.
The IAB, for example, argued (in draft-iab-opes-01) that OPES services
are not under the direct control of the end hosts, but locally installed
services are. An end user can easily update or patch his local virus
scanner installation, but a subscriber to an OPES virus scanning service
has only two choices - stay subscribed or unsubscribe from the service.
Whilst that is true for the experienced user, its not necessarily true for an
ordinary user. A network service automatically updated against the latest
virus details is far easier for the end user than a system the end user needs
to patch. Its down to the implementation details. The subscriber to an OPES
virus scanning service has as many options available are the service makes
available.
You were saying that the conflict resolution policy could allow a query on
the end user. This same functionality could be used when the conflict is user
requested a download and the virus scanner wants to prevent it. Though as you
correctly say this is harder to do for a network service. Its all down to the
implementation details. If the network service provider gives easy to
interact with virus checking services, then its easy to circumvent, if they
dont, then its hard. This isnt anything to do with IRML is it?
A web site would have to understand all posible services through which it may
run and put in IRML conflict resolution tags for each that work against its
wishes. With n ISPs each giving n services thats going to be a big problem
O(n^2).
Whenever any of these services are upgraded or updated the irml may need to
change. The namespaces of all of the isps services will probably be different
making the identification of the services to block difficult. It sounds like
a nightmare to manage to me.
Things like adverts not being removed are DRM issues that need to be
addressed in the content itself. The viewing policy of a piece of content
needs to be kept with the content itself. For instance a piece of music that
is only playable once needs to keep that policy with it so it knows that its
been played.
Things like circumventing bugs in services are different - This is simillar
to the production of a different page based on browser type, and would add a
simillar level of complexity to website production. The browser version is
contained within the request User-Agent header allowing the web app to
produce suitable content. Perhaps the request should be modified to contain
an indication of what services may be run against the response allowing the
origin site to produce content that is appropriate to the viewing path.
For irml to do end host policy interaction in a manageable fashion, it
would need to know about service resolution, service versioning, and sematic
directories to determine exactly what the services do, whether there are any
conflicts and what to do by way of interaction with the end hosts.
In order to detect the conflict the service needs to have a specified
mechanism for interaction with the content over and above the ability to
change the underlying message data. This probably beyond the scope of IRML
and perhaps part of the opes model. The ability to inject a message state
machine in the middle of an end to end operation may clearly needs a good
deal of thought. The meta data model to define the operation of a dynamically
envoked state machine that controls the passage of messages needs to be
defined. I'm note sure how this scheme will work with the stateless protocols
like http.
It's also harder to detect problems and misconfigurations in network
services. Also, OPES network services can be provided to end hosts a lot
easier than services that have to be installed locally. So if a big ISP
offers all of its customers a free advertisement-removal service, then I
bet many content providers will object to this. But they won't (or maybe
can't) object if a company offers a free advertisement-removal
application that users need to download and install on their local
machine.
An advert removal service would probably attract a legal action since it
would break the legal terms of use of the web site and have a large enough
target to make action worthwhile.
So I think network services have to be treated differently from local
services and one aspect is to detect conflicts between endhosts and at
least notify endhosts of such conflicts. This does not mean that one
endhost should generally be able to prevent another endhost from
executing services, although there may be special cases where this would
be necessary (e.g. in the ad removal scenario described above).
-Andre
Regards
-Andy