Re: AtomPubIssuesList for 2005/02/22

[Ezra Cooper <ezra@xxxxxxxxxxxx>]

On 2/24/05 4:53 PM, "Robert Sayre" <mint@xxxxxxxxxxxxxxx> wrote:

> Joe Gregorio wrote:
> 
>> PaceSliceAndDice
>> 
>> +1 In general, but I have some comments
>> 
>> 1. Ezra, I really liked the way you handled the difference between ordered
>>   and unordered collections. Its simple and yet handles all the cases,
>>    entries, simple resources, categories, and users.
> 
> I guess it depends how many simple resources, categories, and users you
> have.

I don't see any reason why these things couldn't have "updated" properties,
making them easier to fetch in chunks; but I didn't want to require it.

>> 2. This line """This URL MUST include the collection
>>    URL as an initial substring, and MUST contain only
>>    one path segment after the collection URL. "Path
>>    segments" are as defined by [[URI RFC]]. This
>>    restriction permits compatibility of the URI space
>>    with that of a WebDAV collection."""
>> 
>>    This seems like a restriction that is un-necessary. IF someone
>>    wanted to make their Atom API WebDAV compatible then they
>>    would *have* to make this restriction in accordance with
>>    WebDAV, not the APP.
>>    There is no where in the APP that this
>>    restriction on the URI space is used.
>> 
> 
> Ezra's proposal includes a depth header. I don't see a restriction on
> circular references.

Here my intention was that "Depth: infinity" would just give me everything
that is a descendant of this collection--with no repeats. I'll revise it to
be more clear on that point. I'm not sure that circular references are bad.

> URI constraints are an easy way to accomplish that.
>   Any namespace operations would probably get an implicit WebDAV
> collection whether we specify it or not. It's a reasonable thing to want
> to MOVE an image. This means the last path separator will matter, we
> just won't have specified it.

But is MOVE going to be part of Atom? Let's suppose not, for the moment. If
a server then wants to support WebDAV fully, there's no reason it can't
restrict its own URIs in this way, and support MOVE. If it's not doing MOVE,
then what's the point of restricting it?

To include MOVE, a la carte, within Atom, seems like feature creep to me.

> The second point is that half the reason
> WebDAV has the restrictions it does is so that clients can expect a
> server to act the same.

Expect the server to act the same in what way?
 
> "Free" URIs look sort of like XSS attacks to me.

I don't see any risk here. Can you explain?

> The third point is that there is still no use case for URI freedom,
> while the restriction has many.

I can see use cases for WebDAV, as you've outlined, but not for the URI
restriction per se. Fewer spec'd restrictions should mean that we're
compatible with more things, not fewer. It still seems as though
WebDAV-savvy implementations could be a compatible extension on top of the
APP core--and we wouldn't have to place needless restrictions.

Am I missing the insight that would explain how spec-restricted URIs would
enable something?

> URI freedom would be more interesting if
> you could remove an entry from one collections without removing it from
> all collections (LINK/UNLINK).

I'm afraid I don't know the spec you're referring to here; can you give a
reference?

>> 4. """If no Range: HTTP header is given in the request, the interval is taken
>>    to be all of time."""
>> 
>>    I was initially taken aback by that, as it seems like an odd default,
>>    which means if I were to hit that URI with a browser, or
>>    a robot, I would by default get the largest possible document with
>> all the entries
>>    in it. 
> 
> Most servers will probably just throw an error. Secondly, it's not a
> Range. I don't know what it is, but it's something else. There's no
> unit, and there's no total.

Do you mean, "not including a Range header" is not a Range? Seems true
enough. Do you want to see something changed?

Ezra