RE: [Simple] Content indirection - Uploading large messages
hisham.khartabil@nokia.com Tue, 21 January 2003 09:56 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24689 for <simple-archive@odin.ietf.org>; Tue, 21 Jan 2003 04:56:42 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0LAEAL04076 for simple-archive@odin.ietf.org; Tue, 21 Jan 2003 05:14:10 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAEAJ04073 for <simple-web-archive@optimus.ietf.org>; Tue, 21 Jan 2003 05:14:10 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24683 for <simple-web-archive@ietf.org>; Tue, 21 Jan 2003 04:56:10 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LAE3J04062; Tue, 21 Jan 2003 05:14:03 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0LADQJ04042 for <simple@optimus.ietf.org>; Tue, 21 Jan 2003 05:13:26 -0500
Received: from mgw-x4.nokia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24677 for <simple@ietf.org>; Tue, 21 Jan 2003 04:55:26 -0500 (EST)
From: hisham.khartabil@nokia.com
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id h0LA17t03873 for <simple@ietf.org>; Tue, 21 Jan 2003 12:01:07 +0200 (EET)
Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id <T5fed039dc2ac158f23077@esvir03nok.nokia.com>; Tue, 21 Jan 2003 11:58:50 +0200
Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 11:58:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2C133.B211AF68"
Subject: RE: [Simple] Content indirection - Uploading large messages
Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7FE7169@esebe019.ntc.nokia.com>
Thread-Topic: [Simple] Content indirection - Uploading large messages
Thread-Index: AcLBMs/sUPSOeItcSiK7IzZ8qe1ucgAANGCQ
To: Oded.Cnaan@comverse.com, simple@ietf.org
Cc: Orly_Rapaport@icomverse.com
X-OriginalArrivalTime: 21 Jan 2003 09:58:50.0143 (UTC) FILETIME=[B276FAF0:01C2C133]
Sender: simple-admin@ietf.org
Errors-To: simple-admin@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/simple/>
Date: Tue, 21 Jan 2003 11:58:49 +0200
Please take a look at http://www.ietf.org/internet-drafts/draft-khartabil-sip-congestionsafe-ci-01.txt I'm planning to update this to include a UA posting (eg: contents for PUBLISH or MESSAGE). Regards, Hisham -----Original Message----- From: ext Cnaan Oded [mailto:Oded.Cnaan@comverse.com] Sent: Tuesday, January 21, 2003 11:51 AM To: simple@ietf.org Cc: Rapaport Orly Subject: RE: [Simple] Content indirection - Uploading large messages Sean, Thanks for the prompt reply. You may be right that the details of how large payloads are sent from the UA to the server (in case these are not the same entities and that there is a network based server) are outside SIMPLE scope but it seems to me that the first hurdle SIMPLE will face would be -interoperability. If you leave this question open for proprietary solutions, applications from different vendors will not be able to co-exist on the same network. If you look at the WG charter, you will find that "The IETF has committed to producing an interoperable standard for these services ". The charter also refers to RFC 2778 and CPIM which require defining how messages are sent from UAs to servers, regardless of their size. Moreover, if you look at 3GPP requirements from SIMPLE (e.g., draft-niemi-simple-im-wireless-reqs-00) they require that "The content size MUST NOT be limited by the Instant Messaging, or message session protocols" - SIMPLE must be able to specify how this is done. I believe SIMPLE WG should define at least a 'default' behavior for these cases, or refer to an external standard, such as MM1. Oded Cnaan -----Original Message----- From: Sean Olson [ mailto:seancolson@yahoo.com] Sent: Tuesday, January 21, 2003 9:46 AM To: 'Cnaan Oded'; simple@ietf.org Subject: RE: [Simple] Content indirection - Uploading large messages The draft intentionally does not address the how the content is placed on the content server to begin with. That is a separate problem that has many disparate solutions and does not necessarily need to be standardized. The interesting thing about standardizing the content-indirection mechanism is that it involves two SIP entities and directly impacts the SIP signaling. The transfer of content, either from the UA to the server, or between UAs is best handled outside of SIP ... the very point of the draft. Some important things to note: 1) The "server" does not have to be distinct from the UA. They can be one in the same. 2) The URL does not have to be an HTTP URL, though this will be probably be one of the more common schemes used. For example, an LDAP URL might very be appropriate for certain types of content 3) HTTP is ideal for conveying meta-data about the content it carries, but that argument is best handled outside of SIMPLE 4) It was never envisoned that MESSAGE would be used to send these large payloads -- the entire point of content indirection is to offload this to a non-SIP carrier. 5) There is nothing mutually exclusive of content-indirection and MMS. Nor is there anything that compels one to use MMS for this task in the draft. It's simply outside the scope of this draft. 6) Is there something particularly non-concrete about the draft? ;-) 7) This mechanism is not tied to any particular architecture, though some architectures may have more pressing need for it than others. cheers, sean -----Original Message----- From: simple-admin@ietf.org [ mailto:simple-admin@ietf.org] On Behalf Of Cnaan Oded Sent: Monday, January 20, 2003 11:05 PM To: 'simple@ietf.org' Subject: [Simple] Content indirection - Uploading large messages The content-indirection draft (the latest I could find was draft-ietf-sipping-content-indirect-02.txt) describes how messages or notifications carry a URL in order to allow the UA to retrieve the (usually large) content over other transports (e.g., HTTP). The draft however does not specify how large content is uploaded from the UA to the server. Using HTTP per se is not sufficient for uploading messages over HTTP as there is some meta-data that needs to be attached to the document such as sender, recipient(s), message type etc. The MMS standard have already solved these details in their MM1 protocol (over HTTP as well). Note also that using the MESSAGE method is not a good practice as well as it would generate huge load on the CSCFs (in mobile networks that deploy IMS/MMD infrastructure), denying them from performing call control tasks. 1. How should large messages be sent from the UA to the server? any specific draft? 2. Does the SIMPLE WG intend to reuse the MM1 specifications or invent a new one? 3. What's the status of this work within the SIMPLE WG? Are there any concrete contributions? Thanks, Oded Cnaan Comverse
- [Simple] Content indirection - Uploading large me… Cnaan Oded
- RE: [Simple] Content indirection - Uploading larg… Sean Olson
- RE: [Simple] Content indirection - Uploading larg… Cnaan Oded
- RE: [Simple] Content indirection - Uploading larg… hisham.khartabil
- Re: [Simple] Content indirection - Uploading larg… Jonathan Rosenberg