Re: [media-types] Multipart without boundaries

[Rahul Gupta <[e-mail]>]

Hi Harald,

I must admit this is a bit of a Hail Mary! 


But the problem itself is well outlined in the draft, even if the answer might be something different. Coming to you all is so that you can help me figure out that answer.

Please see specific comments interleaved...

On Sunday, March 17th, 2024 at 5:38 AM, Harald Alvestrand <[e-mail]> wrote:

> Thanks for your submission!
> 

> The definition of new media types is outside of the charter of MEDIAMAN,
> though.

This is to answer to both Harald and Alexey,

I came to MEDIAMAN because I think I am updating an existing (ancient?) media-type.

I am open to the possibility of defining a "manypart" top level media-type but felt that it would be easier to reuse most of the existing "multipart" standard. But I would like to benefit from your knowledge of this group even in the case I end up defining a "manypart".

> 

> Personally, I think that using "content-length:" for generic multipart
> content is likely to be a design mistake - there's too much processing
> that subtly alters the length of the message. It would only be
> dependable if you were to pair it with a message checksumming mechanism
> such as Content-MD5 so that content modifications could be detected -
> and it would still not allow you to reconstruct the original message if
> the signature was broken by a transform.

Just want to make sure that it is clear that "Content-Length" is defined for each Part and not for the Multipart (since "message" could be mean either). And I have added a condition saying that "Content-Length" on Parts are otherwise interpreted as per RFC9110.

> 

> Content delimiting is a subject with long traditions - the "chunked"
> content-transfer-encoding and the delimiting of message bodies in
> HTTP/1.1 are just two of the areas in which it has been approached.
> 

The representation body will still to have `Transfer-Encoding: chunked` to say that the body is not delimited in advance. And then my intention is delimit each part with "Content-Length". Is there something specific in this tradition you would like me to look at.


> 

> On 3/15/24 10:18, Rahul Gupta wrote:
> 

> > Hello Media-type enthusiasts,
> > 

> > I am proposing a new Internet-Draft "Multipart without Boundaries".
> > https://cxres.github.io/multipart-without-boundaries/draft-gupta-mediaman-multipart-without-boundaries.html
> > 

> > Like the title says, it proposes a new syntax that uses `Content-Length` in each part and thus does not use boundary delimiter to separate encapsulated parts. As explained in the draft, this solves an outstanding issue when parts are dynamically generated (and generally simplifies parsing), especially when used in notification protocols (It is inspired from Braid's subscription response, but respects existing HTTP content-type conventions).
> > 

> > One issue that I faced while writing this draft is that I could not find a IANA registration for the "boundary" parameter for "multipart" media-type in any of the registries. So I am not sure of what instructions to give to IANA for the "no-boundary" parameter.
> > 

> > This is a tiny draft that solves a very specific and limited issue. I know that I am too late for I-D submission and publishing it almost on the eve of the Brisbane round, but I would still appreciate it if the Chair could please sneak it in at least as an announcement (or 5 minute discussion) in the Mediaman session.
> > 

> > Thanks in advance,
> > 

> > Best Regards,
> > Rahul
> > 

> > _______________________________________________
> > media-types mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/media-types

BR/Rahul