Re: i69: Clarify "Requested Variant" [was: New "200 OK" status codes, PATCH & PROPFIND]

If creating multiple resources via POST is indeed a valid  
interpretation of 2616, could this be clarified in the 2616bis?

Thanks
Subbu

On Feb 4, 2008, at 6:40 PM, Mark Nottingham wrote:

>
> I don't think that does the trick. APP creates multiple resources  
> and returns a 201 with a Location of the "Member entry URI",  
> mentioning that other resources could have been created in the  
> process.
>
> So, a 201 can imply the creation of one or more resources; if the  
> response contains metadata (e.g., Location, ETag), they are  
> associated with the most important one, in the judgement of the  
> server.
>
>
>
> On 31/01/2008, at 7:14 AM, Yves Lafon wrote:
>
>>
>> On Thu, 31 Jan 2008, Julian Reschke wrote:
>>
>>>> Should we keep this "multiple locations for one resource" paradigm?
>>>
>>> First of all, I do not agree with the "single new resource"  
>>> interpretation. As Brian observed, that would be a conflict with  
>>> RFC5023.
>>
>> In that case, we need to amend the current text as I read it as  
>> implying there is only one new resource.
>> Also:
>> <<<
>>  A 201 response MAY contain an ETag response header field indicating
>>  the current value of the entity tag for the requested variant just
>>  created, see Section 6.1 of [Part4].
>>>>>
>> Should be:
>> <<<
>>  If one single resource is created, a 201 response MAY contain...
>>>>>
>>
>> -- 
>> Baroula que barouleras, au

Received on Monday, 25 February 2008 20:59:22 UTC