Re: Forward: [Moderator Action] RE: Any CC/PP App servers in the market

Well, I may have sounded a bit too defaitist there. Of course we will finish the
spec. Although it takes a little longer than expected.

Johan

Kazuhiro Kitagawa wrote:

> Subject: [Moderator Action] RE: Any CC/PP App servers in the market
> Date: Mon, 3 Sep 2001 15:08:28 -0400 (EDT)
> From: "C. Enrique Ortiz" <eortiz@agea.com>
> To: "Johan Hjelm" <johan.hjelm@era-t.ericsson.se>,
>      "Butler, Mark" <Mark_Butler@hplb.hpl.hp.com>
> CC: "'cafe babe'" <cafe_babe@hotmail.com>, <www-mobile@w3.org>
>
> > Our problem is time - the working group is rapidly diminishing in number
> and committment with the
> > finishing-up of the spec being simultaneous with a downturn in the
> industry.
>
> hum, too bad.  i think (the idea of) cc/pp is right on.  i am in the middle
> of determining if i should extend our product to support cc/pp natively both
> for device and user profiles maybe for content negotiation.  still not sure
> if i would implement the whole cc/pp spec though.
>
> ceo
>
> > -----Original Message-----
> > From: www-mobile-request@w3.org [mailto:www-mobile-request@w3.org]On
> > Behalf Of Johan Hjelm
> > Sent: Wednesday, August 15, 2001 9:23 PM
> > To: Butler, Mark
> > Cc: 'cafe babe'; www-mobile@w3.org
> > Subject: Re: Any CC/PP App servers in the market
> >
> >
> > Thanks Mark for those good comments. Our problem is time - the
> > working group is
> > rapidly diminishing in number and committment with the
> > finishing-up of the spec
> > being simultaneous with a downturn in the industry.
> >
> > We are trying to wrap up the spec to go to candidate
> > recommendation now, and
> > then we will recharter the group to restart the work (I know, I
> > have been saying
> > that for a while now). One reason is for that is to do the protocol work
> > properly - the numerical namespaces in the HTTP header comes from the HTTP
> > Extension Framework, and that was actually more or less a
> > political decsion. It
> > would have been much cleaner to do a new HTTP header, but we were
> > not allowed to
> > do so at the time. So modifications of the servlets is as well to
> > put off until
> > then.
> >
> > We have not been tracking resources on our web pages for the
> > simple reason that
> > there has only been a couple, but now there are at least four
> > publicly available
> > ones, so that is something we should do.
> >
> > One more comment, about device classes: It works fine as long as
> > you can assume
> > that devices do not diverge from a class. But as soon as they do,
> > you have a
> > problem. I would expect heuristics to be written to determine
> > that there is an
> > 80% fit, and that is fine (but someone has to determine WHICH
> > 80%, and declare
> > it!). To be sure, if your device conforms to a class (who determines
> > conformance?), you can always send an override for the little
> > extras that you
> > have built in. But there has to be a full description of the
> > class somewhere.
> >
> > Vladimir, would you mind sharing your device classes and
> > definitions with us? I
> > am sure it would be useful.
> >
> > Johan
> >
> > "Butler, Mark" wrote:
> >
> > > As far as I know there are no CC/PP enabled app servers on the market -
> > > current servers use the User-Agent string and then often use their own
> > > device capability database. For an example of this, see the
> > device.xml file
> > > in the Morphis open source device transcoder
> > (http://www.morphis.org/) or
> > > the BrowserImpl.xml file in the Cocoon 2 framework
> > > (http://xml.apache.org/cocoon).
> > >
> > > Furthermore as far as I am aware, no-one seems to have
> > considered whether
> > > the proposed CC/PP (http://www.w3.org/TR/NOTE-CCPPexchange) and UAProf
> > >
> > (http://www1.wapforum.org/tech/terms.asp?doc=WAP-248-UAProf-200105
> > 30-p.pdf)
> > > protocols will be compatible with the current HTTP servlet API. I'm
> > > currently trying to determine whether current app servers can use the
> > > proposed CC/PP and UAProf protocols or whether this will
> > necessitate changes
> > > to the base servlet API. Personally I think it would be better to use a
> > > protocol that is compatible with the javax.servlet.http API,
> > and derive a
> > > new API(s) from that specifically for CC/PP and UAProf.
> > >
> > > Specifically current servers such as Tomcat will respond to some CC/PP
> > > requests. There are two problems: Firstly the HTTPex numerical namespace
> > > seems to add unnecessary complexity - perhaps someone from the
> > CC/PP working
> > > group could explain the rationale behind this? Secondly
> > including carriage
> > > returns in the XML file associated with a profile-diff causes
> > problems with
> > > the current servlet API. For example if I send the following
> > CC/PP request
> > > to a simple HTTP request snooping servlet on a Tomcat server
> > >
> > > GET /ccpp/headers/index.cgi HTTP/1.1
> > > Host: localhost
> > > Opt: "http://www.w3.org/1999/06/24-CCPPexchange"; ns=19
> > > 19-Profile: "http://www.aa.com/hw", "http://www.bbb.com/sw",
> > > "1-uKhJE/AEeeMzFSejsYshHg=="
> > > 19-Profile-Diff-1: <?xml version="1.0"?>
> > >  <RDF xmlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
> > >              xmlns:PRF="http://www.w3.org/TR/WD-profile-vocabulary#">
> > >              <Description ID="SoftwarePlatform" PRF:Sound="On" />
> > >          </RDF>
> > >
> > > Then I can successfully retrieve the file from Tomcat once, but
> > subsequent
> > > retrievals or not always possible as Tomcat reports
> > >
> > > Parse error, missing : in
> > > mlns="http://www.w3.org/TR/1999/PR-rdf-syntax-19990105#"
> > >
> > > This problem can be avoided by omitting carriage returns in the enclosed
> > > XML. However this requirement is not mentioned in either the CC/PP and
> > > UAProf protocol specs! The request above does not cause a
> > problem for Apache
> > > with a CGI HTTP request snooping Perl script, but I suspect
> > other servers
> > > using the servlet API will have similar problems.
> > >
> > > Of course once your server has got the profile, then there's
> > the problem of
> > > what to do with it! This also needs "further development" just like
> > > vocabularies. Stuart Lewis, a student at University of Wales at
> > Aberystwyth
> > > (sdl@aber.ac.uk) has a project report that discusses this. I've just
> > > finished a technical report that investigates implementing
> > HTTP/1.1 content
> > > negotiation for CC/PP and UAProf using the JENA RDF API (see
> > > http://www-uk.hpl.hp.com/people/bwm/rdf/jena/index.htm) that should be
> > > published externally this month. Another comment to the CC/PP
> > working group:
> > > please could you start keeping track of these resources in a
> > similar way to
> > > the RDF working group?
> > >
> > > Once a servlet API is defined, I think the next step would be
> > to add CC/PP
> > > support to open-source frameworks like Cocoon, Struts, and
> > Jetspeed (see my
> > > technical report at http://www-uk.hpl.hp.com/people/marbut/ for
> > more details
> > > of how these frameworks can be used for device independence).
> > They already
> > > try to address the problem of content adaptation, so it makes
> > sense to use
> > > them to demonstrate how CC/PP can be used to provide content to multiple
> > > devices.
> > >
> > > Incidentally feedback on my comments on HTTPex, servlet APIs
> > etc from the
> > > CC/PP working group is welcome!
> > >
> > > Mark H. Butler
> > > HP Labs Bristol
> > >
> > > -----Original Message-----
> > > From: cafe babe [mailto:cafe_babe@hotmail.com]
> > > Sent: 15 August 2001 16:34
> > > To: www-mobile@w3.org
> > > Subject: Any CC/PP App servers in the market
> > >
> > > Just curious to know, are there any commercially available
> > Application/Web
> > > servers in the market that are capable of using the CC/PP
> > information in a
> > > client request to generat customized content for a client.
> > > I remember seeing some CC/PP classes in Jigsaw the W3C web server. BEA
> > > Weblogic mentions something about device profiles but I am not
> > sure if it
> > > uses CC/PP for content customization.
> > > Quite a few  Application server vendors(Oracle,IBM,BEA to name
> > a few)  in
> > > the msrket today say that they are capable of customizing
> > content for all
> > > different kinds of devices(phones,PDAs,TVs etc) and that they
> > are extensible
> > > to support any new devices in the future. What I am not clear is that do
> > > they mean that they can support any device that can render
> > XHTML/HTML/WML,
> > > in whuch case the HTTP "Accept" header would be sufficient, or they mean
> > > that they can use a CC/PP kind of mechanism to do further customization
> > > based on other parameters like display size, media support etc.
> > > Inputs on this would be really appreciated.
> > > Thanks
> > >
> > > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> > --
> > ++++++++++++++++++++++++++++++++++++
> >   Johan Hjelm, Senior Specialist
> >      Ericsson Research Japan
> >
> >   Read more about my recent book
> > http://www.wireless-information.net
> > ************************************
> >
> >

--
++++++++++++++++++++++++++++++++++++
  Johan Hjelm, Senior Specialist
     Ericsson Research Japan

  Read more about my recent book
http://www.wireless-information.net
************************************