TDD Handle extra parameters when publishing/extensibility of the creation endpoint

[relu91]

In the current state, the specification prescribes that the create method receives as input a Thing Description (I'm deducing this from the allowed content type, correct me if I'm wrong). Now we know that if we want to convey additional registration information we can actually send an Enriched-TD, where we can state the expiration time with the expires property.

Given that, what if I need to add further parameters to the registration process? consider that those parameters might be implementation-specific or standard parameters to be added in the next charters. I see two possible parameter categories:

1. TD specific parameters: parameters that closely relate to the TD document lifecycle (like expires).
2. TDD specific parameters: like on spot configurations of some internal TDD process.

Category 1 parameters might simply fall under the RegistrationInfomration category, but category 2 does not fit well in my opinion. As an example consider that in my own TDD I added the ability to force create a TD with an option (for whatever reason). Where this option should be conveyed? Inside the TD document that I am sending. Why? I don't want this option to be recorded... it is transient. As query parameter in the URL? What if I have complex objects to convey a configuration? What if it is sensitive information that I want to be protected inside the payload?

Is this payload structure ever be considered as input for the create method? :

{
  thingDescription: { /* Td document goes here */ },
  // I can add here any new/ implementation specific parameter
 }

Disclaimer
I know that we are in a delicate moment in our timeline and I don't want to cause trouble. This issue should be taken as a genuine question from an implementer and it is not meant to be a blocker for the standardization process.

[farshidtz]

The operation in question is to create a Thing Description at /things/<id>. The suggested payload structure is not a TD.

Here is how I'd do it:

1. If you need to supply attributes to influence how a particular create operation must happen, then the query arguments or headers are the best place.
2. If you need to add additional attributes which affects the registration lifecycle (regardless of the initial creation step), then add those to Registration Information.
3. If you need to add additional information to the TD which has nothing to do with the above, then simply extend the TD.
4. If you need to associate a resource to a TD, then store it elsewhere (at /your-resources/<id>) and create a link from the TD to it, or vice versa.

You can create a high-level API endpoint which takes your suggested payload structure and manages both a TD and the other resource.

[relu91]

Thanks, @farshidtz I think you have defined a good strategy. I was closing the issue, but I'm wondering if this can be added to the current document as an improvement to an implementation guideline.

[mmccool]

Seems the discussion has resolved, I will mark as Propose Closing (meaning we will glance at it one more time in a near-future meeting; if you disagree with closing, please say so...)