[ogsa-wg] Once upon a time or two ...

[Mark McKeown]

Hi Dave,

snipped

>
> Another advantage of URIs is that publishers are permitted to use their
> structure to pass back server-specified information and clients are
> permitted to parse URIs to extract this information.  So an LSF system
> could include the job-id in a certain part of the URI and clients can
> extract it as necessary.  (Although one could argue whether that was any
> neater than adding a specific XML field).

WebArch[1] recommends that URIs should be opaque to the client - if
a resource provider encourages a client to reason about his URIs a
coupling is created between the client and the resource provider
- equivalent to one of Adam Bosworth's shared secrets[2].
The resource provider is tied to an approach to creating URIs
that may not be appropriate in the long term.

cheers
Mark

[1] http://www.w3.org/TR/webarch/
[2] http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=337&page=1

>
> Best wishes,
>
> Dave.
>
> > -----Original Message-----
> > From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On
> > Behalf Of David Snelling
> > Sent: 18 November 2005 15:12
> > To: Frank Siebenlist
> > Cc: ogsa-wg; ogsa-naming-wg at ggf.org
> > Subject: [ogsa-wg] Once upon a time or two ...
> >
> > Folks,
> >
> > Once up on a time or two Frank wrote:
> >
> > > Without the proper uniqueness guarantees for the
> > wsa:Address, the use
> > > of ws-naming's AbstractName is meaningless.
> > >
> > > The EPR with an embedded AbstractName essentially describes
> > a binding
> > > between the Address and the AbstractName.
> > > One could argue that this binding is a bit of a flaky assertion
> > > without any way to specify time-validity or issuer.
> > > As a result, one can not see from an EPR alone when it was
> > issued or
> > > whether it is still valid or not.
> > >
>
> > > This would yield the undesirable situation that you would have two
> > > EPRs with identical Addresses and two different AbstractNames
> > > associated with different resources, and the client would
> > have no way
> > > to see which one of the EPRs is valid...
> > >
> > > For example, if I have two EPRs with the same Address,
> > where one EPR
> > > includes an AbstractName that identifies MyBankAccount and
> > the other
> > > includes an AbstractName identifying YourBankAccount, then
> > one of us
> > > will not be happy with that situation...
> > >
> > > In order to avoid this ambiguity, we need the guarantee from the
> > > EPR-minter that Address values will not be reused for different
> > > resources: for all times, the Address should either refer
> > to that one
> > > and only resource, or it should be invalid (and it is allowed to
> > > change between those two states).
> > > Furthermore, the EPR-minters should ensure that globally unique
> > > Addresses are used for a resource such that different
> > EPR-minters do
> > > not (accidentally) use the same Address for different resources.
> > > The described uniqueness properties of the Address constitutes a
> > > required EPR-minter profile for the use of AbstractNames.
> > >
> >
> > This issue has yet to be addressed to my satisfaction. There
> > have been
> > a number of email exchanges in response to it on several
> > occasions, but
> > none of these threads actually deal with the issue.
> >
> > Put simply, if you don't put globally-unique-in-space-time
> > requirements
> > on your address (GSR in OGSI speak*) then any similar
> > requirements you
> > put on an Abstract Name (GSH in OGSI speak) are wasted.
> >
> > I believe that answering this issue will help clarify many of
> > the other
> > threads (miss) associated with this issue.
> >
> > In particular, I believe Frank is right. Therefore, if an EPR
> > is going
> > to be a WS-Name, the wsa:Address MUST have the same uniqueness
> > properties as the Abstract Name. Then if the answer to the question,
> > "Why do this uniqueness stuff twice?", is "I don't know!", then it
> > seems logical to me that a WS-Name is a profiled EPR along the lines
> > proposed by Tom M.
> >
> > Thoughts?
> >
> > Historical Footnote:
> >
> > * Note: OGSI addressed this issue in GSRs by requiring that clients
> > could detect when the GSRs were stale and that services
> > reject them if
> > a client attempted to use them. GSHs had uniqueness
> > constraints placed
> > on them.
> >
> > --
> >
> > Take care:
> >
> >      Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
> >      Fujitsu Laboratories of Europe
> >      Hayes Park Central
> >      Hayes End Road
> >      Hayes, Middlesex  UB4 8FE
> >
> >      +44-208-606-4649 (Office)
> >      +44-208-606-4539 (Fax)
> >      +44-7768-807526  (Mobile)
> >
> >
>
>