OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [camp] Issue 3: proposal direction with two choices

Hi Anish-

What I'm suggesting is to try to avoid making the clients have to do multipart as it is irritating.

Can we support registering through a simple POST whose body is a YAML DP or a ZIP/TAR PDP ? This way a user could write a simple curl to register a DP (and same in JS, CLI tools, etc).

I lean towards _also_ requiring support for multipart/related on the server. However not sure the "pdpUri" attribute is a necessary level of indirection. Particularly if within the DP we support imports to other DP's -- we don't yet, but we have said we would. Assume we had an "import: <href>": The first item in the multipart can be a DP YAML which says "import: cid:item2" then "item2" in the
mutlipart might be another YAML DP or a ZIP/TAR PDP.

Make sense?

> you need ... another part that tells the platform what to do with the PDP (in this case, register).

Maybe this is the confusion. I'm assuming the "register" action is implicit, so we need only supply the PDP.
Is there a reason we can't do this?


On 14/05/2013 14:03, Anish Karmarkar wrote:
On 5/9/13 12:26 PM, Alex Heneveld wrote:

Hi Anish-

Glad you updated CAMP-3 with this link.  Somehow I missed it first time
round!  Obviously it raises a question about my draft proposal for

Q: What are the benefits of "pdpUri: cid:XXX" multi-part versus my
suggestion of a single part and is it worth the overhead? *

I don't know how it could be done with a single part without sacrificing requirements (at least as I see them). The problem I'm trying to solve is: I have a PDP (whatever form it takes) and I want to register that PDP by-value.

The current draft already support registering a PDP by-reference.
To support by-value, you need one part that contains the PDP and another part that tells the platform what to do with the PDP (in this case, register).

To attempt an answer I think it makes it easier for javascript to upload
as it won't have to build ZIPs on the fly.  That's pretty compelling.
But _requiring_ multipart from the client can also be tedious so my vote
would be to require a platform to support EITHER a single part post
which is interpreted as I described, or a multipart post where the first
part is either the map containing { pdpUri: cid:XXX }, in YAML format
(so allowing JSON), or possibly the pdp itself.  (I think I prefer the
latter unless there is a good reason for the former?)

Not sure I understand what you are proposing, but my proposal does provide a map along with the PDP.

Having the deployment plan also support cid: is nice as then artifacts
could be part of the same multi-part.

Perhaps you can explain this on the call, as I'm not sure what you mean.
Are you suggesting that PDP be a MIME format (instead of zip or tar)?

* = also have we settled on how we treat abbreviations in camel case?  i
prefer pdpUri to pdpURI (otherwise you risk getting HTTPRESTAPI !)

Agree, we should be consistent and settle on one.


You also raised ...

Q:  multipart/form-data vs multipart/related

I'm not sure.  Will have to investigate, but not now as I'll miss my
flight!  :O
You've probably chosen the right answer already of course.


On 01/05/2013 01:49, Anish Karmarkar wrote:


I have had a long standing AI to provide a proposal for issue 3 [1].

In the past we have talked about (in this TC as well as in the
collaboration) allowing clients to POST to the platform endpoint to
upload a PDP. Subsequently, we have talked about allowing clients to
include a PDP in their register request (see section 6.11 in WD09 [2]).

If we are going to allow clients to include PDP in their register request:
1) we (the spec) would have a well-defined interoperable way to upload
and register a PDP, and
2) we can stay silent on how the platform does management of
repositories/content. A platform can choose to allow someone to upload
a PDP or manage a platform administered repository, allow for git
push, partial updates etc -- this would be a platform specific
extension. Given all the various ways a platform can manage this, best
to stay silent.

If you agree to the following, I would like to propose the following
as a directional resolution for issue 3.

      Proposal (Directional)

Section 6.11 currently allows one to POST a JSON message:
{"pdp_uri" : "<uri-of-the-pdp>"}

to the platform URI and get back a Location URI for the newly created

This section would be modified to allow for the client to send a
multipart MIME message, the root part of which would contain the same
JSON message as before, but the URI would be a "cid:" uri [3]. This
cid uri would point to another MIME part in the same POST message that
contains the PDP. For example:

MIME-Version: 1.0
Content-Type: ... ;boundary=MIME_boundary;

Content-Type: application/json
Content-ID: <123456@example.org>

{"pdp_uri" : "cid:abcdef@example.org"}

Content-Type: application/zip
Content-Transfer-Encoding: binary
Content-ID: <abdcef@example.org>

// binary octets for zip


The advantage of keeping the same root part as before (in section
6.11) is: it will always be processed the same way. *Where* the PDP is
located obviously changes, based on the URI scheme. Furthermore, if we
decide to allow parametrization of register operations (which we
should, but that is a different issue) then again the expression and
processing of those parameters remain the same regardless of whether
the PDP is provided by value (in the POST request entity-body) or by
reference (eg, a http URL).

      Open Issue

What should the content-type of the multipart message be?
There are two possible options: multipart/form-data [4] or
multipart/related [5].

          1. multipart/form-data

This is very HTML friendly and supported by most browsers. The CAMP
platform can provide such an HTML. The message would look like this --

MIME-Version: 1.0
Content-Type: multipart/form-data; boundary=----MIME_boundary

Content-Disposition: form-data; name="pdp_uri"


Content-Disposition: form-data; name="pdp"; filename="pdp.zip"
Content-ID: <abdcef@example.org>
Content-Type: application/zip

//binary octet for zip


If we decide to go with this, then it would make sense to use the
media-type x-www-form-urlencoded for the case where the PDP is
provided by reference (the current method in section 6.11). There are
two disadvantages of this approach: (1) the POSTed root part is not
JSON, and (2) if we allow for parametrization all the parameter would
also not be JSON (or will be URL-encoded JSON).

          2. multipart/related

This allows us to reuse existing serialization/representation for the
root part as well as any parameters (if we decide to allow that). The
message would like this --

MIME-Version: 1.0
Content-Type: multipart/related;boundary=MIME_boundary;

Content-Type: application/json
Content-ID: <123456@example.org>

{"pdp_uri" : "cid:abcdef@example.org"}

Content-Type: application/zip
Content-Transfer-Encoding: binary
Content-ID: <abdcef@example.org>

// binary octets for zip


I prefer multipart related. What do others think? Is there a more
appropriate media-type to use?

Furthermore, if we decide to go with this proposal, I would like to
suggest that we add another optional, immutable attribute to the
AssemblyTemplate: pdpURI. This would point to the URI from which the
template was created. This would allow for things such as discovery,
cloning, registering the same PDP multiple times (perhaps with
different customization), and debugging.



[1] https://tools.oasis-open.org/issues/browse/CAMP-3
[3] http://www.ietf.org/rfc/rfc2392.txt
[4] http://tools.ietf.org/html/rfc2388
[5] http://tools.ietf.org/html/rfc2387

To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]