Profile question - previous pen to paper

["Tim Grapes" <Timothy.Grapes@sesolutions.com>]

All,
I realize we are in the middle of the "profile" discussion and believe that Daryl's comment is a valid comment and question.  As this moves forward, I wanted to share, just as one input, that we have attempted to define some rules in the past (below).  Not saying these are necessarily correct or complete, or that the terminology is most appropriate.  Just input.
Tim Grapes

•	A TEP Constraint Schema or Profile MUST not become a new or additional messaging “standard” (another TEP “version”).  It is simply a more constrained version of an existing messaging standard.
•	A TEP Constraint Schema or Profile MUST not become a new or additional messaging “standard” (another TEP “version”).  It is simply a more constrained version of an existing messaging standard.
•	A TEP Constraint Schema or Profile message MUST comply with the OASIS TEP standard.
•	A TEP Constraint Schema or Profile message MUST always validate against the OASIS TEP standard Schema.  
•	A TEP Constraint Schema or Profile message MUST validate within the OASIS TEP standard namespace with no changes to root elements.
•	A TEP Constraint Schema or Profile message MUST use all required elements (i.e., no deletion of required elements are allowed).
•	A TEP Constraint Schema or Profile message MUST not change attributes for required fields.
•	A TEP Constraint Schema or Profile / message MUST NOT be a Proprietary Format.
•	A TEP Constraint Schema or Profile message MAY further constrain the TEP standard.*
(* may be thought of as a “constraint Schema” against the standard)
•	A TEP Constraint Schema or Profile message MAY add to required element definitions.*
(* only to extend or interpret the definition)
•	A TEP Constraint Schema or Profile message MAY limit the size of required elements.
A TEP Constraint Schema or Profile message MAY exclude optional elements.