[gfs-wg] Re: Proposed Final Draft for RNS v1.0

[Hiro Kishimoto]

Hi Osamu,

I cannot make GFS-WG session #1 since it clashes with OGSA-RSS-BoF.
However, as I said in my previous email, I strongly recommend you
to refer the latest version of WS-addressing and WS-BaseNotification
in order to avoid version inconsistency.

Thanks,
----
Hiro Kishimoto

Osamu Tatebe wrote:
> Hi Manuel and all,
> 
> Thanks for the revised document.  Here are comments and issues need to
> be clarified in the document from our group.  If there are more
> comments from the GFS-WG, please post them to this mailing list before
> GGF14.  We would like to finalize RNS specification document in GGF14
> GFS-WG #1 session starting at 2pm on June 29.
> 
> Thanks,
> Osamu
> 
> ----------
> * Update operation
> 
> 'Type' needs to be described *not to be updated*.
> 
> * Symlink behavior for VFDS
> 
> We need to consider how to implement (or represent) a symbolic link
> (aka PathAlias in VFDS) in RNS.  Possible solution is
> 
> 1) to represent as 'Alias' but its targetPath is not updated when
>    moving the target entry, or
> 
> 2) to represent as 'Referral' but it has 'TargetPath' instead of
>    'EPR'.
> 
> Unfortunately, either solution affects the RNS specification...
> 
> * IteratorContext
> 
> When IteratorContext is created as ResourceProperties in WS-Resource,
> an EPR can specify the IteratorContext (as a WS-Resource).  This
> means iteratorContextID is not necessary, does not it?
> 
> * Junction message
> 
> In the current document, a referral message is only used for a
> referral junction.  On the other hand, this mechanism is quite useful
> for other junctions; Endpoint Reference Junction and Virtualized
> Reference Junction.  To do this, just add 'Type' and
> 'LogicelReferences' to QueryResponse and ChangeResponse.  'Type' needs
> to be added to distinguish a type of junctions (or type of junction
> messages).  In this case, 'baseDirectory' does not always refer to a
> 'directory'.  Maybe it is better to be renamed to 'basePath'.  Also,
> 'referralEPR' should be just 'EPRs' since it can refer to 'EPRs' in
> Endpoint Reference Junction.
> 
> Moreover, 'remainingPath' (I am not sure this name is good or not) is
> useful that represent a path to be traversed.  Of course, this can be
> obtained by 'Path' and 'basePath', while it is useful.
> 
> * XML Structure of EPRs and LogicalReferences
> 
> EPRs and LogicalReferences are basically a list of EPR and
> LogicalReference, while the structure is not known in the document.
> This needs to be clarified.
> 
> * <Entry> and <Target> in example of QueryResponse
> 
> Neither <Entry> nor <Target> is introduced in the document.
> 
> * rename operation
> 
> Now 'update' does not have 'Name'.  Need to update the description.
> 
> * QueryInput in list operation
> 
> 'EPR' and 'LogicalReference' seem to be missing QueryInput of list
> operation.
> 
> * Error message
> 
> Error message (string) is better to be added in QueryResponse and
> ChangeResponse.  Moreover, several typical error messages need to be
> defined such as 'no such junction or virtual directory', 'not a
> virtual directory', 'junction exists', 'is a virtual directory',
> 'virtual directory not empty', 'invalid argument', ....
> 
> * EPRs and LogicalReferences
> 
> How to update and delete entries in EPRs and LogicalReferences is not
> well-defined.  For example, how to create a junction entry that has
> two EPRs?  How to insert an EPR3 to a junction entry that already has
> EPR1 and EPR2?  How to delete just EPR2 from a junction entry that has
> EPR1 and EPR2?  Would you describe a procedure with an example of
> setResourceProperties?
> 
> * In the case that the specified 'Path' is a junction
> 
> When the specified 'Path' is a junction, 'lookup', 'delete', and
> 'update' operations are for the specified junction itself, while
> 'list' and 'create' are not since these operations basically apply to
> a sub entry (or entries) in the specified 'Path'.  This needs to be
> clarified in the document.  In the list and create cases, a referral
> message (or a above-mentioned junction message) could be returned as a
> QueryResponse and ChangeResponse, respectively.
> 
> * In the case that the specified 'Path' in create operation is an
>   alias to a virtual directory
> 
> When the specified 'Path' in create operation is an alias to a virtual
> directory, how does the create operate?  Since 'Alias' can be resolved
> within the service, it is reasonable to create a new entry under a
> virtual directory pointed to the alias specified by 'Path'.  This
> seems to be a special case enough to be described.
> 
> 
>