Subject: [Sipping] draft-olson-sipping-content-indirect-00.txt

From: Sean Olson <[email-masked]>
Date: Fri, 5 Apr 2002 17:34:10 -0800 (PST)

FYI. I've put together a draft of requirements
for a mechanism to allow content indirection
(an indirect reference to content that would normally
be carried directly in the SIP payload)

http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

/sean

=====
Sean Olson <[email-masked]>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Apr 2002 10:10:04 -0400

Sean - comment below.

	Paul

> http://www.ietf.org/internet-drafts/draft-olson-sipping-content-indirect-00.txt

What is the purpose of REQ-2? 

Since this proposal is about content indirection, it seems like the purpose of the content should be unchanged whether it is indirected or not. Whatever mechanism there is
out to apply equally whether the content is direct or indirect. The Content-Disposition header already serves this purpose.

Perhaps you are trying to say that it should be possible to use several URLs as an alternative to several parts in a multipart-MIME body, and that you want an ability
equivalent to specifying a separate Content-Disposition header for each. That seems reasonable.

But if you are suggesting a need for more forms of disposition than are currently covered by Content-Disposition, then I think that should be handled in a way independent
of content indirection.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Mon, 8 Apr 2002 09:42:05 -0700 (PDT)

> 
> Perhaps you are trying to say that it should be
> possible to use several URLs as an alternative to
> several parts in a multipart-MIME body, and that you
> want an ability
> equivalent to specifying a separate
> Content-Disposition header for each. That seems
> reasonable.

Exactly. I will make this explicit.

> 
> But if you are suggesting a need for more forms of
> disposition than are currently covered by
> Content-Disposition, then I think that should be
> handled in a way independent
> of content indirection.

I think Content-Disposition could be easily
extended to accommodate what I have in mind.
I will leave those details to a draft that 
proposes an implementation of these requirements.

> 	Paul

Thanks for the comments.
/sean