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

That should be good enough.

Thanks Mark.

Subbu

On Feb 26, 2008, at 3:22 PM, Mark Nottingham wrote:

> I'd be OK with adding a non-normative example, at the most; adding  
> normative language for this would imply that we're defining a sever- 
> side model for how HTTP should be implemented, which (as Roy has  
> pointed out several times), isn't a good idea.
>
> Cheers,
>
>
> On 26/02/2008, at 7:59 AM, Subbu Allamaraju wrote:
>
>> 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
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>

Received on Thursday, 28 February 2008 16:25:17 UTC