On Nov 16, 2008, at 11:35 PM, Jonathan Rosenberg wrote:
* I know we've discussed this one, but I disagree that the event
packages HAVE to be specification required. I think we should allow
for
vendor prorpietary usage. My suggestion is to define a vendor tree for
info event packages.
I'd be okay with this.
Because there are numerous situations where a SIP method request can
carry a payload, any INFO method may contain body parts in addition
to the payload associated with the Info Package.
hmm, why? This complicates things. KISS.
Because an SIP request can carry AIB or e2m (or other such extension,
like SAML assertions)) body parts, there is the possibility that an
INFO might also get such attachments. We can't stop this without
deprecating the behavior of those specifications. We must therefore be
prepared to determine which body part(s) is(are) associated with the
INFO package, and which are something else.
Can we do this based only on the MIME body type? Yes, in the cases we
know about so far. Do we have a way to assure this given the
probability of future specs
9.5. Creation of the Info Packages Registry
You should show an example of what the actual table in the IANA
registry looks like and include the 'nil' there.
There are no specific security issues for this mechanism, beyond
those already applicable to SIP-based session signaling. In
particular, if one does not protect the SIP signaling from
eavesdropping or authentication and repudiation attacks, for
example
by using TLS transport,
I disagree with this statement. There are new considerations here -
we're now exchanging APPLICATION data in SIP, and this increases
sensitivity of the data depending on the application. For example
considering using INFO to send typical form-data, like a credit card
number....
And I assure you, the IESG will notice this weakness. We do need to
beef this discussion up.
--
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
