Re: By way of example.

In one of my implementations, our service doc is always available
through the same uri..

  http://example.org/oa/service/atom/introspection

The content of the returned document varies depending on the
authentication credentials of the caller.  The document is served over
an SSL connection.  We're not returning a Content-Location header
because there's no need to return one.

Where's the collision?

- James

Eric J. Bowman wrote:
>> I beg to disapprove. You are making a mistake because you expect several 
>> protocols to play through the same interface (GET, PUT, POST, etc.) with 
>> a single URI.
>>
> 
> http://example.com/service
> 
> This is a URI collision even if the only thing it serves up is .atomsrv, even 
> if I expect only one protocol (APP) to dereference this.
> 
> If the returned Content-Location looks like /service for all users, this is 
> clearly a URI collision.  My solution, returning userid.atomsrv, is simply 
> another form of the same URI collision inherent in the spec, no matter how 
> radically various implementations diverge.  You may not like my 
> implementation but I guarantee you you cannot avoid the URI collision in 
> yours, either, unless you restrict to one user.  It's what the spec calls for.
> 
> -EJB
> 
> 
> 
>