Subject: Re: [Sipping] I-D ACTION:draft-ietf-sipping-content-indirect-02.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 09 Oct 2002 02:32:03 -0400

Sean,

I had posted a few additional requirements on the list that I didn't see
incorporated:

 > Another few points:
 >
 > There is no requirement listed that the indirection indicate the
 > length of the content. I think that this requirement is critical. Its
 > needed for features like automatic download when the size is under
 > some threshold.
 >
 > Similarly, there is no requirement listed that the indirection
 > indicate the type of the content. I think thats even more critical
 > than the length.

One comment on the security consideratiosn section. I think you need to 
take the requirement listed there (integrity/privacy SHOULD be applied 
to indirection URI), and move it up into the actual requirements 
section. Then, the security section would say that this requirement 
addresses the threats outlined above.

There are some other security requirements worth considering. Is it a 
requirement, for example, that "it should be possible for the content of 
the URI to only be obtained from the recipient of the indirection"?

-Jonathan R.

Sean Olson wrote:
 > I've put together a revision of the requirements draft based on
 > comments received from the list. Please review the revised
 > requirements, particularly the new Security Considerations section
 > which probably needs additional work before WGLC.
 >
 > Cheers, Sean Olson Microsoft
 >
 > -----Original Message----- From: [email-masked]
 > [mailto:[email-masked]] On Behalf Of [email-masked]
 >  Sent: Wednesday, September 25, 2002 4:59 AM To: IETF-Announce: Cc:
 > [email-masked] Subject: [Sipping] I-D
 > ACTION:draft-ietf-sipping-content-indirect-02.txt
 >
 >
 > A New Internet-Draft is available from the on-line Internet-Drafts
 > directories. This draft is a work item of the Session Initiation
 > Proposal Investigation Working Group of the IETF.
 >
 > Title		: Requirements for Content Indirection in Session Initiation
 > Protocol (SIP) Messages Author(s)	: S. Olson Filename	:
 > draft-ietf-sipping-content-indirect-02.txt Pages		: 9 Date		:
 > 2002-9-24  This specification defines requirements for a mechanism to
 > indirectly specify the content of a SIP message for the purpose of
 > transferring the content via a non-SIP channel.
 >
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-content-indirect-
 >  02.txt
 >
 > To remove yourself from the IETF Announcement list, send a message to
 >  ietf-announce-request with the word unsubscribe in the body of the
 > message.
 >
 > Internet-Drafts are also available by anonymous FTP. Login with the
 > username "anonymous" and a password of your e-mail address. After
 > logging in, type "cd internet-drafts" and then "get
 > draft-ietf-sipping-content-indirect-02.txt".
 >
 > A list of Internet-Drafts directories can be found in
 > http://www.ietf.org/shadow.html or
 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 >
 >
 > Internet-Drafts can also be obtained by e-mail.
 >
 > Send a message to: [email-masked]. In the body type: "FILE
 > /internet-drafts/draft-ietf-sipping-content-indirect-02.txt".  NOTE:
 > The mail server at ietf.org can return the document in MIME-encoded
 > form by using the "mpack" utility.  To use this feature, insert the
 > command "ENCODING mime" before the "FILE" command.  To decode the
 > response(s), you will need "munpack" or a MIME-compliant mail reader.
 > Different MIME-compliant mail readers exhibit different behavior,
 > especially when dealing with "multipart" MIME messages (i.e.
 > documents which have been split up into multiple messages), so check
 > your local documentation on how to manipulate these messages.   Below
 > is the data which will enable a MIME compliant mail reader
 > implementation to automatically retrieve the ASCII version of the
 > Internet-Draft.
 >
 > _______________________________________________ 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
 >

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.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: "Eric Burger" <[email-masked]>
Date: Thu, 17 Oct 2002 10:13:39 -0400

I can't imagine enforcing such a requirement in the SIP machinery.  I would
offer that we remind people in the security section that a URI is a URI.  If
they want to ensure that only the recipient of the indirection can access
the content of the URI, that they need to provide for it (e.g., using
end-to-end, scheme-appropriate certification (e.g., X.509 for http)).

If we're giving programming hints, we also might want to mention lifetimes
of such URI's, single use URI's, and other tricks of the trade.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jonathan Rosenberg
[snip]
> the URI to only be obtained from the recipient of the indirection"?
[snip]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 21 Oct 2002 12:24:42 -0400

Eric Burger wrote:
> I can't imagine enforcing such a requirement in the SIP machinery. 

Thats OK. It just places a requirement on the overall system, and limits 
potential design choices.

-Jonathan R.