[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AtomPub Multipart Open Issues
>
> Joe Gregorio wrote:
>> From the discussion so far I see the following issues that are as yet
>> unchanged in the spec and I believe need to be resolved:
>>
>> 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.
>>
>> 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.
>
> I was more thinking of the specification using up "multipart" not
> "multipart/related". I can easily imagine form-data being an option in
> the future.
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 convention would at least allow for compatibility with future
extensions that would like to deal with other MIME subtypes. Interestingly
your draft could be duplicated almost as-is to support "mixed" and
"alternative".
- Sylvain
--
Sylvain Hellegouarch
http://www.defuze.org