Excellent - we're almost there! Just a couple of small issues: 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..." 2) Section 4 Endpoint Identifier Profile We should be able to have 0,1 or more EPIs added to the metadata element. 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... 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). 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. 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> That's all! See you all in DC. Regards, Frank. David Snelling wrote:

Folks,

Sorry for the large posting. The OGSA-Naming site is not allowing me to post - maybe I just need to sign up as a GF member.

Joel, Can you post both these documents in "Documents > Root Folder > Current Drafts"?

What I have done:

1) Accepted all previous changes.

2) Rewrote major sections (lots of out of date stuff about WS-Addressing being pre standard etc.)

3) Reorganized the sections around the 4 specs outlined in the use cases document,

4) Added the missing sections that were my action items.

5) Separated normative and non-normative parts of each section, see subsections "Non Normative Discussion". These sections could probably be extended.

6) I removed the SOAP message examples. These could go back in an appendix, but they would be non normative (I don't like having too much of this is a spec) and I wanted to get this out sooner.

7) Asked Michel Drescher to do a new set of schema and WSDL.

There are two documents attached:

1) draft-ws-naming-August-2006-1-ct.doc: This has all my changes tracked. This is provided for process reasons. I really expect folks top start with the clean copy.

2) draft-ws-naming-August-2006-1.doc: I have accepted all my own changes, since it is virtually a new document. People should start with this, and use the above to identify things they thought were there and went away.

Enjoy!

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

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory