[Sip] RE: draft-olson-sip-content-indirect-mech-00

["Sean Olson" <[e-mail]>]

I think we are saying the same thing... my intent is to send two
Content-Type:
headers. One says you are using message/external-body (content
indirection).
The other states the content type of the indirect content
(application/sdp, text/html,
whatever)
 
/sean

	-----Original Message-----
	From: Sriram Parameswar [mailto:[e-mail]] 
	Sent: Tuesday, July 09, 2002 11:41 AM
	To: Sean Olson
	Cc: [e-mail]
	Subject: RE: draft-olson-sip-content-indirect-mech-00
	
	
	Sean,
	 
	One more reason for pushing for the additional Content-Type is
Section 7.4.1 of RFC3261 says - "The Internet media type of the message
body MUST be given by the Content-Type header field." Otherwise how will
the UAS receiving the INVITE know how to parse the body? But maybe I
should wait till the MIME experts give us their verdict :)
	 
	Thanks,
	 
	Sriram

	__________________________________________ 
	Sriram Parameswar              Phone: [phone] 
	Interactive Multimedia Server (IMS) Fax: [phone] 
	Nortel Networks, Richardson USA  Email:
[e-mail] 

		-----Original Message-----
		From: Sean Olson [mailto:[e-mail]]
		Sent: Tuesday, July 09, 2002 1:30 PM
		To: Parameswar, Sriram [NGC:B615:EXCH]; [e-mail]
		Subject: RE: draft-olson-sip-content-indirect-mech-00
		
		
		If you are suggesting that we might want to indirectly
refer to 
		message/sipfrag or text/plain content, I completely
agree. The
		example you cite below is almost exactly what I have
proposed.
		I just happen to use application/sdp instead of
text/html as
		the (indirect) Content-Type:
		 
		thanks
		/sean

			-----Original Message-----
			From: Sriram Parameswar
[mailto:[e-mail]] 
			Sent: Tuesday, July 09, 2002 11:22 AM
			To: Sean Olson; [e-mail]
			Subject: RE:
draft-olson-sip-content-indirect-mech-00
			
			

			Thanks Sean - I would definitely like to hear
from the MIME experts - but here is an example from RFC 2017 section 3
which is more along what I suggested. I think we need to take a closer
look because the current draft does borrow heavily from RFC2017:

			<quote RFC2017> 
			    Content-type: message/external-body;
access-type=URL; 
			                  URL="http://www.foo.com/file" 

			    Content-type: text/html 
			    Content-Transfer-Encoding: binary 

			    THIS IS NOT REALLY THE BODY! 

			</quote RFC2017> 

			Regards, 

			Sriram 

			__________________________________________ 
			Sriram Parameswar              Phone:
972-685-8540 
			Interactive Multimedia Server (IMS) Fax:
972-684-3986 
			Nortel Networks, Richardson USA  Email:
[e-mail] 


			-----Original Message----- 
			From: Sean Olson
[mailto:[e-mail]] 
			Sent: Tuesday, July 09, 2002 12:38 PM 
			To: Parameswar, Sriram [NGC:B615:EXCH];
[e-mail] 
			Subject: RE:
draft-olson-sip-content-indirect-mech-00 


			Thanks for the comments! 

			I will try to dissect my original example to
explain what I was 
			shooting for. I've added line numbers, plus some
surrounding context 
			to hopefully make things a little clearer. 

			1   INVITE sip:[e-mail] SIP/2.0 
			2   Via: SIP/2.0/TCP
10.0.0.2;branch=z9hG4bK83749 
			3   From: <sip:[e-mail]>;tag=abcd 
			4   To: <sip:[e-mail]> 
			5   Call-ID: 1@10.0.0.2 
			6   CSeq: 2343 INVITE 
			7   Content-Type: message/external-body;
access-type="URL"; 
			8                 expiration="Mon, 24 June 2002
09:00:00 GMT"; 
			9
URL="http://www.bogus.com/the-indirect-content" 
			10  Content-Length: ... 
			11  <CRLF> 
			12  Content-Type: application/sdp 
			13  <CRLF> 


			Line 12 is the start of the payload for this
INVITE. 
			Lines 7-9 define the content type of this
payload (indirect content 
			          available at the given URL) 

			Line 12 gives the content type of the indirect
content. It is actually 
			        an entity header inside the payload (an
encapsulated entity) 

			Line 13 marks the end of the entity headers for
this encapsulated entity 
			        and also marks the end of the message 

			This is consistent with the example given in
section 5.2.3 of RFC2046. 
			I'm using MIME in the broadest sense defined in
RFC2045/2046 to allow 
			nesting or encapsulation of entities. This looks
a bit strange compared 
			to other SIP messages, but I believe it is
perfectly valid MIME. I 
			don't think we need to use message/sipfrag or
even text/plain to 
			accomplish 
			this -- the capability to express nested
entities and entity headers is 
			part of MIME. 
			I would be curious to hear from other MIME
experts on this issue to see 
			if I'm 
			abusing something here. 

			/sean 

			-----Original Message----- 
			From: Sriram Parameswar
[mailto:[e-mail]] 
			Sent: Sunday, July 07, 2002 6:35 PM 
			To: Sean Olson; '[e-mail]' 
			Subject:
draft-olson-sip-content-indirect-mech-00 


			Sean, 
			Well written draft!  In Section 3.6 'Specifying
the type of the indirect 
			content' - 
			it must be clearly noted that when including the
content-type of the 
			indirect content in the payload 
			- there must be Content headers specifying that
payload. Along with some 
			textual description added to section 3.6, 
			the example in that section will change to look
something like: 

			Content-Type: message/external-body;
access-type="URL"; expiration="Mon, 
			24 June 2002 09:00:00 GMT"; 
			URL="http://www.bogus.com/the-indirect-content" 
			Content-Type: text/plain 
			Content-Length: ... 
			<CRLF> 
			Content-Type: application/sdp 
			<CRLF> 

			You may also want to add a small section on how
this mechanism satisfies 
			the requirements laid down in the requirements
document 
			(draft-ietf-sipping-content-indirect-00). Just
as an after thought, the 
			additional Content-Type may also be
message/sipfrag instead of 
			text/plain. 

			Regards, 
			Sriram 
			__________________________________________ 
			Sriram Parameswar              Phone:
972-685-8540 
			Interactive Multimedia Server (IMS) Fax:
972-684-3986 
			Nortel Networks, Richardson USA  Email:
[e-mail]