Subject: [Sip] Offer/Counter-offer/answer changes.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 28 Aug 2001 22:05:10 -0700

Okay let's see if this old trick can solicit some comment :)

I propose the following text is added to the next RFC2543bis document to
describe the important offer/counter-offer/answer model. The changed text is
marked. [Note no changes are required to Appendix B.]

10.15 Content-Disposition

        Content-Disposition   =  "Content-Disposition" ":"
                                 disposition-type *( ";" disposition-param )
        disposition-type      =  "render" | "session" | "icon" | "alert" |
"newsession"
	
^^^^^^^^^^^^^^
                             |   disp-extension-token
        disposition-param     =  "handling" "="
                                 ( "optional" | "required" | other-handling
)
                             |   generic-param
        other-handling        =  token
        disp-extension-token  =  token

   The Content-Disposition header field describes how the message body
   or, in the case of multipart messages, a message body part is to be
   interpreted by the UAC or UAS. The SIP header extends the MIME
   Content-Type (RFC 1806 [33]).

   The value "session" indicates that the body part describes a session,
   for either calls or early (pre-call) media. The value "render"
   indicates that the body part should be displayed or otherwise
   rendered to the user. For backward-compatibility, if the Content-
   Disposition header is not missing, bodies of Content-Type
				 ^^^ I don't think the "not" is supposed to
be here
   application/sdp imply the disposition "session", while other content
   types imply "render".

*   The value "newsession" indicates that the message body describes a 
*   session, however, it indicates that this message body is start of a new 
*   session content negotiation. The "newsession" value may only be
*   used in INVITE 200 OK responses (and provisional INVITE responses if 
*   explicitly allowed by extensions) when the original INVITE request
contained a 
*   message body of "session" disposition type. As such, the "newsession"
value
*   means that the message body in the INVITE request is ignored. For 
*   Content-Type application/sdp this means that the 200 OK contains a
*   new SDP offer and that the ACK must contain an SDP answer. There does
not need
*   to be any correlation between the "newsession" message body and the
message
*   body in the original INVITE. The "newsession" value should always be
used with 
*   the "handling=required" disposition parameter. If a UAC is unwilling or 
*   unable to use the "newsession" message body it should simply treat the 
*   message body as invalid.

   The disposition type "icon" indicates that the body part contains an
   image suitable as an iconic representation of the caller or callee.
   The value "alert" indicates that the body part contains information,
   such as an audio clip, that should be rendered instead of ring tone.

   The handling parameter, handling-parm, describes how the UAS should
   react if it receives a message body whose content type or disposition
   type it does not understand. If the parameter has the value
   "optional", the UAS MUST ignore the message body; if it has the value
   "required", the UAS MUST return 415 (Unsupported Media Type).  If the
   handling parameter is missing, the value "required" is to be assumed.

   If this header field is missing, the MIME type determines the default
   content disposition. If there is none, "render" is assumed.
   ^^^^^^ isn't this paragraph repeating what was said in 2nd paragraph

Comments?

Robert.

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip