RE: CCPP Implementation

Peter, Alan

1. HTTP-ex

Personally I would suggest you don't use CC/PP protocol using HTTP-ex. The
CC/PP protocol documents you refer to have not been through any W3C
standardisation process and should not be regarded as standards. Furthermore
HTTP-ex is not compatible with the majority of existing web servers as they
do not support methods such as M-GET. Personally I would prefer to see CC/PP
use a protocol like the W-HTTP one in the UAProf spec that is compatible
with HTTP/1.1. 

There has been some discussion about this before - see
http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0010.html
http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0012.html
http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0017.html
http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0020.html
http://lists.w3.org/Archives/Public/www-mobile/2001Aug/0021.html

2. CR and LF

I suggest look at the HTTP/1.1 spec, but you need to check the HTTP-ex spec
as well just in case it is significantly different.  

The spec you want is
http://www.w3.org/Protocols/rfc2616/rfc2616.html
see section 4.2 Message Headers

Specifically:
"Header fields can be extended over multiple lines by preceding each extra
line with at least one SP or HT."
where SP refers to space whereas HT refers to horizontal tab.

Also note in my experiments I've found a number of servlet / J2EE
implementations do not follow the HTTP/1.1 spec correctly. Therefore don't
assume that just because Jigsaw will process something, it complies with the
spec. This isn't a criticism a Jigsaw - it may implement the spec correctly
- but you need to refer to the spec as well to make sure (I know because
I've made this mistake myself).

4. Base64 encodings

It is possible that the examples in the CC/PP protocol documents are
ficticious and this is why your algorithm can't process them. Without
actually writing some test code I'm afraid I don't know. As Peter notes, an
implementation of base64 encoding is easily available in Java.  

Also note there are a number of issues around profile-diff-digests that have
been identified by the UAProf folks to do with how proxies process
whitespaces. As the profile fragment contained in the profile-diff header
can potentially be altered by proxies or gateways, it is possible that they
will insert additional white spaces at the start of lines or break lines
according to the HTTP/1.1 spec. If this happens then the server will
calculate the MD5 value for the request, but it will differ from the MD5
value in the profile-diff-digest so the server will ignore the profile
information. This rule is present in the specification in order to ensure
the integrity of the profile. One possible solution to this problem would be
a new algorithm, derived from MD5, that ignored whitespaces so that changes
introduced by the proxy would not affect the profile-diff-digest value. For
an example of how to do this see DELI available from my web page. 
 
best regards,

Mark H. Butler, PhD
Research Scientist
HP Labs Bristol
http://www-uk.hpl.hp.com/people/marbut/

> -----Original Message-----
> From: Vogel Peter (FV/SLM) * [mailto:Peter.Vogel2@de.bosch.com]
> Sent: 04 December 2001 15:01
> To: www-mobile@w3.org
> Subject: AW: CCPP Implementation
> 
> 
> Hello Alan,
> 
> > Von: Alan Ng [mailto:ngyahloon@yahoo.com]
> >
> > digest fixed? Any place where i can get the Base64
> > coding in C/C++?
> 
> Perhaps a Java implementation helps as well. You will
> find one within the Jigsaw Server from W3C.
> 
> > When we encode the CC/PP
> > descriptions, do we need to include "\n" or is
> > everything in a long sequence?
> 
> It is my understanding that you have to omit all CR, LF
> within the CC/PP description, following the Profile-Diff
> header (see. 5.2.2 in CCPPex).
> 
> When you transmit CR,LF in your CC/PP description e.g.
> in Jigsaw, it will not work (at least, when you have 
> a CRLF in the first line  of your description, starting 
> with Profile-Diff-1:).
>  
> > 2. When we append the complete profile, at which part
> > should we put in the CR/LF?
> > 
> > For example:
> > 
> > GET /example.htm HTTP/1.1 (CR/LF)
> > Opt: "http://www.w3.org/1999/06/24-CCPPexchange";
> > ns=19 (should we put CRLF here?)
> 
> Yes. Seems to work.
>  
> > 19-Profile: "http://www.abc.com/default",
> > "1-sldknaevsxlskngaedqadf==" (should we put CRLF
> > here?)
> 
> Yes. Seems to work.
> 
> > Lastly, for the profile diff header value, should CRLF
> > be appended at the end (after </RDF>) or after each
> > line?
> 
> I think it should be appended at the end only. Jigsaw filters
> some CRLF within the CC/PP description. But it has problems
> with a CRLF in the first line of the Profile-Diff header.
> 
> Regards,
> Peter Vogel. 
>

Received on Tuesday, 4 December 2001 12:29:26 UTC