[GFS-WG] RNS v1.1 update

[Hideo Matsuda]

Dear Tatebe-san,

Thanks a lot for your updating.

Regarding the case in the rename operation, I would like to
support the 2nd choice (fix the order of operations) since
it gives the same semantics as the sequential operations.

Best regards,

Hideo Matsuda

> Hi all,
> 
> I updated the RNS 1.1 spec and OGSA WSRF BP rendering docs based
> on the discussion during OGF28 and comments in the tracker.
> 
> http://forge.ogf.org/sf/go/artf6426
> http://forge.ogf.org/sf/go/artf6427
> 
> The Change includes
> 
> - Section 1.1, "a pseudo-schema" is changed to "a pseudo-UML"
> - all "RNSResponseEntry" are changed to "RNSEntryResponse"
> - all "rns:response-entry" are changed to "rns:entry-response"
> - Section 2.3.2, add a missing "</s11:Envelope>" in an example
>   of an add request message
> - all "an lookup" are changed to "a lookup"
> - all "an rename" are changed to "a rename"
> - remove Section 3
> 
> Regarding "failure", there is a comment as follows
> 
>> all the content in the spec up till page 18, use “fault”,
>> including example, but from section 4 onward, all the faults
>> become “failure”, for consistency’s sake, and a common
>> sense in SOAP, “fault” is better here.
> 
> I leave it as it is, since this document tries to describe a
> more general way.  Please send comments if you think it should
> be changed.
> 
> Finally, regarding "uniqueness" of the entry-name, the discussion
> of OGF28 suggests to mention this not only in the add opration
> but also in the rename operation.
> 
> When editing about this, I found we need to clarify the case such
> that the target entry exists.  In the POSIX, it will be atomically
> replaced.  If we follow the POSIX semantics, there is an
> undeterministic condition when renaming multiple entries in a bulk
> operation.  For example, when there are two rename requests to the
> same target name, both requests will succeed but the result is
> different depending on which one is applied first.
> 
> I guess there are two possible solutions:
> 
> 1. Do not follow the POSIX semantics.  If the target entry exists,
>    rename fails with RNS Entry Exists Failure.
> 
> 2. Fix the order of operations in bulk operations.  If we assume
>    operations are processed in the sequence order provided by the
>    input argument.
> 
> How do you think about it?
> 
> Thanks,
> Osamu
>