Subject: RE: [Simple] Re: Draft-campbell-simple-im-session-01: Head of Li ne Blocking

From: Adam Roach <[email-masked]>
Date: Tue, 22 Apr 2003 12:36:22 -0500

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]

> I like the solutions you have where I can allocate a buffer, 
> start filling
> it  and when it gets full, back patch the size into some 
> blank space I left
> of the size then send the buffer. However, keep in mind what 
> it looks like
> when I am doing S/MIME at the same time.

For encrypting, you'll just need to maintain a temporary buffer
that you're filling, and then encrypt into the send buffer.
I don't see any way around this. (For signing, it's quite a bit
easier).

> > 2) Limit message sizes. Fail anything larger than an
> >   administratively-determined limit.
> Reasonable - though now would be nice if the relays could 
> tell this MTU to
> clients.

Yep. Could be a header returned in the response to BIND
and VISIT. Of course, this still makes getting an end-to-end
MTU difficult in the two relay case.

> > 3) Chunk the messages in MIME. The use of message/partial
> >   (or, if the semantics are judged to be too different,
> >   "message/msrp-partial") would allow sending UAs to split
> >   messages into reasonable sizes (either negotiated or
> >   protocol-mandated).
> Since we are doing MIME anyways ideas on this path are 
> appealing. Could you
> do it a way where the Relay could actually split something up 
> into smaller
> size chunks that the client sent?

If we follow the message/partial model, yes. RFC 2046 discusses
this:

   Because some message transfer agents may choose to automatically
   fragment large messages, and because such agents may use very
   different fragmentation thresholds, it is possible that the pieces of
   a partial message, upon reassembly, may prove themselves to comprise
   a partial message.  This is explicitly permitted.

Note that, upon reassembly, the top-level MIME type can still be
e.g. multipart/signed -- so S/MIME properties are preserved.

> > 4) Chunk the messages in MSRP. This could work similar to the
> >   BDAT SMTP command described in RFC 3030, but with an added
> >   "Message-ID" to correlate parts. e.g.:
> This might be workable too - again - could the Relay re-chunk 
> something into
> smaller chunks. 

I don't see any technical hurdles to a relay doing so.

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 22 Apr 2003 15:28:24 -0500

First, a comment on this discussion in general: I see a use for message
chunking, but I _really_ don't want to block this specification on it
any more than absolutely necessary to make sure we can add such
functions later.

That being said, if we went with the message/partial approach (which I
admit not being an expert on) how much would we have to say about it in
this specification?

Additionally, would it be useful to add an error response code
indicating "message too large" that contains a size limit value?

> MTU difficult in the two relay case.

While less efficient, a message-too-large response code would seem to
more easily discover full path policy.

> e.g. multipart/signed -- so S/MIME properties are preserved.

I find myself really liking this approach.

> I don't see any technical hurdles to a relay doing so.

Do you see any really benefit in re-inventing this in MSRP, if it
already exists for MIME in general?