Re: Comments on Grouping of Resources

Thanks for this, Jeremy!

> 1: Note the example
> is illegal, in that it does not conform with HTTP spec which does not
> allow username and password. Also the :mypasswd syntax is strongly
> discouraged in RFC 3986

This was meant to provide an example of what the URI userInfo component
may contain. Even though cleartext transmission of user's password is
strongly discouraged both in RFC 2617 [1] and RFC 3986 [2], it is still
widely used, and thus the example may be familiar to the reader. Anyway,
we'll seriously consider to modify the example as you suggest.

> 2: Typo
> <wdr:excludeHosts></wdr:includeHosts>

Thanks. We'll fix it.

> 3: includeHosts
> You seem to mean that includeHosts with also includes
> - in a quick skim I didn't see this stated explicitly,
> or for example that it does not include or whatever; nor
> what to do if you only want and not

wdr:includeHosts denotes all the resources with URIs where the host
component ends with one of the strings in the space-separated list. So


means: "resources with a URI host component ending with or". This of course includes,, and, but not If you wish to say
"* but not" you should specify what follows:


However, based on what you say, it seems that this is not clear. So
we'll revise the document accordingly.

> 4: I found example 4.6 I had to think fairly hard. If this is a standard
> idiom then it may be worth spelling it out a bit.
> "all resources on except those on shot in
> widescreen format."
> which is
> "all resources on except those on, and
> all resources on except those shot in widescreen format."

We'll revise the doc in order to make this clearer. What we meant is the

Let R' be the set of resources with the URI host component ending

Let R'' be the set of resources with the URI host component ending AND shot in widescreen format

The resource set definition corresponds to R=R'-R'' - i.e., the
resources in R' but not in R''.

> 5. The SHOULD under 4.7 is way too strong. I see no reason why the
> expression in 4.7 cannot be implemented efficiently and be generally
> useful; setting the expectation that Powder won't work well is not a
> good idea

Thanks for having pointed this out. Actually, we problem here is that
DRs may be implemented by using different technologies, which can be
more or less efficient depending on how DRs are expressed. Anyway, your
objection is correct, and we'll seriously consider it.

On behalf of the group, thanks again for your suggestions. Any further
comments we'll be greatly welcome.





Received on Wednesday, 1 August 2007 14:06:21 UTC