On Nov 17, 2008, at 11:14 AM, Jonathan Rosenberg wrote:
We do not *NEED* to define what happens when INFO has multiple info
packages in it. If the syntax allows just one, and the spec allows
just one, there can only be one.
And I will reiterate that, this is a separate question from whether
an INFO can contain multipart, where one body is an INFO package
object and the other is for a different reason (AIB). We are
debating whether the INFO framework itself allows for multiple
packages per INFO.
But if there are multiple body parts (only one of which is an INFO
body) , INFO requires a mechanism for finding the right body part.
We can't delimit this based on the MIME type for the same reason we
can't just do a one-to-one map between INFO and MIME -- sometimes a
single MIME type is used in different ways for different applications.
So far, the only reasonable way proposed to identify the MIME body
associated with an INFO package is a MIME CID identifier that points
from the INFO package header to the body. According to this model,
INFO compliant UAs must understand multipart MIME (as the body
handling draft requires), and they must understand Content-ID.
If we have this mechanism, it works just as effectively and
automatically for multiple INFO bodies per message as it does for a
singular body per message.
We could probably say nothing about singular or multiple INFO package
bodies per INFO message in the draft, and nothing would change in the
mechanism at all:
1) Parse header
2) If current header is an Info package identifier, parse out the CID
3) Search through the bodies until you find the right CID
4) If there are more headers, go to step 1
One could probably complicate this by adding a state about "But if
you've already found one Info package header, ignore all subsequent
ones and their associated body parts", but that actually makes the
logic MORE complicated, not less.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
