[ogsa-wg] draft-ogsa-profile-template-v1.5 (current comments and what I believe are the resolutions)
Tom Maguire
tmaguire at us.ibm.com
Mon Apr 18 19:53:47 CDT 2005
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
More information about the ogsa-wg
mailing list