If there is a single body, then the body part of the INFO is for the one
and only package. If there are multiple bodies, one would be for the
INFO package, and the rest for something else. I am fine with a cid in
this case. But there is STILL just one info package per INFO message,
and the only reason for multipart would be reasons having nothing to do
with INFO framework.
-Jonathan R.
Eric Burger wrote:
It is not a theory. Once you have to explicitly identify the body part
for an Info Package, you can identify the body part for ANY Info Package.
Can you propose a simpler way to unambiguously identify the body part
with a mechanism other than Content-ID? That will help me see a way how
one would have to add work to handle multiple body parts, as demanded by
RFC 3261.
On Nov 17, 2008, at 11:14 AM, Jonathan Rosenberg wrote:
Eric Burger wrote:
SUBSCRIBE/NOTIFY didn't specify it because (1) the Event: header as
specifies ensures only a single payload and (2) implementations may
find themselves hopelessly broken when a legal, RFC 3261, multipart
payload shows up.
INFO has to specify it so we do not barf.
This is bogus.
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.
Less is more. We don't need more features just because they are 'free'
from a hypothetical standards perspective. This argument is also bogus.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
--
Jonathan D. Rosenberg, Ph.D. 111 Wood Avenue South
Cisco Fellow Iselin, NJ 08830
Cisco, Voice Technology Group
[EMAIL PROTECTED]
http://www.jdrosen.net PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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
