RE: draft-gregorio-atompub-multipart-02

["Brian Smith" <brian@xxxxxxxxxxxxxx>]

Joe Gregorio wrote:
> How about:
> 
> """
> A successful POST of a multipart/related representation to a 
> Media Collection proceeds as any successful Media Resource 
> creation. The root object is used to create the Media Link 
> Entry and the other body part is used to create the Media Resource.
> """

Seems fine to me.

> > I would an example to be added that shows how this mechanism can be 
> > used to add an Atom document to a collection as a media resource.
> 
> -1 This is an edge case, and while the spec covers this edge 
> case I don't think
>    it merits an example.

Good specifications cover the edge cases too. It is important to give this
some explicit coverage so that implementers realize that they can't just set
alternate='multipart-related' on every <app:accept> element blindly; usually
they will want to skip it on <accept>application/atom+xml</accept>. The
current draft doesn't have an example with
<accept>application/atom+xml</accept> at all.

This edge case is also important because it provides a way to post a feed
document to a collection in a well-defined manner. RFC 5023 leaves the
results of posting a feed document directly to the collection undefined.
That is an important feature for any AtomPub implementation that is doing
WebDAV-like document storage.

> Since the media you post is supposed to show up in the 
> content/@src of the created MLE I would not expect an 
> app:accept of multipart/related to appear at all.

If you want to leave this case unspecified then that is fine with me. I do
think the 4287 restriction needs to be relaxed or worked around in some way
but this isn't the place for it.

> > I don't like the design of the "alternate" attribute; I prefer the 
> > initial submission's multipart="yes".
> 
> And multiple people objected to the boolean attribute.
> 
> Proposals for a method of markup up the support for 
> multpart/related that isn't boolean and isn't a space 
> separated list of tokens is welcome.

I don't have any proposal for this that is better than your first draft.

Regards,
Brian