[ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]

[Steven Newhouse]

> > > > I recently went to implement some of the file staging extensions
> > that
> > > > the HPC group has described.  In particular I was looking to
> > implement
> > > > SCP and I figured that if I was going to implement that spec., it
> > made
> > > > sense to do it according to a standard rather than to come up
> with
> > > > something new and non-interoperable.  However, in the process of
> > > > implementing the specification, I came across a minor nitpick
> that
> > I
> > > > have concerns about.  Specifically, if I read the specification
> > > > correctly, I believe that it is the case that a BES container is
> > > > required by the spec. to fault if a user passes authentication
> > > > information in the URI rather than using the file staging
> > extensions.
> > > > I'm confused as to why the group decided to prohibit a valid form
> > of
> > > > extension to the JSDL and BES specification.  I understand that
> > that
> > > > method of passing information may not be the best choice or most
> > secure
> > > > choice, but I would think that it makes more sense for the HPC
> > group to
> > > > simply standardize on their way of passing authentication
> > information
> > > > rather than prohibit other, in my opinion, equally valid
> > authentication
> > > > mechanisms.  The fact of the matter is that Genesis II has, in
> the
> > past,
> > > > allowed authentication information to be passed in the File
> staging
> > > > URIs.  At this point, it seems like I have the choice of forgoing
> > > > backwards compatibility in favor of HPCP File staging extensions
> > > > compliance, or forgoing HPCP File staging compliance in favor of
> > > > backward compatibility where I really see no good reason why both
> > > > couldn't be achieved.
> > > >
> > > > I'm not trying to cause trouble here, I'm simply curious as to
> the
> > > > reasons for this decision and specifically wanted to mention this
> > in
> > > > case the HPC group hadn't thought of this potential issue before.

It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.

Steven