[Sip] content indirection design question

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.