Re: AtomPub Multipart Open Issues

[Aristotle Pagaltzis <pagaltzis@xxxxxx>]

* Joe Gregorio <joe@xxxxxxxxxxxxxx> [2008-07-01 21:30]:
> 1. The format should use multipart/related ordering and the MLE
>    MUST be the root part.
> 2. The MLE MUST be constructed with an
>    atom:content/src="cid:..." and that cid: URI MUST point to
>    the included media.
> 2.1. A normative reference to cid: URI spec needs to be added.
> 3. Change multipart="yes" to be a non-boolean indicator, such
>    as post-options="multipart".
> 
> Presuming I haven't missed anything, I will come back in a bit
> with camera ready copy proposals.

+1

* Joe Gregorio <joe@xxxxxxxxxxxxxx> [2008-07-02 20:40]:
> On Wed, Jul 2, 2008 at 4:52 AM, Sylvain Hellegouarch <sh@xxxxxxxxxx> wrote:
> > I have to agree with Bill. "related" is only one use of the
> > multipart subtypes. Joe, rather than
> > post-options="multipart", why not using
> > multipart="related|form-data|alternative|...".
> 
> That works for me. I would suggest one small change and allow a
> space separated list of options but have the current spec only
> define "related" and that the attribute is a space separated
> list of values without defining any of the other values.

+1

* Brian Smith <brian@xxxxxxxxxxxxxx> [2008-07-01 23:40]:
> It would be best to define what happens when content/@src
> references in the root part references another part, without
> explicitly excluding further extensions that use more than two
> parts and/or put the cid: link in a different place (like the
> example I mentioned earlier, <link rel='photo'
> href='cid:....'/>).

+1

However, …

> In other words, don't restrict the kinds of multipart/related
> messages the client can send. Instead, say that when a client
> sends a multipart/related message with an atom entry as the
> root, where that entry's atom:content/@src is a cid: link
> referencing the Content-ID of another part of the message, then
> the server MUST process the message using this mechanism. Then
> say that the server MAY (not MUST) reject all multipart/related
> messages that don't meet those conditions.

… we don’t have a lot of MUSTs for servers in RFC 5023 and we
shouldn’t start adding them in extensions.

I think we should continue to follow the same approach as we have
always taken before: describe what the bits mean and avoid
prescribing what to do with them (in normative language anyway).

That would inherently take care of the problem of compatibility
with other extensions, because it would mean that the only thing
that is specified is what the client intends when it sends an
entity in a request that takes a particular form, but doesn’t say
what the client might mean in cases when the entity it sends has
some other, related form.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>