Re: general questions

Hi Stan,



In my research work I'm interested in the content adaptation and negotiation
in heterogeneous

environments, i.e. in environments that include a wide diversity of clients
that can request content

servers.



I try here to resume an answer to your mail in the following four points:



1- Profile definitions:

In heterogeneous environments, clients are very different in terms of
capabilities and preferences,

etc. An efficient adaptive server must take into account all these clients
and make the best effort

 to provide the appropriate reply. User agents must describe their
characteristics in a good way

 using the chosen vocabulary (note that even the set of HTTP accept headers
is considered as a

 vocabulary but unfortunately incomplete). A vocabulary must not be
restricted to one kind of

 devices (such as to only WAP phones) but must cover a large set of clients.
In this context

 I invite you to take a look on the UPS schema and the profile examples

(http://opera.inrialpes.fr/people/Tayeb.Lemlouma/NegotiationSchema/index.htm
). UPS is not

 restricted to a particular kind of users, for example the "neg:DeviceName"
elements can contain

 the name of any device. Another important point which arises at the server
side is the matching

 of the profiles: i.e. how can the server resolve the constraints included
in the client profile and in

 the available original content. The server matching can use the client
request (HTTP header

 for instance) and/or the client retrieved profile (e.g. a received CC/PP
profile).



2- RDF use in CC/PP

RDF is an important concept for the semantic web. Profiles can easily be
readable, using RDF

 makes profiles UNDERSTANDABLE which is very important at the server side.
RDF is a

 generic format and information written in the RDF form is easy to process.
RDF semantic is

 powerful; the serialization of RDF is another task. For example, Notation3

(http://www.w3.org/DesignIssues/Notation3.html) is another serialization of
RDF based on a

 plain text respresentation.



3- Proxy implementation and limitation

>>Most documents talk about a proxy server analyzing the request ..

The reason of this is simple. Today, most of current players (IE, Netscape,
etc.) don't send

 the client profile when a user requests a Web content. Furthermore, many
content servers

 are not able to receive, process and match profiles in order to send an
adapted reply to the

 client. In an other side many users still use browsers that send "poor"
HTTP headers,

 consequently server side components that deliver content based on the
information included

 in HTTP requests can't work efficiently.



In NAC (http://opera.inrialpes.fr/people/Tayeb.Lemlouma/NAC.htm), we have
implemented

 a prototype of an architecture that tries to deliver adapted content
according to user agents'

 characteristics. The server side component, responsible to achieving that
goal, is called ANM

 (adaptation and negotiation module). To use the proposed solution two use
cases are possible:

A) Include the ANM module an original server and request ONLY this server.

B) Use the entire Web through NAC to see how we can process in the more
general situation.

 In this situation we haven't the choice to avoid the use of an intermediate
proxy. Clients point

 so their connection to the proxy that receives the user profiles and match
them with the server

 reply. Here in fact we have the problem that the proxy can't achieve a good
content adaptation

 because it doesn't know all the original server's content and capabilities.
For example, the proxy

 can't apply an efficient selection of original content variants.



4- Exchange protocol

According to our prototype implementation experience, an exchange protocol
between the

 'client/server' or 'client/proxy' or 'proxy/original server' is needed. The
protocol must define

 a way of how profiles are exchanged (sending profiles by clients,
retrieving profiles from an other

 entity, etc.) and server replies are sent to the end user. In NAC, we have
used a module at the

 client side (iPAQ 3600) that sends the client profile in a predefined way.
The server caches the

 profile and retrieves the client profile changes only when necessary (which
is similar in a way to

 the 304 HTTP reply, RFC 2616). Defining an exchange protocol requires a big
effort and a large

 consensus. Some ideas about a protocol framework can be found in RFC 2703.





Regards



Tayeb*

----------
Tayeb Lemlouma
http://www.inrialpes.fr/opera/people/Tayeb.Lemlouma/index.html
Opera project
National Research Institute in Computer Science and Control (INRIA
Rhône-Alpes, France )
Office B213, phone (+33) 04 76 61 52 81, Fax (+33) 04 76 61 52 07.

Received on Tuesday, 21 May 2002 07:10:07 UTC