Re: Comments on draft-ietf-ohto-ccpp-exchange-00

Koen:
Thank you very much for your comments.

> Note that the HTTP Extension Framework is bit controversial in the
> IETF: it is an open question if this should be used for (IETF or
> outside standards level) HTTP extensions in stead of just defining
> additional headers.  I don't think there will be strong objections to
> you using HTTP-ext, but if you don't use it this will also be
> considered OK.  Switching to my personal opinion: I believe that use
> of HTTP-ext might slow deployment: at least you should verify whether
> prospective cc/pp implementers are happy with doing the work of
> implementing (the necessary subset of) http-ext too.

I know the controvercy. 
I believe that HTTP Extension Framework provides the better way of 
extending HTTP/1.1 but I also admit there may be concerns about deployment.
(HTTP Extension Framework has been implemented in Jigsaw Web
server though. http://www.w3.org/Jigsaw )

> ##   The absoluteURI in the Profile header field addresses an entity of at
> ##   CC/PP description which exists in the World Wide Web. 
> 
> As I indicated before at WWW9, I believe that some text on how to
> dereference these URIs would strengthen the protocol and make it more
> extensible.
> 1.1 If the URI is not a http: scheme URI, this spec does not prescribe
>   anything about the mechanism to dereference it.  Baseline client
>   implementations of this spec need not be able to reference non-http
>   URIs.

Right. I suppose mostly the dereferencing would be done by HTTP.
In Section 6. Example in the spec, I use HTTP for dereferencing.

Actually, I thought that how to dereference the URI is beyond the 
scope of this protocol but I think I should try to explain it more.

> 1.2 if the URI is a http: URI, then
<snip />
Those are valuable comments. Thanks.

> ##   The generation method of the profile-diff-name is as follows: 
> A am a bit concerned about this MD5-attaching mechanism. 
> As an alternative, I suggest
> you specify:
>    profile-diff-name   = profile-diff-number [ "-" profile-diff-digest ]
> so that the digest can be left out if wanted.

That would be a good idea.

> Also, if you are serious about making Vary more useful, you should
> also specify a 'preferred http-ext namespace number' (for example 50),

Right. I should have mentioned that.
Actually, the first version of cc/pp exchange protocol spec has 
similar notations. 
Excerpted from http://www.w3.org/TR/1999/NOTE-CCPPexchange-19990129

"The header prefix might be generated dynamically when the name 
space prefix is conflicted by another extension. 
However the name space prefix should have a "preferred"
 name because of the cache efficiency. "

> But aside from that, unless there are strong indications that header
> length restrictions are really a problem, I'd rather see the whole
> profile-diff header system disappear, with all information in these
> headers put directly into the Profile header.

I admit that's simpler.
If you have further concerns, please make me know.

> ##   The warn-code assignes three digits. The "1xx" indicates the status
> ##   of the CC/PP description(e.g. it is fresh or stale). The "2xx"
> ##   indicates the type of the content adaptation applied to the
> ##   message(e.g. content selection, content transformation, or content
> ##   generation).
> 
> This decomposition into 1xx and 2xx is nice, but you are not very
> extensible in adding new warn codes yet, as the spec now is silent on
> how clients should interpret new warn codes unknown to them.  There
> should be at least two classes (orthogonal to your 1xx and 2xx
> distinction now, so I guess you should add an extra number to the
> current codes): say a 1[12]xx class for 'serious -- if you get a code
> in this class and don't understand it, inform the end user', and a
> 2[12]xx 'non-serious -- if you get a code in this class and don't
> understand it, ignore it and keep silent'.

It makes sense to me a lot.

> That is all I have, I hope it is useful.

Thanks again for your thoughtful and valuable comments.
It is definitely useful.

Best Regards,
-- Taka

Received on Friday, 9 June 2000 18:01:02 UTC