[ogsa-naming-wg] Responses to outstanding emails

[Mark McKeown]

Hi Dave,
        Some follow-up comments inline.

> > 3) It is stated in Section 4 that "Endpoint Identifiers conforming
> > to the Endpoint Identifier Profile MUST be globally unique in both
> > space and time". On the face of it this means I cannot make a copy
> > of an EPI! I believe what is ment is that "Endpoint Identifiers
> > conforming to the Endpoint Identifier Profile MUST globally and
> > uniquely identify the same thing in both space and time".
> >
> > I also think MUST is too strong, and should be replaced with SHOULD.
> > I believe that it is impossible to guarantuee that a name will not
> > be reused to indentify two different things. This is also related to
> > the issue of symmetry in section 4.1, if EPIs do globally and uniquely
> > identify things for all time then we could use them to say that two
> > things are not the same because their names are not the same.
>
> This was discussed in the meeting today and we felt that the
> understanding was clear and that the association was unique in S & T
> and not the physical string. No changes made.
>

The spec now makes it clearer that it is the association, and not
the string, that is important. The line in the document now reads:

"EndpointIdentifiers conforming to the Endpoint Identifier Profile:

   * MUST uniquely identify the same endpoint in both space and time.

   * MUST conform to IRI syntax [RFC 3987]."

Does the first point mean that: an EPI will only ever identify
one endpoint AND no other EPI will ever identify that endpoint.
Or is only the first clause implied?


> > 6) Resolver Service. I think the resolver needs the equivalent of
> > HTTP 404
> > "Not Found" and HTTP 410 "Gone" as standard fault messages. Caching
> > information would also be useful; at least the ability for the
> > resolver to be able to say the EPR will not change in the case
> > where it
> > knows it cannot.
>
> The usual practice is to only define those faults specific to the
> specification. If i understand this, these faults arise from other
> parts of the infrastructure.
>

I think there is maybe some mis-understanding. I mean that the
resolver service will often have the fault that the it does not
recognise the EPI that it has been asked to resolve, so there
should be a canonical fault defined for this. Another common fault
is the case when the INSTANCE no longer exists; should the resolver
not have a standard response when a client tries to resolve the
EPI in this case. These are analogous to the HTTP error codes 404
and 410, I am not saying WS-Naming should say anything about HTTP
errors.


A further question is whether it is possible to have an EPI for
an INSTANCE that has not yet come into existance?

cheers
Mark