[ogsa-naming-wg] Responses to outstanding emails

[David Snelling]

Mark,

On 16 Sep 2006, at 15:14, Mark McKeown wrote:

> 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?

I tried very hard to make sure the language is unidirectional. Only  
the first is intended. There is no possible way that the second  
clause can be enforced. I can have private EPI for your entities that  
you never know about. This is a long standing distributed systems  
funny that by now I don't even think about the possibility. If you  
can propose better language, please do so, as this spec is about to  
head for public comment.


>>> 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 felt that might be the case.

> 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.

I see what you're after. This is a refinement of  
naming:ResolveFailedFault specifying the reason it failed. I wasn't  
on the call, but the rest of the specification seems to be a terse as  
possible. I suspect that the WG preferred  a few general faults  
rather than spelling out all the possible cases.

> 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.

I don't believe that this is a fault in the resolver service.

As a client, I would expect this fault from the resource it's self,  
e.g. wsrf-rw:ResourceUnknownFault or  wsrf- 
rw:ResourceUnavailableFault. In general the resolver may know nothing  
about the current state of the resource, in fact I believe it will be  
rare that global resolver services will have any such knowledge, as  
they will simply be notified of updates.

> These are analogous to the HTTP error codes 404
> and 410, I am not saying WS-Naming should say anything about HTTP
> errors.

I understand part of my problem before. These errors mean nothing to  
me. I guess I only go down as far as SOAP.

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

Yes. In many cases all is wanted is an identifier and the instance  
may never exist , although the spec does not address this use case  
and assumes that at some time one may want to resolve an EPI to an EPR.

-- 

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)