[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