The CC/PP Implementor Workshop, 2000
- Date: 15-16, November, 2000
- Host: Host: Mikael Nilsson, Ericsson
- Venue: Ericsson Wireless Internet, Karlstad, Sweden
- Chair: Johan Hjelm, Ericsson
- Secretary: Nigel Byrnes, InterX
Attendees
- Hidetaka Ohto, W3C/Panasonic
- Graham Klyne, Content Technologies
- Mikael Nilsson, Ericsson
- Toni Penttinen, Ericsson
- Kazuhiro Kitagawa, W3C
- Mike McMahon, InterX
- Nigel Byrnes, InterX
- Mika Korpela, Ericsson
- Mike Lamb, InterX
- Chris Woodrow, Information Architects
- Howard Greco, Information Architects
- Thomas Majak, Speedy Tomato
- Kinuko Yasuda, Keio University
- Johan Hjelm, Ericsson
Agenda
- 15 November, 2000
- Feedback from the CCPP WG meeting
- Conformance (which turned into a discussion on CCPP over
HTTP)
- Demonstration of existing Implementations
- RDF Discussion
- Lunch
- Demonstration of existing implementations
- Security and Trust
- 16 November, 2001
- Conformance in WAP
- Content Adaption Strategies
- CCPP: The Future
- Finish
Actions Arising
- Considering HTTP GET message augmented with CCPP data in the
form of a request entity, ask the IEFT how proxies should handle
such messages.
- Clarify the role of TLS as a security mechanism
- Produce a set of guidelines detailing how to deal with security
threats
Minutes of the CCPP Implementers Workshop, 15 Novemeber, 2000
START 9am
Feedback from CCPP WG Meeting
JH reported
- The meeting held over the previous two days in the same
venue.
- A delay in completion of the WG due to "pioneering"
work
- Plans for specifications: merge the current working drafts as
follows:
- "Structure and Vocabulary" will contain the content
of the structure and vocab WDs
- "Requirements and Usecases" will contain
Requirements and Architecture, Terminology and Abbreviations and
Trust
- "Implementors Notes" to be written
- The rest of the lifetime of the WG:
- Revised WDs delivered 22/12/2000
- Review until 12/1/2001
- Public Working Drafts 26/1/2001
- Last Call 23/2/01
- Proposed Recommendation 9/3/2001. Due to existing
Implementers experience, it is believed that the Candidate
Recommendation stage of the specifications can be bypassed.
- GK: The issue of conformance boils down to how the application
server interprets/consumes the profile.
- JH: CCPP is not a complete application. It is useful in the
context of web resource access and requires a request-response
protocol, like HTTP.
- TP: CCPP and P3P are likely to be used in combination.
- which WG would own any "integration" work, CCPP or
P3P?
- CCPP is intended to be protocol independent, but P3P is bound
to HTTP
- JH noted that there had been "pushback" from a recent
IETF meeting in Pittsburgh over implementing CCPP over the HTTP
Extension Framework due to the introduction of an unregistered,
non-standard header. In response, JH has written a document titled
"Content Negotiation Header in HTTP Scenarios" which was
be published as an IETF Internet Draft on 31/10/2000. If there is no
further pushback, then this may become a standard way to transport
CCPP data over HTTP.
[Note: What followed next was a discussion of how to transport CCPP
over existing web infrastructure]
- The slow rate at which existing web infrastructure
(i.e. proxies/servers/browsers) are being updated is stifling the
introduction of new technology like CCPP. Considering the transport
of CCPP over HTTP, what happens if server doesn't support a
CCPP-header?
- GK: it could strip it out. This would be benign.
- GK suggested a deployment strategy to avoid/prevent headers from
being stripped out by headers by overloading the known and well used
HTTP UAgent header.
- e.g. UA-type CCPP=URI;URI...
- HT noted that this would only work for only static profiles,
i.e. no provision for PROFILE-DIFFs
- GK also suggested that the HTTP GET request message could be
augmented with a request entity containing CCPP data.
COFFEE BREAK
RESTART 10:40am
Presentation of Existing CCPP Implementation
- Slides are to sent to JH
- While the content of the slides is not summarised here
Ericsson Wap Application Server, presented by Sten Ulrich Eriksson,
Ericsson
While the server implements much of WAP 1.2.1, no (optional)
UAPROF functionality is currently available. We have to wait for the
next release, version 3.
The only CCPP-like functionality it currently offers is the
selection of a (device-class generic?) template, e.g. if client is a
desktop PC, then select the PC template
SBC-TRIC implementation, by Lalitha Suryanarayana, presented by
Chris Woodrow
first working CCPP implementation
Information Architects Implementation, presented by Chris
Woodrow
any comments/remarks?
11:30 am RDF Discussion, lead by GK
- "[RDF is] a webised knowledge representation format"
Tim Berners-Lee
- RDF can be represented by a directed label graph that consists
of nodes, arcs and leafs. Nodes are resources, arcs are properties
and leafs are property values
- RDF is extensible/unconstrained
- RDF is open-ended, i.e. "anyone can say anything about
anyone".
- RDF maps easily onto Database access concepts. The following
reference was recommended: Data on the Web: from Relations to
Semistructured Data and XML, Serge Abiteboul, 1999 (ISBN
155860622X).
- As a basis for commonality, RDF enables the representation
of:
- CCPP profiles
- document profiles
- personal preferences
- CCPP profiles are hierarchical and lend themselves to be
serialised and modeled in XML.
- RDF for Ontological Description
- RDF provides the low-level tools for building ontological
structures, i.e. data-types for the real-world
- treats documents as documents
Noon Break for Lunch
- Based on early CCPP Note and CCPP Exchange Protocol work
- Their PandA CCPP implementation enabled statistical analysis of
performance. Main agents are:
- Wireless mobile client
- Proxy/Gateway between wireless and wireline networks
- CCPP repository
- Server
- The relationship between network Round Trip Time (RTT) and
profile size over different bearers (between the wireless client and
the proxy/gateway) was considered.
- For a wireless LAN bearer, Inline profile representation is
best for profiles less than 15Kb in size. Note that a typical WAP
UAPROF profile size is around 10Kb. Indirect over a broadband
connection is slower than Inline because of all the extra work the
server has to do resolving the external references.
- For a narrowband connection, Indirect is best in almost all
cases because less information has to be transmitted over the slow
link.
- Caching has a positive affect where RTT between proxy and CCPP repository is large/variable
- For Indirect profiles with many PROFILE-DIFF headers, it
maybe quicker for these to be merged into an Inline profile, if
possible
- Reference to this work in an forthcoming article?
Content conversion
- investigated relative merit of converting images to speed up
download
- CCPP "merit"/benefit was the tradeoff between
increased request size v. decreased response size plus image
conversion time.
- conversion was found to be of benefit for only narrowband
devices where the converted image size is sufficiently small to
outweigh the cost (time) of conversion
- terminal capabilities and network bandwidth are important
factors in deciding optimal CCPP settings
General Browser Architecture, Toni Penttinen, Ericsson
- A java implementation of a WAP UAPROF v1.2 handler.
- Recognised profile data:
- User preferences
- service profile, i.e. application history
- network profile
- User Agent profile
- Supports the use of multiple browser instances
- browsers respond to profile changes
- e.g. editing the "screen size" property values
results in a corresponding change in browser window size
- Source will be available from Ericsson developer/partner site
January next year.
3.00pm Security and Trust, Graham Klyne
[NB: Discussion produced extra points that were not in the
slides. These points are captured below]
- From a trust/security perspective, the goal of CCPP is not to
introduce any additional weaknesses.
- Security was defined as: protection against threats of
disclosure of private information and information used to control
behaviour
- Considering a server which is interpreting a profile with
extra capabilities added by a proxy, "Can I believe
this?"
- Privacy: what is the intended use of this disclosed
information
- Trust: who will this information be disclosed to? Can they be
trusted?
- Enforcement of trust is out of scope.
- Threats:
- not the same in every circumstance
- Approach taken to identify possible weaknesses:
- 1. Figure out what are we trying to do?
- 2. Identify how this can be attacked.
- Disclosure of vulnerabilities, e.g. which WMLScript libraries are supported
- denial of service against proxies--a favourite point of attack
- privacy: aggregation of CCPP and P3P
- piggy backing of requests when the client has an open session
with a server
- Threat contexts:
- provision of document profile by server if a proxy performs adaption
- proxies that modify device profiles
- Trust model
- basis for constructing a trust model is to enable the transfer of trust across trust boundaries
- How to model multiple proxies?
- group them together into a proxychain/superproxy
- trust is a function of trust across the superproxy
- trust-level for the proxy chain is only as good as the lowest level of trust between any two proxies in the chain, i.e. the trust of the proxy chain is only as good as it's weakest link
- proxies significantly complicate things
- Trust mechanisms, technology that can be used to enforce
trust
- ACTION: TLS: Need to clarify it's role
- selected security modes may evolve and may affect chosen
mechanism for deployment with CCPP
- HT: What level of trust is required by end-users?
- JH: Enough such that it doesn't cost them any money!
- Use SSL or investigate CCPP and P3P aggregation
- Trust is not binary
- JH: Does CCPP introduce any significant new threats? e.g. through profile aggregation.
- Such threats already exist through DoubleClick, for
example. CCPP just makes this threat worse.
- Profile Encryption
- Encode all or part of the profile?
- encryption of profile elements might be worthwhile if
intermediaries are deemed threats. Only trusted third parties can
decode encrypted profile data, e.g. Police or Post Office.
- Consider the "BlindMan" use case: if you always
choose to download 'sound' in preference to 'images', then it could
be inferred that you are blind. This information could be supplied
maliciously to a prospective employer, possibly harming your chances
of landing the job.
- Conclusions: extra point: assess risks.
- ACTION: Produce a set of guidelines detailing how to deal with security threats
- Comments from implementers on security:
- User should have control to take away part of the profile
- The user could choose to ignore security risks, i.e. bury his head in the sand
- Draw up contractual arrangements between parties,
e.g. Network Operators and Proxies, who declare not to misuse data.
- Anonymisers are not 100% secure and could also be attacked as a point of intrusion
- - Trust creation is possible by assuming certain elements of
trust that enable the expression of trust.
Minutes of the CCPP Implementers Workshop, 16 Novemeber, 2000
Action Arising:
1. Propose Device Independent Authoring WG at the next Advisory Committee meeting in Boston.
9:10 am Conformance in WAP, Mikael Nilsson,
Ericsson
- Conformance is a foundation that offers a degree of confidence
in a product
- WAP conformance is based around testing the client side
implementation of the WAP stack
- UI layer is not covered
- gateway functionality is also out of scope. Maybe defined in
WAP 2001
- JH: An interesting feature of WAP conformance testing is that it
will test for HTTP v1.1 conformance as well.
- e.g. tests for all HTTP v1.1 headers
- This will be of benefit for all the web at large
- WAP-NG
- While for the current release implementation of UAPROF is
optional, in WAP 2001 some WGs are assuming it to be present.
- WAP 2001 certification will mean devices will use CCPP
- JH encourages interoperability testing of existing CCPP
implementations, particularly those demonstrated at the CCPP
Implementers Meeting
Content Adaption Strategies, Johan Hjelm,
Ericsson
- Thoughts about the future:
- Context adaption is wider than device customisation
- Profile attributes used in context adaption range from:
- "Unique to me", e.g. credit card number
- "Shared with others", e.g. screen size
- These profile attributes can be grouped as follows:
- Personal and environmental
- Context dependent
- At a most simple level, content adaption can be achieved by
changing stylesheets.
- This can be a problem when Inline stylesheets are used,
e.g. by MS FrontPage.
- such content adaption merely changes content format within
the same modality
- Changing modality impacts upon content.
- For small devices, content filtering maybe required.
- or maybe a reauthored content set? For example, how to
ensure a voice browser speaks the WAP acronym as "WAP",
i.e. a single syllable, as opposed to "W" "A"
"P"...
- Considering CCPP as a source of filtering information, the
author will need to retain control.
- as a counter-example, today the user is in control of presentation through browser controls
- this alters the author's intended presentation of the content
- Intended presentations of content could be specified through document profiles
- For times when the user is altering the presentation of
content, CCPP and P3P could be used together to confirm if the user
really wants to exercise this choice. If so, then the author could
deny the user service
- Content Filtering
- currently the server is given no hints on how adapt content
based upon profile data,
- e.g. While the server may be detect that it's client is a
small mobile device, how does it determine that content authored for
a desktop PC is not suitable?
- truly device dependent content may be a misnomer. Content
maybe authored for specific target device classes.
- Candidate General Heuristics to Content Filtering
- Vocabularies for document description
- Dublin Core provides an established document metadata vocabulary
- It has been developed for use in library/cataloguing applications
- For it to be relevant to CCPP and content management
purposes, it's syntax will need to be made more precise.
- The example of how a dublin core attribute was ambiguous in the context of CCPP.
- Any chosen vocabulary must be compatible with the CCPP
vocabulary
COFFEE BREAK
11:00 am CCPP: The Future
- WG Charter expires in March 2001. Johan asked:
- What work do we see that needs to be done in the future?
- Where (i.e. within which WG) would it be done?
- Mike McMahon expressed an interest in document profiling to
enable server-side support of different devices
- Following a recent Device Independent Authoring (DIA)
workshop, the idea of a DIA WG was first proposed. http://www.w3.org/2000/10/DIAWorkshop/
- This would investigate commonality between W3C and non-W3C
specifications like HTML, iTV, WAP, etc
- Nigel Byrnes asked whether specifying server-side behaviour
is in keeping with the W3C philosophy of specifying datastructures
and giving 3rd party implementers free reign in how they choose to
implement them.
- Johan replied that W3C is dynamic, not static. Previously it
didn't specify protocols, but now it is active in this area with the
XML Protocol WG. To promote clarity in the market place and promote
uptake, maybe the specification of server-side behaviour is
necessary for CCPP.
- ACTION: Propose DIA WG at the next Advisory Committee
meeting in Boston in 2 weeks.
- CCPP vocabulary: a common way of describing features
- Creation of a vocabulary for describing core CCPP attributes
would be beneficial for interoperability of semantics
- The CCPP WG has attempted to define a core vocabulary but they found it hard.
- Maybe canonical domain-specific vocabularies will emerge as has already happened for WAP.
- There are the issues of:
1. vocabulary maintenance over time. For the WAP UAPROF WG,
as they already maintain and review one vocabulary, it shouldn't be
too much more effort to do it for a second (or third?).
2. central vocabulary repository. Holder would be responsible
for review, maintenance and education to ensure the vocabularies are
used. Beyond the scope of the W3C
11:30 FINISH