[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (CAMP-80) Section 6.11 "Registering an Application" is unclear about what Content-Type header must be for various scenarios
[ http://tools.oasis-open.org/issues/browse/CAMP-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34413#action_34413 ]
Gilbert Pilz edited comment on CAMP-80 at 8/20/13 2:25 PM:
-----------------------------------------------------------
I wasn't proposing "JSON means PDP, but YAML means DP". We specify two ways of registering apps (by reference or by value) and two things you can use (a PDP or a DP) to register an app. Blowing out the combinations we have:
1.) registering a PDP by reference - the example for this is:
POST /<platform-url> HTTP/1.1
Host: example.org
Content-Type: application/json
Content-Length: ...
{"pdpUri": "/paas/pdp/1"}
but there is no normative text saying that the Content-Type SHALL be "application/json". Note also that there is no way to tell the platform which of the three package formats (ZIP, TAR, or GZIP) the referenced PDP is. This is probably material for another issue.
2.) registering a DP by reference - the example for this is is the same as above, except s/pdpURI/dpURI/. The same issue exists w/regards to the Content-Type, but we don't have to worry about package format.
3.) registering a PDP by value - this is the only clear case, because we say that Content-Type SHALL be either "application/x-zip", "application/x-tar", or "application/x-tgz".
4.) registering a DP by value - this involves POSTing a YAML 1.1 document (which is *not* a superset of JSON) but we don't say what the Content-Type should be.
It seems to me that there are two questions here. The first is "should we use Content-Type as the sole signal of which of the four cases is being invoked?" If the answer to that is yes, then we simply have to work out which Content-Type corresponds to which case. Your concerns about "what if I wrote by DP as JSON?" aren't relevant since CAMP normatively references YAML 1.1 and YAML 1.1 is not a superset of JSON.
I think we can make this work if we use a combination of Content-Type and a smidge of content specific signalling:
1.) Signalled by a Content-Type of "application/json" and the presence of the "pdpURI" attribute in the JSON object. Package format discovery is TBD.
2.) Signalled by a Content-Type of "application/json" and the presence of the "dpURI" attribute in the JSON object. Referenced resource SHALL be a YAML 1.1 document that conforms to Section 4.3, "Deployment Plan Schema", of CAMP 1.1.
3.) Signalled by a Content-Type that is either "application/x-zip", "application/x-tar", or "application/x-tgz"
4.) Signalled by a Content-Type of "application/x-yaml".
was (Author: gilbert.pilz):
I wasn't proposing "JSON means PDP, but YAML means DP". We specify two ways of registering apps (by reference or by value) and two things you can use (a PDP or a DP) to register an app. Blowing out the combinations we have:
1.) registering a PDP by reference - the example for this is:
POST /<platform-url> HTTP/1.1
Host: example.org
Content-Type: application/json
Content-Length: ...
{"pdpUri": "/paas/pdp/1"}
but there is no normative text saying that the Content-Type SHALL be "application/json". Note also that there is no way to tell the platform which of the three package formats (ZIP, TAR, or GZIP) the referenced PDP is. This is probably material for another issue.
2.) registering a DP by reference - the example for this is is the same as above, except s/pdpURI/dpURI/. The same issue exists w/regards to the Content-Type, but we don't have to worry about package format.
3.) registering a PDP by value - this is the only clear case, because we say that Content-Type SHALL be either "application/x-zip", "application/x-tar", or "application/x-tgz".
4.) registering a DP by value - this involves POSTing a YAML 1.1 document (which is *not* a superset of JSON) but we don't say what the Content-Type should be.
It seems to me that there are two questions here. The first is "should we use Content-Type as the sole signal of which of the four cases is being invoked?" If the answer to that is yes, then we simply have to work out which Content-Type corresponds to which case. Your concerns about "what if I wrote by DP as JSON?" are relevant since CAMP normatively references YAML 1.1 and YAML 1.1 is not a superset of JSON.
I think we can make this work if we use a combination of Content-Type and a smidge of content specific signalling:
1.) Signalled by a Content-Type of "application/json" and the presence of the "pdpURI" attribute in the JSON object. Package format discovery is TBD.
2.) Signalled by a Content-Type of "application/json" and the presence of the "dpURI" attribute in the JSON object. Referenced resource SHALL be a YAML 1.1 document that conforms to Section 4.3, "Deployment Plan Schema", of CAMP 1.1.
3.) Signalled by a Content-Type that is either "application/x-zip", "application/x-tar", or "application/x-tgz"
4.) Signalled by a Content-Type of "application/x-yaml".
> Section 6.11 "Registering an Application" is unclear about what Content-Type header must be for various scenarios
> -----------------------------------------------------------------------------------------------------------------
>
> Key: CAMP-80
> URL: http://tools.oasis-open.org/issues/browse/CAMP-80
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Reporter: Gilbert Pilz
> Priority: Critical
>
> While implementing the code for Section 6.11 I noticed that there are a couple of scenarios in which the spec is unclear about the expected Content-Type of the POST request. The more minor of these is the case in which the Consumer POSTs a JSON object that contains the URI of the PDP or DP. Since the request is JSON, an implementer can infer that the Content-Type should be "application/json", but the spec should really be clear about this just to avoid any misunderstandings.
> The second, and more serious, case is when the Consumer directly POSTs the contents of a DP in the request body.
> This is important because, as defined in the spec, Content-Type is the only information an implementation has to figure out which of the four different methods a Consumer is attempting to use when they POST to the Platform resource.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]