Ian Foster: Is this rewording correct? I wasn’t sure of the meaning: It seemed to say that no Profile could ever make reference to an extension, which seemed unnecessarily restrictive, and also is contradicted by the next paragraph. <trm>Section deleted per AI to remove copyrighted material</trm> Ian Foster: This is unclear to me. What are “other profiles”? <trm>Section deleted per AI to remove copyrighted material</trm> Ian Foster: I’m not sure what this is saying. Of course it’s true, but how does this relate to profile conformance? <trm>Section deleted per AI to remove copyrighted material</trm> Dave Snelling: This definition is critical as it distinguishes profile types below. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: It has been suggested that we don't need this category. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Tom Maguire: Needs work The paragraph in question: In some cases, specifications allow multiple interpretations of aspects of the specification. Where this variability in interpretation is likely to effect interoperability, the profile should restrict the interpretation. The nature of these restrictions may range from a simple clarification of meaning in a specification to the inclusion of "mini" specifications for missing content in the referenced specification. Note that if such a "mini" specification becomes significant in size or relevance outside the given profile, it should be spun out as a separate normative specification and referenced externally. <trm>We are in practice doing this for KeyInfo exchange in Basic Profile. The question remains do we need to provide additional guidance on when to spin-off</trm> Dave Snelling: The names of these profile types follow the GGF document type and process models. We could use just two types, informational and normative, and allow the GGF process only to distinguish the later two. We would still need our own guide-lines, however. There has also been a suggestion for other names. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: There is concern that this non-normative form of profile <informational> may undervalue the others. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: There was some surprise that there were no restrictions on either the status value or the adoption value. Discuss on a call. <trm>Discussed ad-nauseaum and agreed to</trm> Dave Snelling: Can other WGs create OGSA Profiles? <trm>Other WGs can create OGSA profiles but they must be approved by the OGSA WG. Have we clarified this process?</trm> Dave Snelling: As interoperable implies at least two implementations, it would exclude key specifications that the OGSA WG may want to encourage implementers to address. Do we need another category or a refined definition of interoperable? Discuss on a call. <trm>Discussed. I believe we have agreed to the set of profile types defined in the document.</trm> Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.   – Antoine de Saint-Exupery T o m   M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY  12601