RE: AtomPub Multipart Open Issues

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Joe Gregorio wrote:
> Presuming I haven't missed anything, I will come back in a 
> bit with camera ready copy proposals.

> With respect to the issue of this specification 'using up' 
> the multipart/related media type, I believe that if later 
> specifications come along that also want to use 
> multipart/related in a different manner then those follow-on 
> specifications can add a new parameter to the 
> multipart/related media-type to distinguish it from this 
> specifications usage.

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:....'/>).

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.

In particular, I think that a very similar mechanism like this could be used
for one-step creation of entries with enclosures (link rel='enclosure' with
inline content).

Regards,
Brian