I was enlightened today on the telecon to the opinions of those of you who see a clear distinction between the activity template (JSDL) and activity instance options. I'm fine with that, although thinking about this I realize that we need extensibility, then, also in the CreateActivity operation. As a specific example, GRAM needs to access delegated credentials. Security requirements are out of scope of the OGSA-BES spec, but EPRs pointing to credentials clearly are in the activity instance category rather than the activity template category. The only way not to violate the above philosophy is to add an xsd:any (minOccurs="0" maxOccurs="unbounded" namespace="##other") to the parameter list of CreateActivity. Putting these extensions in the JSDL document isn't appropriate. This could also be a better solution for things like the subscription request and the CreateInSuspendedState parameters. They would essentially be out of scope of the spec, but not forbidden. I think that would appease those who don't like it specified in the spec given that not all implementations will want to have that feature or the exact same feature. Peter