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

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

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: [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 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: [phone] 
	Interactive Multimedia Server (IMS) Fax: [phone] 
	Nortel Networks, Richardson USA  Email:
[e-mail]