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


On 5/14/13 6:33 AM, Alex Heneveld wrote:

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 ?

Interesting that you bring this up. That was exactly my proposal many many moons ago: A simple POST with the PDP as the only content of the HTTP request entity body to the Platform entry point URL would result in the PDP being "made available" to the platform. The HTTP response would then contain the "Location" header that provides the URI for the PDP. Subsequently one can then register the PDP (possibly multiple times) using the existing method in the current draft. I still prefer this way of doing things. I'll send an email with that proposal again and link it in JIRA as an alternate proposal.

This way a user could write a simple curl to register a DP (and same in
JS, CLI tools, etc).


I agree this is a simpler way.

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.


If we accept the alternate way of uploading a PDP as mentioned above. I would say that this becomes a separate issue of how to enable registering a PDP with an 'aggregation' method. We can decide to support that by allowing a POST that just contains just the DP (which in turn contains pointers to other artifacts) OR leave that as an extensibility exercise.

-Anish
--

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?

--A


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
CAMP-65...

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.

-Anish
--


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.


Best
Alex


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


      Preamble

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
AssemblyTemplate.

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;

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

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

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

// binary octets for zip

--MIME_boundary--


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

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

cid:abcdef@example.org

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

//binary octet for zip

------MIME_Boundary

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;
    type="application/json";
    start="<123456@example.org>";

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

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

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

// binary octets for zip

--MIME_boundary--

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.

Thanks.

-Anish
--

[1] https://tools.oasis-open.org/issues/browse/CAMP-3
[2]
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/49008/camp-spec-v1.1-wd09.doc

[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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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