[ogsa-naming-wg] Responses to outstanding emails

[David Snelling]

Folks,

Here we go:

All open issues that I feel could not be resolved are in new  
trackers. If anyone thinks I have missed the mark on these, let me know:

First from Andreas:

> Section 2.2 states "The conformance claim URI for this Profile as a
> whole...."  Emphasizing the "as a whole" for the moment, if a service
> exposes this claim does it mean that it (implicitly) exposes all
> sub-profile claims defined in this document? Or does it mean that it
> must also expose other relevant claim URIs in addition to this URI?

We fixed this in today's discussion by removing the overall claim ID.

> Section 6 says
> "INSTANCES conforming to the Web Service Endpoint Address Identifier
> Profile MUST conform to the Unambiguous Web Service Endpoint Profile."
>
> but the Unambiguous Web Service Endpoint Profile is already mandatory
> for anyone claiming conformance to the WS-Naming profile. So shouldn't
> this be
>
> "INSTANCES conforming to WS-Naming MAY conform to the Web Service
> Endpoint Address Identifier Profile."

This has been superseded by the above change.

> Section 5 is missing a conformance statement.

Not needed, as this is a mini-spec rather than actually a profile.  
The portType URI provides the necessary tag where required.

 From Mark Meown:

> 1) The reference to "cryptographically strong" in the abstract. I
> am not sure what this means so could it be expanded or a reference
> included.

As this is non-normative and only informative, I deleted the line.

> 2) I don't think that the abstract is clear about the primary
> purpose of names: Names allows us to determine if two things are
> in fact the same thing by comparision of their names. It becomes
> clear then that EPRs, as defined by the WS-Addressing, cannot be used
> as names because the specification does not define any mechanism for
> comparing EPRs for sameness.

I think there is enough motivation in the introduction, so left the  
text the way it was.

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

> 4) The URI specification, eg RFC 3987, advises against bit-wise
> comparision as it can lead to false-negatives if strings are
> encoded differently. I think it is enough to refer to the URI/IRI
> specification on how to compare URIs/IRIs.

This was fixed in the meeting to refer to the equals function as  
defined by RFC 3987.


> 5) As an implementor I find Section 3 a bit ambiguous. Taking the two
> conformance targets:
>
> "MUST include sufficient information within all ENDPOINTREFERENCEs  
> minted
> by the INSTANCE to guarantee that all messages sent using that
> ENDPOINTREFERENCE are received by a unique endpoint within the  
> context of
> the implementation."
>
> and
>
> "MUST guarantee that all messages sent to the INSTANCE are received  
> by a
> unique endpoint within the context of the implementation or the  
> message is
> rejected and a fault returned."
>
> What is the "INSTANCE"? In the first point it seems to be the thing
> that creates the EPRs, while in the second point it is the thing that
> recieves the messages. I had thought that it was EPRs that can conform
> to the profile.

I clarified the text in the first case.


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

> 1) Section 4 Endpoint Identifier Profile
>
> <quote>
> The EndpointIdentifier element MUST be included in the  
> ENDPOINTREFERENCE
> wsa:Metadata element. The schema for an EndpointIdentifier is included
> in Appendix A."
> </quote>
>
> This is a little confusing because we could also have an EPI  
> through the
> wsa:Address of a Web Service Endpoint Address Profile or we could add
> one in the reference properties.
> Maybe it should be something like "When an EPI is added to the  
> Metadata
> element, then it MUST be according..."

This was addressed at the meeting today and the problem fixed.

> 2) Section 4 Endpoint Identifier Profile
>
> We should be able to have 0,1 or more EPIs added to the metadata  
> element.

I clarified the text, but the WS-Addressing allows 0 to unbounded  
xs:any in the metadata element, so this is implied.

> 3) section 5.1.3 Fault Types
>
> <quote>
> /naming:referral-epr
>
> An EndpointReference, provided by the resolver INSTANCE, that  
> references
> an alternative resolution service. The referral-epr element contains
> either a naming:EndpointIdentifierResolver and  
> naming:ReferenceResolver
> element, as defined is section 5.2.
> </quote>
>
> This is a little confusing... I believe this implies that we use the
> exact same elements for the EndpointIdentifierResolver and
> ReferenceResolver EPRs as we use in the EPR's Metadata element...

Yes. This is intentional as the types are in fact the same. No  
changes made.


> 4)section 5.1.3 Fault Types
>
> We should also add the option to return a referral EPI, i.e. an alias
> that in turn can be resolved to an application-EPR.
>
> In other words, the exact same
> EndpointIdentifier/EndpointIdentifierResolver/ReferenceResolver trio
> that we can add to a Metadata element could be returned as referral
> information (including multiples).

This is a pending issue. I created a tracker.

> 5) section 6. Web Service Endpoint Address Identifier Profile
>
> I don't believe it's clear enough that such an wsa:Address is a
> full-fledged EPI that can be used with the resolvers that we defined.
>
> Maybe we can change:
>
> This profile restricts the “Unambiguous Web Service Endpoint Profile”
> further, and defines the requirements placed on an EPR wsa:Address  
> field
> (IRI) to ensure that it is unique in space and time, and that it by
> itself identifies the endpoint/resource.
>
> to:
>
> This profile restricts the “Unambiguous Web Service Endpoint Profile”
> further, and defines the requirements placed on an EPR wsa:Address  
> field
> (IRI) to ensure that it is unique in space and time, and that it by
> itself identifies the endpoint/resource, and can therefor be used  
> as an
> EPI with any of the defined resolver services.

This change was added today during the meeting.

> 6) Annotation of EPR with profile conformance claim URIs
>
> In some cases, we can infer the profile conformance claim from the EPR
> content, like:
> if the Metadata section includes an EndpointIdentifier,
> EndpointIdentifierResolver, or ReferenceResolver element, then it
> conforms at least to the "Unambiguous Web Service Endpoint Profile".
>
> However, we have no way yet to communicate any profile conformance  
> claim
> in the EPR.
>
> I suggest to add another element to the EPR's Metadata section like:
>
> …
> <naming:profile-conformance-claim>
> xsd:anyURI
> </naming:profile-conformance-claim>
> ...
>
> such that we could have an EPR like:
>
> <wsa:EndpointReference
> xmlns:wsa=”http://www.w3.org/2005/03/addressing”
> xmlns:naming=”http://ggf.org/name”>
> <wsa:Address>
> http://tempuri.org/example_application/B94C4186-0923-4dbb- 
> AD9C-39DFB8B54388
> </wsa:Address>
> <wsa:Metadata>
> <naming:profile-conformance-claim>
> http://www.ogf.org/naming/2006/08/naming-wsepai-pf
> </naming:profile-conformance-claim>
> </wsa:Metadata>
> </wsa:EndpointReference>

I believe there are existing ways to do this. According to Tom,  
claims can go in the WSDL at the operation level. Thus portTypes can  
advertise this information. For EPRs there is a defined way  
(wsa:Metedata) to include portType information in the EPR. We should  
simply use these existing mechanisms.

> I ran WSDLs through our validation tools. Here are two issues:
>
> - <wsdl:import
>         namespace=http://www.w3.org/2005/03/addressing
>         location="http://www.w3.org/2005/03/addressing"/>
>
> Missing quotes. Should be
>
> - <wsdl:import
>         namespace="http://www.w3.org/2005/03/addressing"
>         location="http://www.w3.org/2005/03/addressing"/>

Fixed.

> -    <wsdl:message name="Resolve"/>
>
> At least one wsdl:part element is required. Basic profile 1.0  
> compliance
>
>     <wsdl:message name="Resolve">
>         <wsdl:part name="void"  element="naming:VoidType"/>
>     </wsdl:message>
>
> With these changes it validates with our tools and stubs get  
> generated.

In a later mail to me this was explained to be a tooling problem. No  
change made.

> For the naming-spec, I don't see any major issues. One item that might
> need to clearify is the mixed use of URI and IRI in the document. IRI
> can be seen as a super set of URI because of its relaxed syntax
> restriction. In section 4, it says
>
> EPI ... "MUST conformto URI syntax [RFC3987]."

Fixed.

> But RFC3987 is for the definition of IRI. I suppose the author(s)
> really meant the IRI here (which will also be my selection).
>
> Such mixed use is also seen in a few examples given in the PortType
> definition (e.g. "5.1.1
> <naming:endpoint-identifier>xsd:anyURI</naming:endpoint-identifier>").

NB: From Tom M. "The correct xml type for IRIs is xsd:anyURI."

> I would suggest to go through the use of URI in the document and
> replace them with IRI when appropriate.

Done.

In summary, only outstanding issue is the possible Fault for EPIs.

-- 

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)