rfc3238.txt

RFC 的详细文档！

   language translation, why is that of any concern to the content
   provider one way or another?  One answer is that one of the proper
   concerns of the IETF is to design architectures that enable end-hosts
   to detect and respond to inappropriate actions in the network.  This
   seems of particular importance for powerful devices in the network
   such as OPES intermediaries, which are authorized by one of the end-
   nodes to act on or transform data in the network, but other than that
   are not under the direct control of that end-node.

   Consider as an example the services of virus scanning or language
   translation.  The end user has reasonable power in detecting and
   dealing with imperfect or corrupted virus scanners or language
   translators that are under her direct control (e.g., on her own
   machine).  The end user knows exactly what program is installed, and
   has direct access to the content before and after the service is



IAB                          Informational                      [Page 6]

RFC 3238              IAB Considerations for OPES           January 2002


   applied.  The end user would have less control over similar services
   offered by OPES in the network itself, where the end user's only
   control might be the binary one of authorizing or not authorizing the
   service.  (We also note that services deployed on the end host in a
   self-contained fashion, such as a local virus scanning program, are
   not a service in the network, and therefore are not in the province
   of the IETF one way or another.)

   For a OPES service such as virus scanning or language translation,
   the end user could detect a corrupted intermediary, but only through
   a "black-box" approach of comparing the input with the output.  This
   is also imprecise and requires some effort, compared to the effort
   required to detect a corrupted virus scanner installed on one's own
   machine.  For example, the user could retrieve the "non-OPES" version
   of the content directly from the content provider, if there is a
   "non-OPES" version, and compare this with the "OPES" version of the
   content available from the OPES intermediary.  However, in the case
   of dynamic content, the "non-OPES" version of the content retrieved
   by the user directly from the content provider might not necessarily
   be the same as the "non-OPES" version of the content considered by
   the OPES intermediary.  This limited control by the end user of the
   OPES service, and the limited ability of the end user to detect
   imperfect or corrupted intermediaries, argues for an architecture
   that helps the content provider to detect and respond to imperfect or
   corrupted OPES intermediaries as well.

   We consider the specific example of virus scanning, authorized by the
   end user as an OPES service.  One could imagine virus scanning as a
   widely deployed OPES service, augmenting the virus scanning done on
   the end host itself.  If I ask for, say, a paper by Steve Bellovin on
   security and viruses in the network, and am informed by my authorized
   OPES virus-scanning service that this content does not pass the
   virus-scan, there are a number of possibilities:

   (1) Unknown to Steve, the content (that is, Steve's paper) contains a
       harmful virus.

   (2) Steve inserted a harmful virus in the content on purpose, with
       playful or malicious intent.

   (3) The OPES virus scanner can't distinguish between a true harmful
       virus, and Steve's paper about harmful viruses.

   (4) My local OPES virus scanner has been hacked, with malicious
       intent, to reject all content from Steve Bellovin.






IAB                          Informational                      [Page 7]

RFC 3238              IAB Considerations for OPES           January 2002


   At some point, for some content, some widely-deployed implementation
   of some OPES virus scanner is likely to result in problem (3), and
   some OPES implementation is likely to be corrupted to result in
   problem (4).  Because the end user has limited control over the OPES
   virus scanner, the end user also is limited in its ability to detect
   problems (3) or (4) in the OPES virus scanner.  In addition, the
   content provider is probably the one with the strongest incentive to
   detect problems (3) or (4) in the OPES virus scanner.  (The content
   provider generally has a strong incentive to detect problem (1) as
   well.)  In this case, it seems prudent that the overall OPES
   architecture should be carefully designed to prevent the OPES service
   of virus scanning, as authorized by the client, from unnecessarily
   preventing the distribution of content that in fact does not have
   viruses.

   Obviously, it is not viable to propose that content providers simply
   indicate that some content should be passed to the end user without
   virus scanning - the point of virus scanning is for the end user to
   exercise control in this regard.  However, if some form of end-system
   notification allows the content provider to find out that the content
   is being rejected by a virus scanning service instead of being
   delivered to the end user, then the content provider (Steve, in this
   case) might want to inform end users that this content is known by
   the content provider not to pass some OPES virus scanning services.
   End users could then make their own decisions about whether or not to
   retrieve that content bypassing the OPES virus scanning service,
   relying on their own virus scanner or an alternate virus scanning
   service for this particular content.  Such end-system notification to
   the content provider, if requested, cannot be enforced, and cannot be
   relied upon from corrupted intermediaries, but it seems important
   nevertheless.

   Of course, malicious users can also use their awareness of the virus
   scanning service to perfect their ability to construct malicious
   viruses that can evade the virus scanning service.  This will be done
   anyway, with any virus scanning service, and seems like an acceptable
   cost to allow content providers some protection against the vagaries
   of imperfect or corrupted OPES services in the network.

   Thus, for client-requested services such as virus scanning and
   language translation, it is clearly desirable for the origin server
   to have notification, if it requests it, that these services are
   being performed on its content before the content is sent to the
   client.  Any such end-system notification might be accompanied by
   reduced performance (in terms of overhead, delays, etc.) for the OPES
   service applied to that content.  But some form of end-system





IAB                          Informational                      [Page 8]

RFC 3238              IAB Considerations for OPES           January 2002


   notification is clearly necessary if content providers are to be able
   to detect and respond to actions by OPES intermediaries that are
   deemed inappropriate by the content provider.

   Similarly for a client-based OPES service of language translation, it
   is clearly desirable for content providers to be able to inform end
   users when some content is deemed by the content provider to be
   incompatible with language translation.  In this case, the important
   issue is not to prevent the OPES language translation from being
   performed on the content, but instead to give the content provider
   some mechanism to discover the language translation, and to inform
   the end user (or more precisely, to inform the end user's host
   computer) if the content provider believes that this language
   translation is incompatible with this particular content.

   IAB Considerations:

   (3.1) Notification: The overall OPES framework needs to assist
   content providers in detecting and responding to client-centric
   actions by OPES intermediaries that are deemed inappropriate by the
   content provider.

3.2.  Data integrity with server-centric OPES services

   What are the concerns, if any, with the end-to-end integrity of data
   in a server-centric OPES service such as location-based services?
   For example, CNN could authorize a location-based OPES service, where
   the OPES intermediary inserts the weather report or news headline of
   regional interest into the requested web page.  The same issue of the
   detection and response to broken or modified OPES intermediaries
   occurs with server-centric OPES as with client-centric OPES services.
   We only consider server-centric services on responses, as we are not
   aware of any proposals for server-centric OPES services on requests
   from the client to the content provider.

   How are the end-nodes to detect inappropriate actions from OPES
   services authorized by the content provider?  The OPES service is
   being performed at an OPES intermediary in the network itself, and
   not under the direct control of the content provider; in particular,
   the content provider might not have the ability to monitor directly
   the output of the OPES intermediary.  One could argue that the
   content provider and server-centric OPES intermediary are part of a
   single distributed application, and can be responsible on their own
   for detecting and dealing with broken or modified OPES
   intermediaries, without involving the end user.  But this is
   unconvincing, basically arguing that standardizing protocols for
   performing OPES services is a network issue properly in the domain of
   the IETF, but the ensuring the overall integrity of the service is a



IAB                          Informational                      [Page 9]

RFC 3238              IAB Considerations for OPES           January 2002


   distributed application matter, and not in the province of the IETF
   at all.  It would seem to us that you can't have it both ways.
   Simply labeling the content provider and the OPES intermediary as
   part of the same distributed application does not give the content
   provider the ability to monitor the actions of the OPES intermediary.

   However, if the end user receives some form of notification that
   these OPES services have been provided, and has some mechanism for
   receiving the "non-OPES" content from the content provider without
   the OPES intermediary's modifications (if there is such a thing as a
   non-OPES version of the content), then the end user is in a better
   position to detect and react to inappropriate actions from
   compromised or poorly-designed OPES intermediaries.  Thus, it is
   clear that some form of end-system notification is required to allow
   the end user to detect and respond to broken or modified OPES
   intermediaries.  If the end user has notification of action by OPES
   intermediaries, it could "veto" an OPES service simply by throwing
   the OPES-modified content away.  And if the client wants to talk
   directly to the origin server to receive the "non-OPES" version, and
   the origin server is configured to allow this, then the OPES
   intermediary must be designed to permit this end-to-end
   communication.

   In addition to concerns about detecting and responding to faulty or
   compromised OPES intermediaries, there are purely policy-based
   concerns about the integrity of data.  If the content provider looks
   at the source IP address from the HTTP request, or tosses a coin, in
   order to decide what content to provide, then that is the content
   provider's business.  But if there exists a "non-OPES" version of
   some content available from the content provider, and also modified
   versions available from OPES intermediaries, then it is important
   that end users would be able to discover that they are receiving a
   modified version from the network, and not the "non-OPES" version
   that is also available from the content provider directly.

   IAB Considerations:

   (3.2) Notification: The overall OPES framework should assist end
   users in detecting the behavior of OPES intermediaries, potentially
   allowing them to identify imperfect or compromised intermediaries.

   (3.3) Non-blocking: If there exists a "non-OPES" version of content
   available from the content provider, the OPES architecture must not
   prevent users from retrieving this "non-OPES" version from the
   content provider.






IAB                          Informational                     [Page 10]

RFC 3238              IAB Considerations for OPES           January 2002


3.3.  Data integrity with client-centric OPES services on requests

   There have also been proposals for OPES services authorized by the
   client on requests from the client to the content provider.  Examples
   include services that remove fields from the HTTP header for added
   privacy, and content-filtering services that filter requests based on
   the requested URL.  For such services, there is still a need for end
   hosts to be assisted in detecting and responding to imperfect or
   corrupted intermediaries, but it seems less clear to what extent this
   applies to the content provider, and to what extent it applies to the
   end user that authorized the service.  The requirements will probably
   have to be determined by the OPES and wider IETF communities on a
   case-by-case basis for each specific service.

4.  Application Layer Addresses

   Most application layer addressing revolves around URIs, which, for
   the most part, give a structured method to refer to a single data
   entity on a remote server.  URIs are universal in that, in principle,
   the same result is obtained irrespective of the location of the
   client performing the resolution.

   Practice often differs from this theory -- ad-strippers remove data
   from pages at the client end; web server farms redirect clients to
   one of several potential target machines for load-balancing or to
   give the user "localized" content.

   However, from an architectural standpoint, it is important to be
   clear about what is being done here.  In all cases, URI resolution
   standards (as defined for individual URI schemes, such as HTTP) apply
   unchanged between the client and the OPES intermediary.  What the
   intermediary does to fulfill the request is not material to the
   discussion, and must produce a result that is compliant with the
   applicable URI scheme definition.  In this sense, the OPES
   intermediary is the "endpoint" of URI resolution.

   In client-centric OPES, the intermediary is resolving the URI on
   behalf of the client, and then applying client-requested services to
   provide a data response to the client.  The client gets the data it
   wanted, but it did not carry out the URI resolution.

   In server-centric OPES, the "origin server" cedes its authority to
   the intermediary to determine what is the "appropriate" content to
   supply for a given URI.   The client may well perform standard URI
   resolution, but that reaches no further than the intermediary.

   With those distinctions firmly in mind, there are two particular
   areas of concern for OPES-like services.



IAB                          Informational                     [Page 11]

RFC 3238              IAB Considerations for OPES           January 2002


   The first is the consideration of the effect of a series of
   interactions, over time and location (i.e., not just one document
   retrieval).   Potential problems include inconsistencies in intra-
   and inter-document references -- depending on what content is
   changed, references from one version of a document might not exist in
   a modified target, etc.

   The other concern is whether this leads to the creation of content
   that is exclusively accessible through the use of an intermediary.
   That is, there is no "non-OPES" version.  Either this should not be
   allowed, or this would argue for an extension to the Internet
   application layer addressing architecture.

   IAB Considerations:

   (4.1) URI resolution: OPES documentation must be clear in describing