Subject: [Sip] content indirection design question

From: "Nasir Khan" <[email-masked]>
Date: Fri, 24 Feb 2006 14:09:09 -0800

I have this question for the designers of
http://www.ietf.org/internet-drafts/draft-ietf-sip-content-indirect-mech
-05.txt
The way the meta data about the indirect content is split between
message and body is counter-intuitive. 
 
Eg. 
-----------------------------Actual-------------------------
                        Content-Type: message/external-body;
access-type="URL";
                expiration="Mon, 24 June 2002 09:00:00 GMT";
                URL=http://www.example.com/the-indirect-content
            Content-Length : 234
            <CRLF>
            Content-Type: image/jpeg
            Content-Disposition: render
---------------------------------
 
The Content-Type header indicates that this is an indirect content and
also contains the pointer to the actual content, it contains a lot of
other information about the content and then there is a Content-Length
that is not the length of the actual content but the length of the
content attributes that appear as Content headers in the body of this
message, which contains some further information about the content. 
This type of semantic overloading and distribution has not been seen in
most of the SIP design that I am aware of so far, what were the reasons
for this design decision? 
 
You could have defined a simple protocol (which you have done
indirectly) which is transported in the message body much like SDP and
defines the content as indirect content, as an example ..
 
Eg. 
------------------------Suggested---------------------------------------
----
Content-Type: application/indirect-content
Content-Length: 563
<CRLF>
Indirect-Content-Param: URL;expiration="Mon, 24 June 2002 09:00:00 GMT"
Indirect-Content:  http://www.example.com/the-indirect-content
Indirect-Content-Type: image/jpeg
Indirect-Content-Length : 234532
Indirect-Content-Description : Happy fish image
......etc etc.  

------------------------------------------------------------------------
----------

OR alternatively

You could have extended SIP by adding these headers (Indirect-XXX)
headers in this draft to describe the indirect content and left the body
empty. 

Any of these approaches simplify the UA implementation, particularly in
approach-1 that I describe above, I could have used a factory generated
pluggable content protocol handler which is delegated to deal with the
content it specializes in, selectable by Content-Type header alone which
just reads the body of the message after <CRLF>, where it finds
everything it needs. 

Thanks

~Nasir    

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________
Sip mailing list  https://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

---

From: Dean Willis <[email-masked]>
Date: Fri, 24 Feb 2006 16:26:03 -0600

On Feb 24, 2006, at 4:09 PM, Nasir Khan wrote:

> I have this question for the designers of http://www.ietf.org/ 
> internet-drafts/draft-ietf-sip-content-indirect-mech-05.txtThe way  
> the meta data about the indirect content is split between message  
> and body is counter-intuitive.  Eg. ----------------------------- 
> Actual-------------------------                        Content- 
> Type: message/external-body; access-type="URL";                 
> URL=http://www.example.com/the-indirect-content            Content- 
> Length : 234            <CRLF>            Content-Type: image/ 
> jpeg            Content-Disposition:  
> render--------------------------------- The Content-Type header  
> indicates that this is an indirect content and also contains the  
> pointer to the actual content, it contains a lot of other  
> information about the content and then there is a Content-Length  
> content attributes that appear as Content headers in the body of  
> this message, which contains some further information about the  
> content. This type of semantic overloading and distribution has not  
> been seen in most of the SIP design that I am aware of so far, what  
> were the reasons for this design decision?  You could have defined  
> a simple protocol (which you have done indirectly) which is  
> transported in the message body much like SDP and defines the  
> content as indirect content, as an example .. Eg.  
> ------------------------ 
> Suggested-------------------------------------------Content-Type:  
> application/indirect-contentContent-Length: 563<CRLF>Indirect- 
> Content-Param: URL;expiration="Mon, 24 June 2002 09:00:00  
> GMT"Indirect-Content:  http://www.example.com/the-indirect- 
> contentIndirect-Content-Type: image/jpegIndirect-Content-Length :  
> 234532Indirect-Content-Description : Happy fish image……etc etc.
> ---------------------------------------------------------------------- 
> ------------
>
>
>
> OR alternatively
>
> headers in this draft to describe the indirect content and left the  
> body empty.
>
>
>
> Any of these approaches simplify the UA implementation,  
> particularly in approach-1 that I describe above, I could have used  
> a factory generated pluggable content protocol handler which is  
> delegated to deal with the content it specializes in, selectable by  
> Content-Type header alone which just reads the body of the message  
> after <CRLF>, where it finds
Interesting email format, seems to be devoid of newlines.

The history is like this: MIME had already defined message/external- 
body (RFC 2017) and its semantics. This approach was used in ietf- 
announce email for years, and I believe was still being used at the  
time SIP content indirection was introduced. In the usual IETF  
tradition, we re-used it rather than inventing yet another MIME type.  
Generality over simplicity, and all that.

Besides, this was what the MIME people told us to do.

--
Dean