[GFS-WG] RNS v1.1 update

[Osamu Tatebe]

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

-- 
Osamu Tatebe <tatebe at cs.tsukuba.ac.jp>