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

["Sriram Parameswar" <[e-mail]>]

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 <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]
<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
<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]
<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
<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]