First, I agree 100% with what Adam has said.
I just wanted to comment on one issue which is peripheral to the
discussion of INFO but is directly relevant to the issue of semantics of
sip messages in general.
Hadriel Kaplan wrote:
I agree with you, but that problem already exists today. There are plenty
of cases where there are constraints on the combination of method+mime that
cannot be described with Accept and Allow headers. There are devices which
won't accept Invites or re-Invites without application/sdp, and there are
devices which don't accept Options with mime types they do accept Invites
with, etc. (You can call them broken I guess) What does it mean for an
application/sdp mime body to be in a Message method, or in a Bye?
To the last question, it first depends on what the Content-Disposition
is. In spite of Gonzalo's draft on the subject, most people continue to
ignore this. But it really needs to be a key part of decision about the
semantics of message bodies.
If an application/sdp body has content-disposition of "session", and it
is in an INVITE, UPDATE, PRACK, or responses to those, then it is the
description of the session for this invite, subject to the offer/answer
rules.
Note that the *default* content-disposition for a body of type
application/sdp is "session" if it is found in one of the above
contexts. Otherwise the normal default disposition of "render" applies.
So an application/sdp body without a content-disposition in a MESSAGE
should be rendered. Of course there are issues of how or if it can be
rendered, but that is what it should mean.
If you put an application/sdp body in a MESSAGE and explicitly specified
a disposition of "session" then of course it shouldn't be rendered.
There is no defined meaning for a body with disposition of session in a
MESSAGE, so presumably it should be considered an error or ignored.
Paul
_______________________________________________
Sip mailing list https://www1.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
