Response to LC-2097 on OPES

LC-2097

To the W3C Mobile Web Best Practices Working Group:

The Internet Architecture Board has reviewed the subject document, and 
notes that it has previously reviewed related work done in the IETF in 
the Open Pluggable Edge Services (OPES) Working Group.  In its preview 
and review of OPES work, the IAB expressed its concerns about privacy, 
control, monitoring, and accountability of such services in RFC 3238 [ 
http://tools.ietf.org/html/rfc3238 ].

We have no specific architectural concerns with the "Content 
Transformation Guidelines" document as written; it does seem to take 
into account the questions raised during the OPES discussions.  We would 
like, though, to make that explicit by specifically documenting that you 
reviewed and considered the issues in RFC 3238.


===

PROPOSED RESOLUTION: Ref-2097 resolve yes and add a section under 1.3 
scope noting that OPES RFC 3238 is relevant to this work and has been 
reviewed.

===

Summary of considerations of RFC 3238 http://tools.ietf.org/html/rfc3238


    (2.1) One-party consent: An OPES framework standardized in the IETF
    must require that the use of any OPES service be explicitly
    authorized by one of the application-layer end-hosts (that is, either
    the content provider or the client).

    (2.2) IP-layer communications: For an OPES framework standardized in
    the IETF, the OPES intermediary must be explicitly addressed at the
    IP layer by the end user.

    (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) 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.

    (4.1) URI resolution: OPES documentation must be clear in describing
    these services as being applied to the result of URI resolution, not
    as URI resolution itself.

    (4.2) Reference validity: All proposed services must define their
    impact on inter- and intra-document reference validity.

    (4.3) Any services that cannot be achieved while respecting the above
    two considerations may be reviewed as potential requirements for
    Internet application addressing architecture extensions, but must not
    be undertaken as ad hoc fixes.

    (5.1) Privacy: The overall OPES framework must provide for mechanisms
    for end users to determine the privacy policies of OPES
    intermediaries.

Received on Tuesday, 11 November 2008 19:23:46 UTC