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