Re: [media-types] (No subject)

[Rahul Gupta <[e-mail]>]

Hi Alexey,

Thank you for your comments.

I had been very careful in stating in the draft that if the `content-type` header is follows the pattern defined in RFC2046 ie `multipart/something` followed by the "boundary "parameter, it will continue to be processed as before. Only when a "boundary" is not defined and "no-boundary" is defined, (ie a `content-type` header that is considered illegal by RFC2046 and when multipart message is not to be processed as of today) will the new standard kick-in. Therefore, I do not see how any existing implementation will break. What am I missing?

Like I said in my response to Harald, I am open to the possibility of defining a new media type, but want to explore first if I can get away with modifying "multipart".

BR/Rahul



Sent with Proton Mail secure email.

On Sunday, March 17th, 2024 at 6:30 AM, Alexey Melnikov <[e-mail]> wrote:

> Hi Rahul,
> 

> I would add to what Harald wrote:
> 

> The top level multipart media types are syntactically required to have the boundary parameter. You can’t change that without changing how multipart is defined and this will break multiple (all?) currently compliant implementations.
> 

> What you can do instead, is to define a new top level media type that uses different framing/ways to delimit subparts.
> 

> Best Regards,
> Alexey
> 

> > On 17 Mar 2024, at 10:08, Harald Alvestrand [e-mail] wrote:
> > 

> > Thanks for your submission!
> > 

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

> > 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.
> > 

> > 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.
> > 

> > > 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
> > 

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

> 

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