Re: [Sip] content indirection design question

[Dean Willis <[e-mail]>]

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";                 
> 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-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
>
> 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
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
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip