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

From: "Sriram Parameswar" <[email-masked]>
Date: Tue, 9 Jul 2002 13:21:31 -0500

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: [email-masked]

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: Tuesday, July 09, 2002 12:38 PM
To: Parameswar, Sriram [NGC:B615:EXCH]; [email-masked]
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:[email-masked] SIP/2.0
2   Via: SIP/2.0/TCP 10.0.0.2;branch=z9hG4bK83749
3   From: <sip:[email-masked]>;tag=abcd
4   To: <sip:[email-masked]>
5   Call-ID: [email-masked]
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:[email-masked]] 
Sent: Sunday, July 07, 2002 6:35 PM
To: Sean Olson; [email-masked]'
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: [email-masked]