From simple-bounces@ietf.org Sat Apr 01 11:35:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPj4P-00079D-VF; Sat, 01 Apr 2006 11:35:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPj4O-000798-Ty for simple@ietf.org; Sat, 01 Apr 2006 11:35:24 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPj4O-0006i0-GU for simple@ietf.org; Sat, 01 Apr 2006 11:35:24 -0500 Received: (qmail 12447 invoked by uid 0); 1 Apr 2006 16:35:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Apr 2006 16:35:23 -0000 Message-ID: <008301c655aa$43902800$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Sat, 1 Apr 2006 18:35:19 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1391079893==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1391079893== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C655BB.06EE1770" This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C655BB.06EE1770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Two comments: 1 - ambiguity in ABNF AUID =3D global-auid / vendor-auid global-auid =3D auid auid =3D 1*pchar vendor-auid =3D rev-hostname "." auid rev-hostname =3D toplabel *( "." domainlabel ) domainlabel =3D alphanum / alphanum *( alphanum / "-" ) = alphanum toplabel =3D ALPHA / ALPHA *( alphanum / "-" ) alphanum >From RFC3986: pchar =3D unreserved / pct-encoded / sub-delims / ":" / "@" unreserved =3D ALPHA / DIGIT / "-" / "." / "_" / "~" sub-delims =3D "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=3D" The characters allowed in an AUID should be considered more carefully. = Currently, '.' is allowed which is ambiguous (i.e. which part belongs to = 'rev-hostname' and which part to the auid).=20 2 - normative reference [2] refers to an older version of XML schema, = latest is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/ Regards, jeroen ------=_NextPart_000_0080_01C655BB.06EE1770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Two comments:
 
1 - ambiguity in ABNF
 
  =20 AUID           &nb= sp;=20 =3D  global-auid / vendor-auid
  =20 global-auid      =3D  auid
   = auid           &nb= sp;=20 =3D  1*pchar
   = vendor-auid     =20 =3D  rev-hostname "." auid
  =20 rev-hostname     =3D  toplabel *( "." = domainlabel =20 )
   domainlabel      =3D  = alphanum /=20 alphanum *( alphanum / "-" ) alphanum
  =20 toplabel         =3D  ALPHA = / ALPHA=20 *( alphanum / "-" ) alphanum
 
From RFC3986:
 =20 pchar         =3D unreserved / = pct-encoded=20 / sub-delims / ":" / "@"
  unreserved    =3D = ALPHA / DIGIT=20 / "-" / "." / "_" / "~"
  sub-delims    =3D "!" / = "$" /=20 "&" / "'" / "(" /=20 ")"
           =      =20 / "*" / "+" / "," / ";" / "=3D"
 
The characters allowed in an AUID = should be=20 considered more carefully. Currently, '.' is allowed which is ambiguous = (i.e.=20 which part belongs to 'rev-hostname' and which part to the auid). =

2 - normative reference [2] refers to an older version of XML = schema,=20 latest is http://www.w= 3.org/TR/2004/REC-xmlschema-1-20041028/
 
Regards,
 
jeroen
------=_NextPart_000_0080_01C655BB.06EE1770-- --===============1391079893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1391079893==-- From simple-bounces@ietf.org Sat Apr 01 12:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPjsx-0003id-Fq; Sat, 01 Apr 2006 12:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPjsw-0003hC-5X for simple@ietf.org; Sat, 01 Apr 2006 12:27:38 -0500 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPjsu-0000eU-H6 for simple@ietf.org; Sat, 01 Apr 2006 12:27:38 -0500 Received: (qmail 31639 invoked by uid 0); 1 Apr 2006 17:27:35 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 1 Apr 2006 17:27:35 -0000 Message-ID: <00a501c655b1$8e5a6920$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Subject: Re: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Sat, 1 Apr 2006 19:27:30 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1163138123==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1163138123== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C655C2.51B5E790" This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C655C2.51B5E790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Another ABNF related comment: the "extension-selector" production in = section 6.3 is ambiguous, it is a superset of both "attribute-selector" = and "namespace-selector": node-selector =3D element-selector ["/" terminal-selector] terminal-selector =3D attribute-selector / namespace-selector / extension-selector element-selector =3D step *( "/" step) step =3D by-name / by-pos / by-attr / by-pos-attr / extension-selector by-name =3D NameorAny by-pos =3D NameorAny "[" position "]" position =3D 1*DIGIT attr-test =3D ( "@" att-name "=3D" <"> att-value <"> ) / ( "@" att-name "=3D" <'> att-value <'> ) by-attr =3D NameorAny "[" attr-test "]" by-pos-attr =3D NameorAny "[" position "]" "[" attr-test = "]" NameorAny =3D QName / "*" ; QName from XML Namespaces att-name =3D QName att-value =3D AttValue ; from XML specification attribute-selector =3D "@" att-name namespace-selector =3D "namespace::*" extension-selector =3D 1*( %x00-2e / %x30-ff ) ; anything but = "/" One solution would be to change it into: extension-selector =3D "x-" 1*( %x00-2e / %x30-ff ) ; anything but = "/" Regards, Jeroen ------=_NextPart_000_00A2_01C655C2.51B5E790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Another ABNF related comment: the=20 "extension-selector" production in section 6.3 is ambiguous, it is a = superset of=20 both "attribute-selector" and "namespace-selector":
 
  =20 node-selector          =3D=20 element-selector ["/" terminal-selector]
  =20 terminal-selector      =3D attribute-selector / = namespace-selector=20 /
           &n= bsp;           &nb= sp;   =20 extension-selector
  =20 element-selector       =3D step *( "/"=20 step)
  =20 step           &nb= sp;      =20 =3D by-name / by-pos / by-attr / by-pos-attr=20 /
           &n= bsp;           &nb= sp;   =20 extension-selector
  =20 by-name           =     =20 =3D NameorAny
  =20 by-pos           &= nbsp;    =20 =3D NameorAny "[" position "]"
  =20 position           = ;   =20 =3D 1*DIGIT
  =20 attr-test          &nbs= p;  =20 =3D ( "@" att-name "=3D" <"> att-value <"> )=20 /
           &n= bsp;           &nb= sp;   =20 ( "@" att-name "=3D" <'> att-value <'> )
  =20 by-attr           =     =20 =3D NameorAny "[" attr-test "]"
  =20 by-pos-attr          &n= bsp; =3D=20 NameorAny "[" position "]" "[" attr-test "]"
  =20 NameorAny          &nbs= p;  =20 =3D QName / "*"   ; QName from XML Namespaces
  =20 att-name           = ;   =20 =3D QName
  =20 att-value          &nbs= p;  =20 =3D AttValue      ; from XML=20 specification
   attribute-selector     = =3D "@"=20 att-name
   namespace-selector     =3D=20 "namespace::*"
   = extension-selector     =3D 1*(=20 %x00-2e / %x30-ff )  ; anything but "/"
One solution would be to change it=20 into:
 
extension-selector     =3D "x-"=20 1*( %x00-2e / %x30-ff )  ; anything but "/"
Regards,
 
Jeroen
------=_NextPart_000_00A2_01C655C2.51B5E790-- --===============1163138123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1163138123==-- From simple-bounces@ietf.org Sat Apr 01 22:56:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPthO-0001Jp-EL; Sat, 01 Apr 2006 22:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPthM-0001Jk-HL for simple@ietf.org; Sat, 01 Apr 2006 22:56:20 -0500 Received: from zproxy.gmail.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPthL-0000zO-B8 for simple@ietf.org; Sat, 01 Apr 2006 22:56:20 -0500 Received: by zproxy.gmail.com with SMTP id x3so1338092nzd for ; Sat, 01 Apr 2006 19:56:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=M3w3a3aUkOhaZsJWYX2NwSJ+XXt2pq12J1mCzKawjkgGRmjFnq+WrRk9IuZ9I8sLlZxTn/P4RM5emI+7NMujPiR1UMIHRydeDlRQ9bW/B3YeC+NzlHFOZDLeEHnrdbBBGMCC1cKSjuGmmL/5F0QxA3/pu6WdEduu7JKH0EkAbeg= Received: by 10.35.37.18 with SMTP id p18mr461769pyj; Sat, 01 Apr 2006 19:56:18 -0800 (PST) Received: by 10.35.89.19 with HTTP; Sat, 1 Apr 2006 19:56:18 -0800 (PST) Message-ID: <9d77d7060604011956l6c281d00p69625a93d3032a36@mail.gmail.com> Date: Sun, 2 Apr 2006 11:56:18 +0800 From: "Xiang Ting" To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rohan@ekabal.com, fluffy@cisco.com Subject: [Simple] Suggestion on MSRP connection model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The MSRP draft describe connection initial under TCP as below: [snip] When a new MSRP session is created, the offerer MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available, and is implemented by both parties to the connection. [/snip] There is a new RFC 4415 named 'TCP-Based Media Transport in the Session Description Protocol (SDP)' give solution on how to create TCP based connection using SDP. I suggest MSRP can also use the method describe in RFC4415 to initial it's connection, this is more flexible. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sat Apr 01 23:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPuaV-0005hN-2q; Sat, 01 Apr 2006 23:53:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPuaT-0005hH-SX for simple@ietf.org; Sat, 01 Apr 2006 23:53:17 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPuaS-0003gH-HW for simple@ietf.org; Sat, 01 Apr 2006 23:53:17 -0500 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k324prDm041345 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 1 Apr 2006 22:51:54 -0600 (CST) (envelope-from ben@estacado.net) In-Reply-To: <9d77d7060604011956l6c281d00p69625a93d3032a36@mail.gmail.com> References: <9d77d7060604011956l6c281d00p69625a93d3032a36@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A0A5E82-14FD-4F43-9F0B-8DCF7E1F0CE7@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Date: Sat, 1 Apr 2006 22:51:48 -0600 To: "Xiang Ting" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org Subject: [Simple] Re: Suggestion on MSRP connection model X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org 4415 is "IANA Registration for Enumservice Voice ". I assume you are referring to RFC 4145. This RFC was still a work in progress at the time that the SIMPLE working group designed the connection management features of MSRP, and did not at that time meet the needs the MSRP requirement of positively identifying which session an incoming connection belonged to. When 4145 was published, this part of MSRP was substantially complete, and the working group did not choose to redesign because of the completion of another RFC. You can understand how it becomes impossible to complete a specification if you reopen items for which the working group already has consensus each time a potentially related publication is completed. My opinion on the matter is that we should complete MSRP as it is, and then if 4145 is determined to be a better approach MSRP we can write a new spec that updates that part of MSRP. That is the point of the statement saying that the MSRP connection direction may be overridden if a standardized approach for connection direction negotiation becomes available. On Apr 1, 2006, at 9:56 PM, Xiang Ting wrote: > The MSRP draft describe connection initial under TCP as below: > [snip] > When a new MSRP session is created, the offerer MUST act as the > "active" endpoint, meaning that it is responsible for opening the > transport connection to the answerer, if a new connection is > required. However, this requirement MAY be weakened if > standardized > mechanisms for negotiating the connection direction become > available, > and is implemented by both parties to the connection. > [/snip] > > There is a new RFC 4415 named 'TCP-Based Media Transport in the > Session Description Protocol (SDP)' > give solution on how to create TCP based connection using SDP. > > I suggest MSRP can also use the method describe in RFC4415 to initial > it's connection, this is more flexible. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 03 05:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQLKi-00029u-9m; Mon, 03 Apr 2006 05:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQLKh-00029m-FR for simple@ietf.org; Mon, 03 Apr 2006 05:26:47 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQLKg-0008Ux-27 for simple@ietf.org; Mon, 03 Apr 2006 05:26:47 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k339PSTx010102; Mon, 3 Apr 2006 12:25:31 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 12:26:43 +0300 Received: from [127.0.0.1] ([172.21.35.223]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 Apr 2006 12:26:43 +0300 Message-ID: <4430EA52.5010205@nokia.com> Date: Mon, 03 Apr 2006 12:26:42 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Jussi K. Virtanen" References: <95d59cef0603300411s3755eb02x6999c5c5460b6567@mail.gmail.com> In-Reply-To: <95d59cef0603300411s3755eb02x6999c5c5460b6567@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Apr 2006 09:26:43.0008 (UTC) FILETIME=[B8498400:01C65700] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Aki Niemi , IETF SIMPLE Subject: [Simple] Re: How are participant URIs conveyed from the focus to an MSRP switch? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Jussi: The protocol that runs between the focus and the MSRP switch needs to be able to carry the SIP URIs of the participants along with the MSRP session identifiers. Although not strictly required for other purposes, similar functions are also required over this interface (for instance, the focus and the MSRP mixer have to exchange the MSRP URIs of each participant, to create the SDP). /Miguel Jussi K. Virtanen wrote: > Hi, > > In order to be able to forward private messages, an MSRP switch has to > maintain an association between an MSRP session and a participant URI. > > Consider a situation in which the focus of a conference and an MSRP > switch that acts as a mixer in the conference are separate and the MSRP > switch is not a SIP UA. How are the participant URIs conveyed from the > focus to the MSRP switch? > > > Best Regards, > > -- > Jussi K. Virtanen -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 05 09:10:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7me-0001VW-GP; Wed, 05 Apr 2006 09:10:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7md-0001VR-0u for simple@ietf.org; Wed, 05 Apr 2006 09:10:51 -0400 Received: from pproxy.gmail.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7mb-0005RG-Qf for simple@ietf.org; Wed, 05 Apr 2006 09:10:50 -0400 Received: by pproxy.gmail.com with SMTP id t32so109011pyc for ; Wed, 05 Apr 2006 06:10:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=fUUB8R2NYLg5+L6tA+K3t4tnWWtklO71ny/CTcVWVsElRBEQVuZymt5yh+RkZ2a0npLRDmy7rOV34QSZoQAzQzDI2ZZ/5zKpudrACAHovhFTrKU+4ezeFi/j3zBBeX6h5xS2YoTC6yHR7AXrRldhEtTry5tRZmA4UC8TTVJdtqM= Received: by 10.35.103.12 with SMTP id f12mr133989pym; Wed, 05 Apr 2006 06:10:49 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Wed, 5 Apr 2006 06:10:49 -0700 (PDT) Message-ID: <9d77d7060604050610m4652dc5pd4c6e5e7cbb3177d@mail.gmail.com> Date: Wed, 5 Apr 2006 21:10:49 +0800 From: "Xiang Ting" To: simple@ietf.org Subject: [Simple][MSRP]Is a MSRP message with both an empty body and a Content-Type a correct massage? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rohan@ekabal.com, fluffy@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It is said in the draft about MSRP that "If the request has a body, it must contain a Content-Type header field." Now, I have a question to= ask. Is a MSRP message with both an empty body(only CRLF appears) and a Content-Type a correct massage? e.g. "MSRP tdsaff34r35d SEND\r\n" "To-Path: msrp://10.70.110.158:7654/sfasf439;tcp\r\n" "From-Path: msrp://10.71.106.33:33322/afd43rfes;tcp\r\n" "Message-ID: dsdf34r\r\n" "Content-Type: text/plain\r\n" "\r\n" "\r\n" "-------tdsaff34r35d$\r\n" "MSRP tdsaff34r35d REPORT\r\n" "To-Path: msrp://10.70.110.158:7654/sfasf439;tcp\r\n" "From-Path: msrp://10.71.106.33:33322/afd43rfes;tcp\r\n" "Message-ID: dsdf34r\r\n" "Status: 000 200 OK\r\n" "Content-Type: text/plain\r\n" "\r\n" "\r\n" "-------tdsaff34r35d$\r\n" _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 05 09:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7uU-0006JR-Rj; Wed, 05 Apr 2006 09:18:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR7uT-0006GX-I0 for simple@ietf.org; Wed, 05 Apr 2006 09:18:57 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR7uR-0005yM-61 for simple@ietf.org; Wed, 05 Apr 2006 09:18:57 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k35DIgrh067765 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 5 Apr 2006 08:18:45 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <9d77d7060604050610m4652dc5pd4c6e5e7cbb3177d@mail.gmail.com> References: <9d77d7060604050610m4652dc5pd4c6e5e7cbb3177d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple][MSRP]Is a MSRP message with both an empty body and a Content-Type a correct massage? Date: Wed, 5 Apr 2006 08:18:34 -0500 To: Xiang Ting X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It depends on the content-type value. A lone CRLF is a legal content for text/plain. It would not be legal for all possible MIME types. Hope this helps! Ben. On Apr 5, 2006, at 8:10 AM, Xiang Ting wrote: > It is said in the draft about MSRP that "If the request has a body, > it must contain a Content-Type header field." Now, I have a > question to ask. > Is a MSRP message with both an empty body(only CRLF appears) and a > Content-Type a correct massage? > > e.g. > "MSRP tdsaff34r35d SEND\r\n" > "To-Path: msrp://10.70.110.158:7654/sfasf439;tcp\r\n" > "From-Path: msrp://10.71.106.33:33322/afd43rfes;tcp\r\n" > "Message-ID: dsdf34r\r\n" > "Content-Type: text/plain\r\n" > "\r\n" > "\r\n" > "-------tdsaff34r35d$\r\n" > > > "MSRP tdsaff34r35d REPORT\r\n" > "To-Path: msrp://10.70.110.158:7654/sfasf439;tcp\r\n" > "From-Path: msrp://10.71.106.33:33322/afd43rfes;tcp\r\n" > "Message-ID: dsdf34r\r\n" > "Status: 000 200 OK\r\n" > "Content-Type: text/plain\r\n" > "\r\n" > "\r\n" > "-------tdsaff34r35d$\r\n" _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 02:37:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRO76-0000Sh-LW; Thu, 06 Apr 2006 02:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLrgk-0006dS-07 for simple@ietf.org; Tue, 21 Mar 2006 19:59:02 -0500 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLrgi-0004iP-JX for simple@ietf.org; Tue, 21 Mar 2006 19:59:01 -0500 Received: from [130.129.130.162] (DHCP-Wireless-130-162.ietf65.org [130.129.130.162]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.3) with ESMTP id k2M0wwgo073736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 18:58:59 -0600 (CST) (envelope-from adam@estacado.net) Message-ID: <4420A14F.6010702@estacado.net> Date: Tue, 21 Mar 2006 18:58:55 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?EUC-KR?B?wMzBvsfK?= Subject: Re: [Simple] srtp negotiation on SIP (sdp message) References: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> In-Reply-To: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by vicuna.estacado.net id k2M0wwgo073736 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Thu, 06 Apr 2006 02:37:03 -0400 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org =C0=CC=C1=BE=C7=CA wrote: >I want to find some draft or document for srtp key negotiation for sip >by using sdp messages. > =20 > The issue is extremely complicated at the moment; there are 11 competing proposals right now for ways to negotiate encryption keys for RTP. Relevant documents include: RFC 3830 RFC 3711 draft-ietf-mmusic-kmgmt-ext-15 draft-ietf-mmusic-sdescriptions-12 draft-ietf-msec-mikey-rsa-r-02 draft-ietf-msec-mikey-dhhmac-11 draft-ietf-msec-newtype-keyid-05 draft-mcgrew-srtp-ekt-00 draft-baugher-mmusic-sdp-dh-00 draft-zimmermann-avt-zrtp-01 draft-tschofenig-avt-rtp-dtls-00 draft-fischl-sipping-media-dtls-00 draft-fischl-mmusic-sdp-dtls-00 draft-rescorla-tls-partial-00 draft-modadugu-dtls-short-00 draft-lehtovirtya-srtp-rcc-00 draft-fries-msec-applicability-00 draft-wing-mmusic-sdes-early-media-00 Dan Wing did the work to put together this list. He has also done a very good job analyzing the current situation. See: http://www3.ietf.org/proceedings/06mar/slides/raiarea-1.ppt /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 02:37:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRO76-0000SO-6v; Thu, 06 Apr 2006 02:37:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLW2l-00058i-3q for simple@ietf.org; Mon, 20 Mar 2006 20:52:19 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLW2j-0007Pf-QU for simple@ietf.org; Mon, 20 Mar 2006 20:52:19 -0500 X-IronPort-AV: i="4.03,112,1141621200"; d="scan'208"; a="30325993:sNHT64190220" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Mar 2006 20:52:14 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IM delivery reports for conferencing Thread-Index: AcZMaIwp+tCU0MRNToSgG8JDGluh4wAAHCFAAAhAqLA= From: "Burger, Eric" To: "Sean Olson" , "Hisham Khartabil" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-Mailman-Approved-At: Thu, 06 Apr 2006 02:37:02 -0400 Cc: simple@ietf.org Subject: [Simple] RE: IM delivery reports for conferencing X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I would offer that it MUST be driven by the client - they are the only one that knows whether they care. C.f. the use of notifications for MSRP conferencing. -----Original Message----- From: Sean Olson [mailto:Sean.Olson@microsoft.com]=20 Sent: Monday, March 20, 2006 4:58 PM To: Hisham Khartabil Cc: Burger, Eric; simple@ietf.org Subject: RE: IM delivery reports for conferencing Well, my opinion obviously is that we do need this capability. However, I don't believe the sender should really be in control of this facet of delivery notifications. In fact if you build in aggregation support now rather than later, than you don't even need to negotiate this. (I propose making receiving aggregated DN support at the sender mandatory)=20 -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: Monday, March 20, 2006 1:52 PM To: Sean Olson Cc: eburger@brooktrout.com; simple@ietf.org Subject: Re: IM delivery reports for conferencing On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > The URI attribute only works if you structure the rest of the=20 > information around it.... Are you suggesting aggregation by multipart=20 > MIME or creating a new top-level XML element? I have suggested neither. I doesn't matter really although the latter makes more sense. The question is do we need such feature? and if we do, to allow the sender of the IM to choose which mode or reporting s/he wanted (aggregated or one by one)? If the answer to the first question is yes, then I strongly believe that the answer to the second question is also yes. Hisham > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Wednesday, March 15, 2006 1:49 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: > >> >> Looking at: >> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >> -00.tx >> t >> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >> >> Neither seems to address the use case of an "exploder" or IM=20 >> conferencing where a single IM may have multiple recipients. My=20 >> suggestion is that the schema you choose for the notification allow=20 >> multiple delivery notifications to be batched together with each=20 >> entry > >> distringuished by the recipient URI. > > It does address it to an extent. That's what the "uri" attribute is=20 > there for. If we want to allow aggregation of receipts before sending=20 > the receipt to the IM sender, then we also need to start thinking=20 > about what the sender wants and how to indicate it in the IM itself. > > Hisham > >> >> For example: >> >> For Draft-khartabil-simple-im-receipts-00 >> >> >> 34jk324j >> >> read >> 200 >> The message has been read >> >> >> error >> 415 >> The message could not be=20 >> delivered >> >> >> >> Or, for Draft-burger-simple-imdn-03 >> >> >> >> 1542af3e8b@eburger@example.com >> >> >> >> im:hisham.khartabil@example.net >> >> read >> >> >> >> im:eric.burger@example.net >> >> read >> >> >> >> Sorry if this has been discussed before. Was there a reason this was=20 >> omitted previously? >> >> Thanks, >> Sean >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 07:32:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRSj7-0004Vy-Q9; Thu, 06 Apr 2006 07:32:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRSj6-0004Vs-4O for simple@ietf.org; Thu, 06 Apr 2006 07:32:36 -0400 Received: from rwcrmhc12.comcast.net ([204.127.192.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRSj3-0004jq-Rb for simple@ietf.org; Thu, 06 Apr 2006 07:32:36 -0400 Received: from s73602 (unknown[71.56.187.251]) by comcast.net (rwcrmhc12) with SMTP id <20060406113156m1200khibbe>; Thu, 6 Apr 2006 11:31:56 +0000 Message-ID: <0bf001c6596d$5f7cce80$ea087c0a@china.huawei.com> From: "Spencer Dawkins" To: References: <000a01c64d49$e4ac5b50$5fb2d5a5@LocalHost> <4420A14F.6010702@estacado.net> Subject: Re: [Simple] srtp negotiation on SIP (sdp message) Date: Thu, 6 Apr 2006 06:29:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ks_c_5601-1987"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I agree with Adam's summary, and can only add (from my impression of the discussion around http://www3.ietf.org/proceedings/06mar/slides/raiarea-1.ppt#21) that none of the 11 competing proposals are so obviously the right answer that we should pick one existing proposal and forget the other 10 proposals... Spencer ----- Original Message ----- From: "Adam Roach" ÀÌÁ¾ÇÊ wrote: >I want to find some draft or document for srtp key negotiation for sip >by using sdp messages. > > The issue is extremely complicated at the moment; there are 11 competing proposals right now for ways to negotiate encryption keys for RTP. Relevant documents include: RFC 3830 RFC 3711 draft-ietf-mmusic-kmgmt-ext-15 draft-ietf-mmusic-sdescriptions-12 draft-ietf-msec-mikey-rsa-r-02 draft-ietf-msec-mikey-dhhmac-11 draft-ietf-msec-newtype-keyid-05 draft-mcgrew-srtp-ekt-00 draft-baugher-mmusic-sdp-dh-00 draft-zimmermann-avt-zrtp-01 draft-tschofenig-avt-rtp-dtls-00 draft-fischl-sipping-media-dtls-00 draft-fischl-mmusic-sdp-dtls-00 draft-rescorla-tls-partial-00 draft-modadugu-dtls-short-00 draft-lehtovirtya-srtp-rcc-00 draft-fries-msec-applicability-00 draft-wing-mmusic-sdes-early-media-00 Dan Wing did the work to put together this list. He has also done a very good job analyzing the current situation. See: http://www3.ietf.org/proceedings/06mar/slides/raiarea-1.ppt /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 12:01:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWun-0003tZ-4A; Thu, 06 Apr 2006 12:00:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRWum-0003tS-7P for simple@ietf.org; Thu, 06 Apr 2006 12:00:56 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRWuj-0005lU-A3 for simple@ietf.org; Thu, 06 Apr 2006 12:00:56 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 729195A6; Thu, 6 Apr 2006 18:00:52 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 18:00:51 +0200 Received: from esealmw107.eemea.ericsson.se ([153.88.200.70]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 18:00:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Thu, 6 Apr 2006 18:00:50 +0200 Message-ID: <2DC267ED40568D4F9AA4F5DF955AF16A024660FC@esealmw107.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Thread-Index: AcZR1WZseBLT1fS1RJynwa33duLwtAHucNyQ From: "Anders Lindgren C \(HF/EAB\)" To: "Robert Sparks" , X-OriginalArrivalTime: 06 Apr 2006 16:00:51.0659 (UTC) FILETIME=[473889B0:01C65993] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi all, I have some minor editorial comments to the draft 1)In chapter 6.1 the example of an XCAP root URI is "http://xcap.example.com. In chapter 6.2 the example has as xcap root "http://xcap.example.com/services and a statement that the example from chapter 6.1 continues. In chapter 7 the example is back to use a XCAP root URI that looks like "http://xcap.example.com. In chapter 13 the examples are using http://xcap.example.com/services as example of the XCAP root URI My propsal is to use the same XCAP root URI example (http://xcap.example.com) everywhere. Thanks Anders Lindgren -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: den 27 mars 2006 21:32 To: simple@ietf.org list Subject: [Simple] WGLC : draft-ietf-simple-xcap-09.txt=20 This is a SIMPLE working group Last Call for Comments on draft-ietf- simple-xcap-09. This last call ends in two weeks - April 10, 2006 The previous version of this draft was approved for publication, but was removed from the RFC editor's queue to address a technical issue with conditional inserts. The group also agreed to incorporate several clarifying text changes while the document was open. Please review the changes carefully and send feedback to the SIMPLE list, copying Jonathan. RjS On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the SIP for Instant Messaging and=20 > Presence Leveraging Extensions Working Group of the IETF. > > Title : The Extensible Markup Language (XML) Configuration Access =20 > Protocol (XCAP) > Author(s) : J. Rosenberg > Filename : draft-ietf-simple-xcap-09.txt > Pages : 68 > Date : 2006-3-23 > =09 > This specification defines the Extensible Markup Language (XML)=20 > Configuration Access Protocol (XCAP). XCAP allows a client to read,=20 > write and modify application configuration data, stored in XML format=20 > on a server. XCAP maps XML document sub-trees and element attributes=20 > to HTTP URIs, so that these components can be directly accessed by=20 > HTTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-xcap-09.txt". > > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-xcap-09.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-3-23150339.I-D@ietf.org> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 19:26:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRds4-00070V-Qc; Thu, 06 Apr 2006 19:26:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRds4-00070Q-14 for simple@ietf.org; Thu, 06 Apr 2006 19:26:36 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRds3-0003a8-KK for simple@ietf.org; Thu, 06 Apr 2006 19:26:35 -0400 Received: from [10.10.2.211] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k36NR9pH007906 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 18:27:10 -0500 In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8F4906E3-151C-4F97-8C0F-ED169E8CFAD2@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Thu, 6 Apr 2006 18:26:28 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.746.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I'll further note that there are some bright young lads in OMA who want to use IMDN as a billing mechanism. If you send an IMDN, the sender gets billed for sending you the message, and if you don't, the billing system will presume the message was lost in transit and presumably not bill. This would appear to make IMDN both mandatory and something that couldn't be driven from a UA. I maintain IMDN is a bad idea. It gives people bad ideas. -- Dean On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. > However, > I don't believe the sender should really be in control of this > facet of > delivery notifications. In fact if you build in aggregation support > now > rather than later, than you don't even need to negotiate this. (I > propose making receiving aggregated DN support at the sender > mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter > makes more sense. The question is do we need such feature? and if > we do, > to allow the sender of the IM to choose which mode or reporting s/he > wanted (aggregated or one by one)? If the answer to the first question > is yes, then I strongly believe that the answer to the second question > is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM >>> conferencing where a single IM may have multiple recipients. My >>> suggestion is that the schema you choose for the notification allow >>> multiple delivery notifications to be batched together with each >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 19:33:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdya-0002sE-TK; Thu, 06 Apr 2006 19:33:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRdyZ-0002s9-UK for simple@ietf.org; Thu, 06 Apr 2006 19:33:19 -0400 Received: from mail2.microsoft.com ([131.107.1.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRdyZ-0003p4-Ei for simple@ietf.org; Thu, 06 Apr 2006 19:33:19 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:33:18 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:33:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:33:08 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 16:33:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: IM delivery reports for conferencing Date: Thu, 6 Apr 2006 16:32:19 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C642E9B5@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <8F4906E3-151C-4F97-8C0F-ED169E8CFAD2@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: IM delivery reports for conferencing Thread-Index: AcZZ0Y5vajqE6C2wRFmIOWlOm9lCuAAALJlg From: "Sean Olson" To: "Dean Willis" , "Burger, Eric" X-OriginalArrivalTime: 06 Apr 2006 23:33:08.0594 (UTC) FILETIME=[76183520:01C659D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org There are people who proposed billing based on the ACK as well .... Is ACK a bad idea? -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, April 06, 2006 4:26 PM To: Burger, Eric Cc: Sean Olson; Hisham Khartabil; simple@ietf.org Subject: Re: [Simple] RE: IM delivery reports for conferencing I'll further note that there are some bright young lads in OMA who want to use IMDN as a billing mechanism. If you send an IMDN, the sender gets billed for sending you the message, and if you don't, the billing system will presume the message was lost in transit and presumably not bill. This would appear to make IMDN both mandatory and something that couldn't be driven from a UA. I maintain IMDN is a bad idea. It gives people bad ideas. -- Dean On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for=20 > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. =20 > However, > I don't believe the sender should really be in control of this facet=20 > of delivery notifications. In fact if you build in aggregation support > now rather than later, than you don't even need to negotiate this. (I=20 > propose making receiving aggregated DN support at the sender > mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the=20 >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter=20 > makes more sense. The question is do we need such feature? and if we=20 > do, to allow the sender of the IM to choose which mode or reporting=20 > s/he wanted (aggregated or one by one)? If the answer to the first=20 > question is yes, then I strongly believe that the answer to the second > question is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM=20 >>> conferencing where a single IM may have multiple recipients. My=20 >>> suggestion is that the schema you choose for the notification allow=20 >>> multiple delivery notifications to be batched together with each=20 >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is=20 >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking=20 >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be=20 >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 22:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRgUF-0005UO-RF; Thu, 06 Apr 2006 22:14:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRgUE-0005UJ-IS for simple@ietf.org; Thu, 06 Apr 2006 22:14:10 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRgUE-00007V-2I for simple@ietf.org; Thu, 06 Apr 2006 22:14:10 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k372E4Qb069652 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 21:14:05 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <8F4906E3-151C-4F97-8C0F-ED169E8CFAD2@softarmor.com> References: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> <8F4906E3-151C-4F97-8C0F-ED169E8CFAD2@softarmor.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0F6A88A9-086F-4548-98B9-132C1D16BADA@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Thu, 6 Apr 2006 21:13:56 -0500 To: Dean Willis X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: simple@ietf.org, "Burger, Eric" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 6, 2006, at 6:26 PM, Dean Willis wrote: > > I'll further note that there are some bright young lads in OMA who > want to use IMDN as a billing mechanism. If you send an IMDN, the > sender gets billed for sending you the message, and if you don't, > the billing system will presume the message was lost in transit and > presumably not bill. This would appear to make IMDN both mandatory > and something that couldn't be driven from a UA. > > I maintain IMDN is a bad idea. It gives people bad ideas. > Babies and bathwater. I suspect there are very few protocol mechanisms that no-one has tried to abuse. As long as we don't try to accept these "abuse cases" as requirements, we should be fine. In the case of your particular example, one of our working IMDN requirements is that the receiving endpoint must not send an IMDN unless its user approves. That makes it pretty useless for billing. > -- > Dean > > On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > >> I would offer that it MUST be driven by the client - they are the >> only >> one that knows whether they care. C.f. the use of notifications for >> MSRP conferencing. >> >> -----Original Message----- >> From: Sean Olson [mailto:Sean.Olson@microsoft.com] >> Sent: Monday, March 20, 2006 4:58 PM >> To: Hisham Khartabil >> Cc: Burger, Eric; simple@ietf.org >> Subject: RE: IM delivery reports for conferencing >> >> Well, my opinion obviously is that we do need this capability. >> However, >> I don't believe the sender should really be in control of this >> facet of >> delivery notifications. In fact if you build in aggregation >> support now >> rather than later, than you don't even need to negotiate this. (I >> propose making receiving aggregated DN support at the sender >> mandatory) >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Monday, March 20, 2006 1:52 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: >> >>> The URI attribute only works if you structure the rest of the >>> information around it.... Are you suggesting aggregation by >>> multipart >>> MIME or creating a new top-level XML element? >> >> I have suggested neither. I doesn't matter really although the latter >> makes more sense. The question is do we need such feature? and if >> we do, >> to allow the sender of the IM to choose which mode or reporting s/he >> wanted (aggregated or one by one)? If the answer to the first >> question >> is yes, then I strongly believe that the answer to the second >> question >> is also yes. >> >> Hisham >> >>> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Wednesday, March 15, 2006 1:49 PM >>> To: Sean Olson >>> Cc: eburger@brooktrout.com; simple@ietf.org >>> Subject: Re: IM delivery reports for conferencing >>> >>> >>> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >>> >>>> >>>> Looking at: >>>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>>> -00.tx >>>> t >>>> And: http://tools.ietf.org/wg/simple/draft-burger-simple- >>>> imdn-03.txt >>>> >>>> Neither seems to address the use case of an "exploder" or IM >>>> conferencing where a single IM may have multiple recipients. My >>>> suggestion is that the schema you choose for the notification allow >>>> multiple delivery notifications to be batched together with each >>>> entry >>> >>>> distringuished by the recipient URI. >>> >>> It does address it to an extent. That's what the "uri" attribute is >>> there for. If we want to allow aggregation of receipts before >>> sending >>> the receipt to the IM sender, then we also need to start thinking >>> about what the sender wants and how to indicate it in the IM itself. >>> >>> Hisham >>> >>>> >>>> For example: >>>> >>>> For Draft-khartabil-simple-im-receipts-00 >>>> >>>> >>>> 34jk324j >>>> >>>> read >>>> 200 >>>> The message has been read >>>> >>>> >>>> error >>>> 415 >>>> The message could not be >>>> delivered >>>> >>>> >>>> >>>> Or, for Draft-burger-simple-imdn-03 >>>> >>>> >>>> >>>> 1542af3e8b@eburger@example.com >>>> >>>> >>>> >>>> im:hisham.khartabil@example.net >>>> >>>> read >>>> >>>> >>>> >>>> im:eric.burger@example.net >>>> >>>> read >>>> >>>> >>>> >>>> Sorry if this has been discussed before. Was there a reason this >>>> was >>>> omitted previously? >>>> >>>> Thanks, >>>> Sean >>>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 22:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRh61-0003kQ-GC; Thu, 06 Apr 2006 22:53:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRh5z-0003kL-KZ for simple@ietf.org; Thu, 06 Apr 2006 22:53:11 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRh5z-0001Av-4M for simple@ietf.org; Thu, 06 Apr 2006 22:53:11 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k372r6a9078414 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 6 Apr 2006 21:53:07 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Thu, 6 Apr 2006 21:52:59 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It seems like we are going around in circles on this one. We spent a good bit of time discussing this in the design team meeting. Aggregation creates a huge amount of complexity. You have to worry about how long an aggregator is willing to wait to get all the possible IMDNs. The amount of time it may take for an IMDN to come back is effectively unbounded. What does an aggregator do with IMDNs that come back days later? Are we going to require all exploders device to statefully aggregate IMDNs? That can create a lot of state. Or, if we follow one of Sean's previous suggestions and allow exploders to send multiple batches (which I assume allows for batch sizes of 1), then UAC's have to deal with the possibility of receiving multiple IMDNs from a single message. That is, clients are no simpler to implement than they would be if we did not have aggregation at all. In fact, they are more complex because they have to deal with parsing the aggregated format. IMHO, if we include aggregation as an intrinsic part of IMDN, we greatly reduce our chance of finishing IMDN in any relevant timeframe. My preference is to make aggregation support optional at the client. In a separate spec. That does not block completion of the rest of IMDN. SIP has perfectly good mechanisms for signaling such support. Bottom line: We should start out with the simplest mechanism that can possibly work. Ben. On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. > However, > I don't believe the sender should really be in control of this > facet of > delivery notifications. In fact if you build in aggregation support > now > rather than later, than you don't even need to negotiate this. (I > propose making receiving aggregated DN support at the sender > mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter > makes more sense. The question is do we need such feature? and if > we do, > to allow the sender of the IM to choose which mode or reporting s/he > wanted (aggregated or one by one)? If the answer to the first question > is yes, then I strongly believe that the answer to the second question > is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM >>> conferencing where a single IM may have multiple recipients. My >>> suggestion is that the schema you choose for the notification allow >>> multiple delivery notifications to be batched together with each >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 06 23:14:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRhQ5-0005cV-Hu; Thu, 06 Apr 2006 23:13:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRhQ4-0005cN-5o for simple@ietf.org; Thu, 06 Apr 2006 23:13:56 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRhQ2-0001kj-RA for simple@ietf.org; Thu, 06 Apr 2006 23:13:56 -0400 Received: from [192.168.0.105] ([71.240.162.175]) (authenticated bits=0) by nostrum.com (8.13.4/8.13.4) with ESMTP id k373Drb5099204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 6 Apr 2006 22:13:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v746.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Thu, 6 Apr 2006 22:13:51 -0500 To: "simple@ietf.org list" X-Mailer: Apple Mail (2.746.3) Received-SPF: pass (nostrum.com: 71.240.162.175 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org If you haven't sent comments, please do so now. RjS On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: > This is a SIMPLE working group Last Call for Comments on draft-ietf- > simple-xcap-09. > > This last call ends in two weeks - April 10, 2006 > > The previous version of this draft was approved for publication, > but was removed > from the RFC editor's queue to address a technical issue with > conditional inserts. > The group also agreed to incorporate several clarifying text > changes while the document > was open. > > Please review the changes carefully and send feedback to the SIMPLE > list, copying > Jonathan. > > RjS > > On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the SIP for Instant Messaging and >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : The Extensible Markup Language (XML) Configuration >> Access Protocol (XCAP) >> Author(s) : J. Rosenberg >> Filename : draft-ietf-simple-xcap-09.txt >> Pages : 68 >> Date : 2006-3-23 >> >> This specification defines the Extensible Markup Language (XML) >> Configuration Access Protocol (XCAP). XCAP allows a client to read, >> write and modify application configuration data, stored in XML format >> on a server. XCAP maps XML document sub-trees and element attributes >> to HTTP URIs, so that these components can be directly accessed by >> HTTP. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- >> announce >> to change your subscription settings. >> >> >> 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-simple-xcap-09.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: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-xcap-09.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. >> Content-Type: text/plain >> Content-ID: <2006-3-23150339.I-D@ietf.org> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 01:33:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRja9-00068F-C5; Fri, 07 Apr 2006 01:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRja7-00064w-AY for simple@ietf.org; Fri, 07 Apr 2006 01:32:27 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRja5-0005yy-88 for simple@ietf.org; Fri, 07 Apr 2006 01:32:27 -0400 Received: from mailout6.microsoft.com ([157.54.69.150]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 22:32:14 -0700 Received: from tuk-hub-04.redmond.corp.microsoft.com ([157.54.70.30]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 22:32:13 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 22:32:13 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Apr 2006 22:32:13 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Simple] RE: IM delivery reports for conferencing Date: Thu, 6 Apr 2006 22:32:12 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C61506FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: IM delivery reports for conferencing Thread-Index: AcZZ7mvORF/ukHxmTgKg7wovfZiPcwAFXzRc References: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> From: "Sean Olson" To: "Ben Campbell" , "Burger, Eric" X-OriginalArrivalTime: 07 Apr 2006 05:32:13.0207 (UTC) FILETIME=[9FAF4270:01C65A04] X-Spam-Score: 0.1 (/) X-Scan-Signature: 680445c3afe8c9e96925f2dfef141924 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1181718505==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1181718505== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65A04.9F6ADADE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65A04.9F6ADADE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Aggregation is not trivial, I would agree. In fact, I would argue that = solving the trivial 2-party problem is not solving any problem at all. I = see almost zero value in IMDN for simple 2-party conversations -- can = you demonstrate otherwise? I'm willing to put some effort in to define = how aggregation works. Do you think it is intractable to solve in 3-6 = months? -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net] Sent: Thu 4/6/2006 7:52 PM To: Burger, Eric Cc: Sean Olson; Hisham Khartabil; simple@ietf.org Subject: Re: [Simple] RE: IM delivery reports for conferencing =20 It seems like we are going around in circles on this one. We spent a good bit of time discussing this in the design team =20 meeting. Aggregation creates a huge amount of complexity. You have =20 to worry about how long an aggregator is willing to wait to get all =20 the possible IMDNs. The amount of time it may take for an IMDN to =20 come back is effectively unbounded. What does an aggregator do with =20 IMDNs that come back days later? Are we going to require all =20 exploders device to statefully aggregate IMDNs? That can create a lot =20 of state. Or, if we follow one of Sean's previous suggestions and allow =20 exploders to send multiple batches (which I assume allows for batch =20 sizes of 1), then UAC's have to deal with the possibility of =20 receiving multiple IMDNs from a single message. That is, clients are =20 no simpler to implement than they would be if we did not have =20 aggregation at all. In fact, they are more complex because they have =20 to deal with parsing the aggregated format. IMHO, if we include aggregation as an intrinsic part of IMDN, we =20 greatly reduce our chance of finishing IMDN in any relevant =20 timeframe. My preference is to make aggregation support optional at =20 the client. In a separate spec. That does not block completion of the =20 rest of IMDN. SIP has perfectly good mechanisms for signaling such =20 support. Bottom line: We should start out with the simplest mechanism that can =20 possibly work. Ben. On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. =20 > However, > I don't believe the sender should really be in control of this =20 > facet of > delivery notifications. In fact if you build in aggregation support =20 > now > rather than later, than you don't even need to negotiate this. (I > propose making receiving aggregated DN support at the sender =20 > mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter > makes more sense. The question is do we need such feature? and if =20 > we do, > to allow the sender of the IM to choose which mode or reporting s/he > wanted (aggregated or one by one)? If the answer to the first question > is yes, then I strongly believe that the answer to the second question > is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM >>> conferencing where a single IM may have multiple recipients. My >>> suggestion is that the schema you choose for the notification allow >>> multiple delivery notifications to be batched together with each >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C65A04.9F6ADADE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Simple] RE: IM delivery reports for conferencing

Aggregation is not trivial, I would agree. In fact, I = would argue that solving the trivial 2-party problem is not solving any = problem at all. I see almost zero value in IMDN for simple 2-party = conversations -- can you demonstrate otherwise? I'm willing to put some = effort in to define how aggregation works. Do you think it is = intractable to solve in 3-6 months?


-----Original Message-----
From: Ben Campbell [mailto:ben@estacado.net]
Sent: Thu 4/6/2006 7:52 PM
To: Burger, Eric
Cc: Sean Olson; Hisham Khartabil; simple@ietf.org
Subject: Re: [Simple] RE: IM delivery reports for conferencing

It seems like we are going around in circles on this one.

We spent a good bit of time discussing this in the design team 
meeting.  Aggregation creates a huge amount of complexity. You = have 
to worry about how long an aggregator is willing to wait to get = all 
the possible IMDNs. The amount of time it may take for an IMDN = to 
come back is effectively unbounded. What does an aggregator do = with 
IMDNs that come back days later? Are we going to require all 
exploders device to statefully aggregate IMDNs? That can create a = lot 
of state.

Or, if we follow one of Sean's previous suggestions and allow 
exploders to send multiple batches (which I assume allows for = batch 
sizes of 1), then UAC's have to deal with the possibility of 
receiving multiple IMDNs from a single message. That is, clients = are 
no simpler to implement than they would be if we did not have 
aggregation at all. In fact, they are more complex because they = have 
to deal with parsing the aggregated format.

IMHO, if we include aggregation as an intrinsic part of IMDN, = we 
greatly reduce our chance of finishing IMDN in any relevant 
timeframe. My preference is to make aggregation support optional = at 
the client. In a separate spec. That does not block completion of = the 
rest of IMDN. SIP has perfectly good mechanisms for signaling = such 
support.

Bottom line: We should start out with the simplest mechanism that = can 
possibly work.

Ben.


On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote:

> I would offer that it MUST be driven by the client - they are the = only
> one that knows whether they care.  C.f. the use of = notifications for
> MSRP conferencing.
>
> -----Original Message-----
> From: Sean Olson [mailto:Sean.Olson@microsoft.com<= /A>]
> Sent: Monday, March 20, 2006 4:58 PM
> To: Hisham Khartabil
> Cc: Burger, Eric; simple@ietf.org
> Subject: RE: IM delivery reports for conferencing
>
> Well, my opinion obviously is that we do need this = capability. 
> However,
> I don't believe the sender should really be in control of = this 
> facet of
> delivery notifications. In fact if you build in aggregation = support 
> now
> rather than later, than you don't even need to negotiate this. = (I
> propose making receiving aggregated DN support at the = sender 
> mandatory)
>
> -----Original Message-----
> From: Hisham Khartabil [mailto:hisham.khartabil@telio.n= o]
> Sent: Monday, March 20, 2006 1:52 PM
> To: Sean Olson
> Cc: eburger@brooktrout.com; simple@ietf.org
> Subject: Re: IM delivery reports for conferencing
>
>
> On Mar 20, 2006, at 10:41 PM, Sean Olson wrote:
>
>> The URI attribute only works if you structure the rest of = the
>> information around it.... Are you suggesting aggregation by = multipart
>> MIME or creating a new top-level XML element?
>
> I have suggested neither. I doesn't matter really although the = latter
> makes more sense. The question is do we need such feature? and = if 
> we do,
> to allow the sender of the IM to choose which mode or reporting = s/he
> wanted (aggregated or one by one)? If the answer to the first = question
> is yes, then I strongly believe that the answer to the second = question
> is also yes.
>
> Hisham
>
>>
>> -----Original Message-----
>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.n= o]
>> Sent: Wednesday, March 15, 2006 1:49 PM
>> To: Sean Olson
>> Cc: eburger@brooktrout.com; simple@ietf.org
>> Subject: Re: IM delivery reports for conferencing
>>
>>
>> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote:
>>
>>>
>>> Looking at:
>>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts=
>>> -00.tx
>>> t
>>> And: = http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt
>>>
>>> Neither seems to address the use case of an = "exploder" or IM
>>> conferencing where a single IM may have multiple = recipients. My
>>> suggestion is that the schema you choose for the = notification allow
>>> multiple delivery notifications to be batched together with = each
>>> entry
>>
>>> distringuished by the recipient URI.
>>
>> It does address it to an extent. That's what the = "uri" attribute is
>> there for. If we want to allow aggregation of receipts before = sending
>> the receipt to the IM sender, then we also need to start = thinking
>> about what the sender wants and how to indicate it in the IM = itself.
>>
>> Hisham
>>
>>>
>>> For example:
>>>
>>> For Draft-khartabil-simple-im-receipts-00
>>>
>>>          = <status-receipt>
>>>          &= nbsp;  <message-id>34jk324j</message-id>
>>>          &= nbsp;  <recipient uri=3D"bob@example.com">
>>>          &= nbsp;       = <type>read</type>
>>>          &= nbsp;       = <status>200</status>
>>>          &= nbsp;       <note = lang=3D"en">The message has been read</note>
>>>          &= nbsp;  </recipient>
>>>          &= nbsp;  <recipient uri=3D"alice@example.com">
>>>          &= nbsp;       = <type>error</type>
>>>          &= nbsp;       = <status>415</status>
>>>          &= nbsp;       <note = lang=3D"en">The message could not be
>>> delivered</note>
>>>          &= nbsp;  </recipient>
>>>          = </status-receipt>
>>>
>>> Or, for Draft-burger-simple-imdn-03
>>>
>>>         = <imdn>
>>>          &= nbsp;  <original-message-id>
>>>          &= nbsp;     1542af3e8b@eburger@example.com
>>>          &= nbsp;  </original-message-id>
>>>          &= nbsp;  <reporting-uas = uri=3D"im:hisham.khartabil@example.net">
>>>          &= nbsp;     <original-recipient-uri>
>>>          &= nbsp;        = im:hisham.khartabil@example.net
>>>          &= nbsp;     </original-recipient-uri>
>>>          &= nbsp;     = <disposition>read</disposition>
>>>          &= nbsp;  </reporting-uas>
>>>          &= nbsp;  <reporting-uas = uri=3D"im:eric.burger@example.net">
>>>          &= nbsp;     <original-recipient-uri>
>>>          &= nbsp;        = im:eric.burger@example.net
>>>          &= nbsp;     </original-recipient-uri>
>>>          &= nbsp;     = <disposition>read</disposition>
>>>          &= nbsp;  </reporting-uas>
>>>         = </imdn>
>>>
>>> Sorry if this has been discussed before. Was there a reason = this was
>>> omitted previously?
>>>
>>> Thanks,
>>> Sean
>>>
>>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.= org/mailman/listinfo/simple

------_=_NextPart_001_01C65A04.9F6ADADE-- --===============1181718505== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1181718505==-- From simple-bounces@ietf.org Fri Apr 07 06:46:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoTn-0008Gr-Om; Fri, 07 Apr 2006 06:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRoTn-0008Gm-1O for simple@ietf.org; Fri, 07 Apr 2006 06:46:15 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRoTl-0007i5-6f for simple@ietf.org; Fri, 07 Apr 2006 06:46:15 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id k37AkAC2023407; Fri, 7 Apr 2006 12:46:10 +0200 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id k37AkAlB004389; Fri, 7 Apr 2006 12:46:10 +0200 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 12:46:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Apr 2006 12:46:08 +0200 Message-ID: <72963DDDF17D7949ABD18DC5DA58E770EE22AE@MCHP7R5A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC : draft-ietf-simple-xcap-09.txt, some comments Thread-Index: AcZZ8VSwaH01EEkJS7aSC2XZ95YE4wAHbugA From: "Schmidt, Christian" To: "Jonathan Rosenberg" , "Robert Sparks" , X-OriginalArrivalTime: 07 Apr 2006 10:46:09.0929 (UTC) FILETIME=[7B3EEF90:01C65A30] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: Subject: [Simple] WGLC : draft-ietf-simple-xcap-09.txt, some comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Jonathan, here some comments to version 09 of the draft: Best Regards Christian Schmidt 6.2 Document Selector: Comment: The example "http://xcap.example.com/services/resource-lists" = is in violation with the recommendation specified in section 6.1, = stating that the XCAP Root is recommended to be "http://xcap.". = Hence the example should be "http://xcap.example.com/resource-lists". 6.3 Node Selector: Text in Verion 09: "Unfortunately, the characters permitted by these productions include some that are not allowed for pchar, which is the production for the allowed set of characters in path segments in the URI. The AttValue production allows many such characters within the US-ASCII set, including the space. Those characters MUST be percent- encoded when placed in the URI. Furthermore, QName and AttValue allow many Unicode characters, outside of US-ASCII. When these characters need to be represented in the HTTP URI, they are percent- encoded. To do this, the data should be encoded first as octets according to the UTF-8 character encoding [18] and then only those octets that do not correspond to characters in the unreserved set should be percent-encoded. For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2"." Comment: As first stated, a path segments allows all characters that are = part of the pchar set. Other characters need to be percent-encoded. = Hence, the actual description of how to transform data into a valid path = segment should state: Textproposal: "To do this, the data should be encoded first as octets according to = the UTF-8 character encoding [18] and then only those octets that do not = correspond to the pchar set should be percent-encoded."=20 Editorial Comment: Page 21: Last Paragraph: Selection 8.2.3) > Selection 8.2.3 7.4. Create or Replace an Element, page 27, first paragraph Text in Verion 09: "The "*" indicates that all element children of are to be considered when computing the position for insertion. If, instead of a wildcard *, an element name (QName) was present, the expression above would insert the new element as the position-th element amongst those with the same expanded name." =20 Comment: A reference to Section 8.2.3 should be added here with respect = to how insertions are done. Text in Verion 09: "To be certain that element insertions have the GET(PUT(x))=3D=3Dx property, the client can check that the attribute predicates in the final path segment of the URI match the attributes of the element in the body of the request. As an example of an request that would not have this property and therefore not be idempotent, consider the following PUT request (URIs are line-folded for readability): PUT /rls-services/users/bill/index/~~/rls-services/ service%5b@uri=3D%22sip:good-friends@example.com%5d HTTP/1.1 Content-Type:application/xcap-el+xml Host: xcap.example.com http://xcap.example.com/resource-lists/users/joe /index/~~/resource-lists/list%5b@name=3D%22l1%22%5d presence This request will fail with a 409. The Request URI contains a final path segment with a predicate based on attributes - @uri=3D"sip:good-friends@example.com". However, this will not match the value of the "uri" attribute in the element in the body." Comment: A note should be added to make the implications of the = idempotent restriction clear. I.e. it will not be possible to replace an = element with one that has a new value for an attribute that is the sole = unique element identifier using a request URI that contains a node = selector that holds the current attribute value to identify the element = (as presented in the example). The only way around it would be to = specify the position instead of the attribute value in the node selector = (i.e. for the example the following request URI would work taking that = the element is the 2nd element: = /rls-services/users/bill/index/~~/rls-services/service%5b2%5d ). 7.7 Create or Replace an Attribute Text in Verion 09: "To be certain that attribute insertions have the GET(PUT(x))=3D=3Dx property, the client can check that any attribute predicate in the path segment that selects the element into which the attribute is inserted, matches a different attribute than the one being inserted by the request. As an example of a request that would not have this property and therefore not be idempotent, consider the following PUT request (URIs are line folded for readability): PUT /rls-services/users/bill/index/~~/ rls-services/service%5b@uri=3D%22sip:good-friends@example.com%5d/@uri HTTP/1.1 Content-Type:application/xcap-att+xml Host: xcap.example.com "sip:bad-friends@example.com" This request will fail with a 409." Comment: A note should be added to make the implications of the = idempotent restriction clear. I.e. is will not be possible to replace = the attribute value of an attribute that is the sole unique element = identifier using a request URI that contains a node selector that holds = the current attribute value to identify the parent element (as presented = in the example). The only way around it would be to specify the position = instead of the attribute value in the node selector (i.e. for the = example the following request URI would work taking that the parent = element is the 2nd element: = /rls-services/users/bill/index/~~/rls-services/service%5b2%5d/@uri ). 8.2.1 Locating the Parent "If the parent URI has no node selector separator, it is referring to the directory into which the document should be inserted. If this directory does not exist, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the element. Detailed conflict reports are discussed in Section 11. If the directory does exist, the server checks to see if there is a document with the same filename as the target node. If there is, the operation is the replacement operation discussed in Section 8.2.4. If it does not exist, it is the creation operation, discussed in Section 8.2.4." Comment: As the XCAP protocol does not provide the means to create a = directory, it is not possible to have a directory structure in the = document selector and thus all documents are present in either to global = directory or the home directory (and never in a subdirectory of the = global or home directory). The only way to have one or more = subdirectories in the document selector is when the application usage = requires the existence of such subdirectories, which is in my view very = unlikely. This should be noted. Comment: The last reference should be replaced by 8.2.3. The same, at = first line in page 35. 8.2.7 Resource Interdependencies Text in Verion 09: "If the creation or replacement was successful, and the resource interdependencies are resolved, the server returns a 201 Created or or 200 OK, respectively. Note that a 201 Created is generated for creation of new documents, elements, or attributes. A 200 OK response to PUT MUST not contain any content." Comment: And what about the 201 Created? What should the content be of = the 201 Created? Should it e.g. contain the XCAP URI identifying the = just created document, element or attribute (in line with RFC 2616]? =20 8.4 DELETE Handling Text in Verion 09: "GET operations can be conditional, and follow the procedures defined in [6]." Comment: Replace GET by DELETE 8.5 Managing Etags Text in Verion 09: "In the case of a DELETE, the entity tag refers to the value of the entity tag for all other resources after the deletion of the specified resource has occurred. One way to think about this is that the server is, logically speaking, re-instantiating the resource for a brief instant, so that it can have an entity tag that can be reasonably returned in the response to DELETE." Comment: This would be correct when deleting elements or attributes. But = there is no sense in creating and returning an ETag when the whole = document is deleted! 11.1 Document Structure Proposal for a modified definition: : This indicates that an attempt to insert a document, = element, or attribute failed because the directory, document or element = into which the insertion was supposed to occur does not exist. This error element can contain an optional element, which provides an HTTP URI of the xcap resource that identifies the closest ancestor that does exist. This HTTP URI MAY be a relative URI, relative to the document itself. Because this is a valid HTTP URI, its node selector component MUST be percent-encoded. Comment: Note that if the element must contain a HTTP URI = identifying an xcap resource, then it can never indicate a directory = (for e.g. the case in which the create of a document failed because the = parent directory does not exist). 12. XCAP Server Capabilities Proposal for enhanced text: The structure of the document is simple. The root element is . Its children are , , and . Each of these contain a list of AUIDs, extensions and namespaces supported by the server. Extensions are named by tokens defined by the extension, and typically define new selectors. Namespaces are identified by their namespace URI. Since all XCAP servers support the "xcap-caps" AUID, it MUST be listed in the element and=20 the "urn:ietf:params:xml:ns:xcap-caps" namespace MUST be listed in the element. Comment: It doesn't seem to be a good idea to list the supported = namespaces unrelated to the AUIDs. When an XCAP server supports multiple = application usages. All namespaces of all supported application usages = are returned as just one list. From this one list, the XCAP client can = not determine which namespaces are supported for which application = usages. 13. Examples Comment: The '/services' is to be removed in line with the = recommendation of section 6.1. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Urspr=FCngliche Nachricht----- Von: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Gesendet: Freitag, 7. April 2006 05:14 An: simple@ietf.org list Betreff: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt=20 If you haven't sent comments, please do so now. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 09:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqvU-0004gr-EG; Fri, 07 Apr 2006 09:23:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRqvS-0004gm-Pi for simple@ietf.org; Fri, 07 Apr 2006 09:22:58 -0400 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRqvS-0004Kv-AB for simple@ietf.org; Fri, 07 Apr 2006 09:22:58 -0400 X-IronPort-AV: i="4.04,96,1144036800"; d="scan'208"; a="31133705:sNHT84149144" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: IM delivery reports for conferencing Date: Fri, 7 Apr 2006 09:14:36 -0400 Message-ID: <330A23D8336C0346B5C1A5BB19666647029AF7CC@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: IM delivery reports for conferencing Thread-Index: AcZZ7snC+US312lKQ7il31RMTs8wCQAVkdIg From: "Burger, Eric" To: "Ben Campbell" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Client cannot do aggregation, as it has no clue why it is getting bombarded with dozens of IMDN's for the single message it sent. That said, I agree, we should not do aggregations in the initial release of IMDN, but leave it as an exercise for the reader (and future standardization work) for how a B2BUA could do aggregation. -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Thursday, April 06, 2006 10:53 PM To: Burger, Eric Cc: simple@ietf.org Subject: Re: [Simple] RE: IM delivery reports for conferencing It seems like we are going around in circles on this one. We spent a good bit of time discussing this in the design team =20 meeting. Aggregation creates a huge amount of complexity. You have =20 to worry about how long an aggregator is willing to wait to get all =20 the possible IMDNs. The amount of time it may take for an IMDN to =20 come back is effectively unbounded. What does an aggregator do with =20 IMDNs that come back days later? Are we going to require all =20 exploders device to statefully aggregate IMDNs? That can create a lot =20 of state. Or, if we follow one of Sean's previous suggestions and allow =20 exploders to send multiple batches (which I assume allows for batch =20 sizes of 1), then UAC's have to deal with the possibility of =20 receiving multiple IMDNs from a single message. That is, clients are =20 no simpler to implement than they would be if we did not have =20 aggregation at all. In fact, they are more complex because they have =20 to deal with parsing the aggregated format. IMHO, if we include aggregation as an intrinsic part of IMDN, we =20 greatly reduce our chance of finishing IMDN in any relevant =20 timeframe. My preference is to make aggregation support optional at =20 the client. In a separate spec. That does not block completion of the =20 rest of IMDN. SIP has perfectly good mechanisms for signaling such =20 support. Bottom line: We should start out with the simplest mechanism that can =20 possibly work. Ben. On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > I would offer that it MUST be driven by the client - they are the only > one that knows whether they care. C.f. the use of notifications for > MSRP conferencing. > > -----Original Message----- > From: Sean Olson [mailto:Sean.Olson@microsoft.com] > Sent: Monday, March 20, 2006 4:58 PM > To: Hisham Khartabil > Cc: Burger, Eric; simple@ietf.org > Subject: RE: IM delivery reports for conferencing > > Well, my opinion obviously is that we do need this capability. =20 > However, > I don't believe the sender should really be in control of this =20 > facet of > delivery notifications. In fact if you build in aggregation support =20 > now > rather than later, than you don't even need to negotiate this. (I > propose making receiving aggregated DN support at the sender =20 > mandatory) > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: Monday, March 20, 2006 1:52 PM > To: Sean Olson > Cc: eburger@brooktrout.com; simple@ietf.org > Subject: Re: IM delivery reports for conferencing > > > On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: > >> The URI attribute only works if you structure the rest of the >> information around it.... Are you suggesting aggregation by multipart >> MIME or creating a new top-level XML element? > > I have suggested neither. I doesn't matter really although the latter > makes more sense. The question is do we need such feature? and if =20 > we do, > to allow the sender of the IM to choose which mode or reporting s/he > wanted (aggregated or one by one)? If the answer to the first question > is yes, then I strongly believe that the answer to the second question > is also yes. > > Hisham > >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Wednesday, March 15, 2006 1:49 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >> >>> >>> Looking at: >>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>> -00.tx >>> t >>> And: http://tools.ietf.org/wg/simple/draft-burger-simple-imdn-03.txt >>> >>> Neither seems to address the use case of an "exploder" or IM >>> conferencing where a single IM may have multiple recipients. My >>> suggestion is that the schema you choose for the notification allow >>> multiple delivery notifications to be batched together with each >>> entry >> >>> distringuished by the recipient URI. >> >> It does address it to an extent. That's what the "uri" attribute is >> there for. If we want to allow aggregation of receipts before sending >> the receipt to the IM sender, then we also need to start thinking >> about what the sender wants and how to indicate it in the IM itself. >> >> Hisham >> >>> >>> For example: >>> >>> For Draft-khartabil-simple-im-receipts-00 >>> >>> >>> 34jk324j >>> >>> read >>> 200 >>> The message has been read >>> >>> >>> error >>> 415 >>> The message could not be >>> delivered >>> >>> >>> >>> Or, for Draft-burger-simple-imdn-03 >>> >>> >>> >>> 1542af3e8b@eburger@example.com >>> >>> >>> >>> im:hisham.khartabil@example.net >>> >>> read >>> >>> >>> >>> im:eric.burger@example.net >>> >>> read >>> >>> >>> >>> Sorry if this has been discussed before. Was there a reason this was >>> omitted previously? >>> >>> Thanks, >>> Sean >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 09:48:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrJf-0006rl-U0; Fri, 07 Apr 2006 09:47:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrJe-0006mx-QJ for simple@ietf.org; Fri, 07 Apr 2006 09:47:58 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRrJc-0005AL-EZ for simple@ietf.org; Fri, 07 Apr 2006 09:47:58 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k37DlqYi026699 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 7 Apr 2006 08:47:52 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <65F27F597EB1E44384BA802189D334C61506FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <330A23D8336C0346B5C1A5BB19666647027B03BA@ATLANTIS.Brooktrout.com> <65F27F597EB1E44384BA802189D334C61506FF@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A1BF31B-537A-4DF1-A68B-182A1EF15CD9@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Fri, 7 Apr 2006 08:47:46 -0500 To: Sean Olson X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: simple@ietf.org, "Burger, Eric" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 7, 2006, at 12:32 AM, Sean Olson wrote: > Aggregation is not trivial, I would agree. In fact, I would argue > that solving the trivial 2-party problem is not solving any problem > at all. I see almost zero value in IMDN for simple 2-party > conversations -- can you demonstrate otherwise? I'm willing to put > some effort in to define how aggregation works. Do you think it is > intractable to solve in 3-6 months? > > I do have use cases for 2 party, the most compelling of which are store-and-forward intermediaries. But I am not arguing that we limit ourselves to the 2 party case. What I don't want to solve right now (read: don't want to block the rest of IMDN on solving it) is IMDN aggregation at an intermediary. I am more than happy to say that the UAC must be prepared to receive multiple IMDNs for a single message. Then we can add intermediary aggregation in as an extension, to which a client would have to indicate support. As far as "solving in 3-6 months", I offer up the example of how hard it was to agree on the REPORT mechanism in MSRP. It is not that it is hard to come up with a solution that works so much as it is hard to come up with a solution that everyone agrees on. It is possible that I am just still traumatized over MSRP :-) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 09:49:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrKn-0008E2-Tx; Fri, 07 Apr 2006 09:49:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrKm-0008Dx-Tv for simple@ietf.org; Fri, 07 Apr 2006 09:49:08 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRrKl-0005Bh-DE for simple@ietf.org; Fri, 07 Apr 2006 09:49:08 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k37Dn4Xx026831 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 7 Apr 2006 08:49:04 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <330A23D8336C0346B5C1A5BB19666647029AF7CC@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647029AF7CC@ATLANTIS.Brooktrout.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C537030-3585-4030-B672-8DD54222D817@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Fri, 7 Apr 2006 08:48:58 -0500 To: "Burger, Eric" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 7, 2006, at 8:14 AM, Burger, Eric wrote: > Client cannot do aggregation, as it has no clue why it is getting > bombarded with dozens of IMDN's for the single message it sent. > It does not have to know why. It just has to know it could happen. > That said, I agree, we should not do aggregations in the initial > release > of IMDN, but leave it as an exercise for the reader (and future > standardization work) for how a B2BUA could do aggregation. Oh, well, I will quit arguing with you then :-) > > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Thursday, April 06, 2006 10:53 PM > To: Burger, Eric > Cc: simple@ietf.org > Subject: Re: [Simple] RE: IM delivery reports for conferencing > > It seems like we are going around in circles on this one. > > We spent a good bit of time discussing this in the design team > meeting. Aggregation creates a huge amount of complexity. You have > to worry about how long an aggregator is willing to wait to get all > the possible IMDNs. The amount of time it may take for an IMDN to > come back is effectively unbounded. What does an aggregator do with > IMDNs that come back days later? Are we going to require all > exploders device to statefully aggregate IMDNs? That can create a lot > of state. > > Or, if we follow one of Sean's previous suggestions and allow > exploders to send multiple batches (which I assume allows for batch > sizes of 1), then UAC's have to deal with the possibility of > receiving multiple IMDNs from a single message. That is, clients are > no simpler to implement than they would be if we did not have > aggregation at all. In fact, they are more complex because they have > to deal with parsing the aggregated format. > > IMHO, if we include aggregation as an intrinsic part of IMDN, we > greatly reduce our chance of finishing IMDN in any relevant > timeframe. My preference is to make aggregation support optional at > the client. In a separate spec. That does not block completion of the > rest of IMDN. SIP has perfectly good mechanisms for signaling such > support. > > Bottom line: We should start out with the simplest mechanism that can > possibly work. > > Ben. > > > On Mar 20, 2006, at 7:52 PM, Burger, Eric wrote: > >> I would offer that it MUST be driven by the client - they are the >> only >> one that knows whether they care. C.f. the use of notifications for >> MSRP conferencing. >> >> -----Original Message----- >> From: Sean Olson [mailto:Sean.Olson@microsoft.com] >> Sent: Monday, March 20, 2006 4:58 PM >> To: Hisham Khartabil >> Cc: Burger, Eric; simple@ietf.org >> Subject: RE: IM delivery reports for conferencing >> >> Well, my opinion obviously is that we do need this capability. >> However, >> I don't believe the sender should really be in control of this >> facet of >> delivery notifications. In fact if you build in aggregation support >> now >> rather than later, than you don't even need to negotiate this. (I >> propose making receiving aggregated DN support at the sender >> mandatory) >> >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >> Sent: Monday, March 20, 2006 1:52 PM >> To: Sean Olson >> Cc: eburger@brooktrout.com; simple@ietf.org >> Subject: Re: IM delivery reports for conferencing >> >> >> On Mar 20, 2006, at 10:41 PM, Sean Olson wrote: >> >>> The URI attribute only works if you structure the rest of the >>> information around it.... Are you suggesting aggregation by >>> multipart >>> MIME or creating a new top-level XML element? >> >> I have suggested neither. I doesn't matter really although the latter >> makes more sense. The question is do we need such feature? and if >> we do, >> to allow the sender of the IM to choose which mode or reporting s/he >> wanted (aggregated or one by one)? If the answer to the first >> question >> is yes, then I strongly believe that the answer to the second >> question >> is also yes. >> >> Hisham >> >>> >>> -----Original Message----- >>> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] >>> Sent: Wednesday, March 15, 2006 1:49 PM >>> To: Sean Olson >>> Cc: eburger@brooktrout.com; simple@ietf.org >>> Subject: Re: IM delivery reports for conferencing >>> >>> >>> On Mar 15, 2006, at 7:30 PM, Sean Olson wrote: >>> >>>> >>>> Looking at: >>>> http://tools.ietf.org/wg/simple/draft-khartabil-simple-im-receipts >>>> -00.tx >>>> t >>>> And: http://tools.ietf.org/wg/simple/draft-burger-simple- >>>> imdn-03.txt >>>> >>>> Neither seems to address the use case of an "exploder" or IM >>>> conferencing where a single IM may have multiple recipients. My >>>> suggestion is that the schema you choose for the notification allow >>>> multiple delivery notifications to be batched together with each >>>> entry >>> >>>> distringuished by the recipient URI. >>> >>> It does address it to an extent. That's what the "uri" attribute is >>> there for. If we want to allow aggregation of receipts before >>> sending >>> the receipt to the IM sender, then we also need to start thinking >>> about what the sender wants and how to indicate it in the IM itself. >>> >>> Hisham >>> >>>> >>>> For example: >>>> >>>> For Draft-khartabil-simple-im-receipts-00 >>>> >>>> >>>> 34jk324j >>>> >>>> read >>>> 200 >>>> The message has been read >>>> >>>> >>>> error >>>> 415 >>>> The message could not be >>>> delivered >>>> >>>> >>>> >>>> Or, for Draft-burger-simple-imdn-03 >>>> >>>> >>>> >>>> 1542af3e8b@eburger@example.com >>>> >>>> >>>> >>>> im:hisham.khartabil@example.net >>>> >>>> read >>>> >>>> >>>> >>>> im:eric.burger@example.net >>>> >>>> read >>>> >>>> >>>> >>>> Sorry if this has been discussed before. Was there a reason this >>>> was >>>> omitted previously? >>>> >>>> Thanks, >>>> Sean >>>> >>> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 10:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrzW-0002Mj-Bc; Fri, 07 Apr 2006 10:31:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRrzU-0002Mb-LY for simple@ietf.org; Fri, 07 Apr 2006 10:31:12 -0400 Received: from mail1.microsoft.com ([131.107.1.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRrzS-00073A-AT for simple@ietf.org; Fri, 07 Apr 2006 10:31:12 -0400 Received: from mailout5.microsoft.com ([157.54.69.148]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 07:31:09 -0700 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 07:31:08 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by tuk-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 07:31:08 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 07:31:08 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: IM delivery reports for conferencing Date: Fri, 7 Apr 2006 07:31:10 -0700 Message-ID: <65F27F597EB1E44384BA802189D334C642EBD4@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <4A1BF31B-537A-4DF1-A68B-182A1EF15CD9@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] RE: IM delivery reports for conferencing Thread-Index: AcZaSeKqUE7jmQxCTp6O43rBLKFCGwABeGsw From: "Sean Olson" To: "Ben Campbell" X-OriginalArrivalTime: 07 Apr 2006 14:31:08.0257 (UTC) FILETIME=[E8E05510:01C65A4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: simple@ietf.org, "Burger, Eric" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org This works for me (not standardizing how the intermediary aggregates for now) provided we can define the XML schema in such a way that it is straightforward to extend it to the aggregation scenario. -----Original Message----- From: Ben Campbell [mailto:ben@estacado.net]=20 Sent: Friday, April 07, 2006 6:48 AM To: Sean Olson Cc: Burger, Eric; Hisham Khartabil; simple@ietf.org Subject: Re: [Simple] RE: IM delivery reports for conferencing On Apr 7, 2006, at 12:32 AM, Sean Olson wrote: > Aggregation is not trivial, I would agree. In fact, I would argue that > solving the trivial 2-party problem is not solving any problem at all. > I see almost zero value in IMDN for simple 2-party conversations --=20 > can you demonstrate otherwise? I'm willing to put some effort in to=20 > define how aggregation works. Do you think it is intractable to solve=20 > in 3-6 months? > > I do have use cases for 2 party, the most compelling of which are store-and-forward intermediaries. But I am not arguing that we limit ourselves to the 2 party case. What I don't want to solve right now (read: don't want to block the rest of IMDN on solving it) is IMDN aggregation at an intermediary. I am more than happy to say that the UAC must be prepared to receive multiple IMDNs for a single message. Then we can add intermediary aggregation in as an extension, to which a client would have to indicate support. As far as "solving in 3-6 months", I offer up the example of how hard it was to agree on the REPORT mechanism in MSRP. It is not that it is hard to come up with a solution that works so much as it is hard to come up with a solution that everyone agrees on. It is possible that I am just still traumatized over MSRP :-) _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 10:33:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRs20-0002dY-Lz; Fri, 07 Apr 2006 10:33:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRs1z-0002dT-El for simple@ietf.org; Fri, 07 Apr 2006 10:33:47 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRs1z-0007Bv-4R for simple@ietf.org; Fri, 07 Apr 2006 10:33:47 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k37EXh7n037440 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 7 Apr 2006 09:33:43 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <65F27F597EB1E44384BA802189D334C642EBD4@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> References: <65F27F597EB1E44384BA802189D334C642EBD4@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A0F5B51-30FE-402B-9AC5-EF8373ED9822@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] RE: IM delivery reports for conferencing Date: Fri, 7 Apr 2006 09:33:37 -0500 To: "Sean Olson" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: simple@ietf.org, "Burger, Eric" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 7, 2006, at 9:31 AM, Sean Olson wrote: > This works for me (not standardizing how the intermediary > aggregates for > now) provided we can define the XML schema in such a way that it is > straightforward to extend it to the aggregation scenario. > That seems reasonable to me. > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net] > Sent: Friday, April 07, 2006 6:48 AM > To: Sean Olson > Cc: Burger, Eric; Hisham Khartabil; simple@ietf.org > Subject: Re: [Simple] RE: IM delivery reports for conferencing > > > On Apr 7, 2006, at 12:32 AM, Sean Olson wrote: > >> Aggregation is not trivial, I would agree. In fact, I would argue >> that > >> solving the trivial 2-party problem is not solving any problem at >> all. > >> I see almost zero value in IMDN for simple 2-party conversations -- >> can you demonstrate otherwise? I'm willing to put some effort in to >> define how aggregation works. Do you think it is intractable to solve >> in 3-6 months? >> >> > I do have use cases for 2 party, the most compelling of which are > store-and-forward intermediaries. But I am not arguing that we limit > ourselves to the 2 party case. > > What I don't want to solve right now (read: don't want to block the > rest > of IMDN on solving it) is IMDN aggregation at an intermediary. I am > more > than happy to say that the UAC must be prepared to receive multiple > IMDNs for a single message. Then we can add intermediary > aggregation in > as an extension, to which a client would have to indicate support. > > As far as "solving in 3-6 months", I offer up the example of how > hard it > was to agree on the REPORT mechanism in MSRP. It is not that it is > hard > to come up with a solution that works so much as it is hard to come up > with a solution that everyone agrees on. It is possible that I am just > still traumatized over MSRP :-) > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 13:58:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvDe-0002Ju-RL; Fri, 07 Apr 2006 13:58:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRvDe-0002Ip-CA for simple@ietf.org; Fri, 07 Apr 2006 13:58:02 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRvDd-0007gN-Tj for simple@ietf.org; Fri, 07 Apr 2006 13:58:02 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2006 10:58:01 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,98,1144047600"; d="scan'208"; a="25430041:sNHT26896416" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k37Hw1VY005620; Fri, 7 Apr 2006 13:58:01 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 13:58:01 -0400 Received: from [10.86.160.207] ([10.86.160.207]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 13:58:00 -0400 Message-ID: <4436A828.7020206@cisco.com> Date: Fri, 07 Apr 2006 13:58:00 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Robert Sparks Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2006 17:58:00.0919 (UTC) FILETIME=[CF663E70:01C65A6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "simple@ietf.org list" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I have read the draft and think it's fine, with the following note: I agree with the previously noted concerns except for the concern about dots in the custom AUID names, which I really don't see as a problem. -josh Robert Sparks wrote: > If you haven't sent comments, please do so now. > > RjS > > On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: > >> This is a SIMPLE working group Last Call for Comments on >> draft-ietf-simple-xcap-09. >> >> This last call ends in two weeks - April 10, 2006 >> >> The previous version of this draft was approved for publication, but >> was removed >> from the RFC editor's queue to address a technical issue with >> conditional inserts. >> The group also agreed to incorporate several clarifying text changes >> while the document >> was open. >> >> Please review the changes carefully and send feedback to the SIMPLE >> list, copying >> Jonathan. >> >> RjS >> >> On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: >> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the SIP for Instant Messaging and >>> Presence Leveraging Extensions Working Group of the IETF. >>> >>> Title : The Extensible Markup Language (XML) Configuration >>> Access Protocol (XCAP) >>> Author(s) : J. Rosenberg >>> Filename : draft-ietf-simple-xcap-09.txt >>> Pages : 68 >>> Date : 2006-3-23 >>> >>> This specification defines the Extensible Markup Language (XML) >>> Configuration Access Protocol (XCAP). XCAP allows a client to read, >>> write and modify application configuration data, stored in XML format >>> on a server. XCAP maps XML document sub-trees and element attributes >>> to HTTP URIs, so that these components can be directly accessed by >>> HTTP. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt >>> >>> To remove yourself from the I-D Announcement list, send a message to >>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>> of the message. >>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>> to change your subscription settings. >>> >>> >>> 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-simple-xcap-09.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: >>> mailserv@ietf.org. >>> In the body type: >>> "FILE /internet-drafts/draft-ietf-simple-xcap-09.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. >>> Content-Type: text/plain >>> Content-ID: <2006-3-23150339.I-D@ietf.org> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 17:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRyXE-0005Ah-35; Fri, 07 Apr 2006 17:30:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRyXD-0005Ac-Mz for simple@ietf.org; Fri, 07 Apr 2006 17:30:27 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRyXC-0006pj-4B for simple@ietf.org; Fri, 07 Apr 2006 17:30:27 -0400 Received: (qmail 27280 invoked by uid 0); 7 Apr 2006 21:30:23 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Apr 2006 21:30:23 -0000 Message-ID: <005901c65a8a$78b4f670$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: "Josh Littlefield" , "Robert Sparks" References: <4436A828.7020206@cisco.com> Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Fri, 7 Apr 2006 23:30:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Josh, The concern was about dots in global AUIDs. When dots are allowed, there is no syntactical distinction between "global" AUIDs and "vendor-specific" AUIDs, since e.g. "com.example.foo" would also be a valid global AUID If the distinction is not important, then the ABNF should be changed into: AUID = 1*pchar If on the other hand you want to be able to extract the reverse domain part from a vendor-specific AUID, then the syntax should also be changed to be able to detect where the reverse domain part ends and the AUID begins Regards, jeroen ----- Original Message ----- From: "Josh Littlefield" To: "Robert Sparks" Cc: Sent: Friday, April 07, 2006 7:58 PM Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt >I have read the draft and think it's fine, with the following note: I >agree with the previously noted concerns except for the concern about dots >in the custom AUID names, which I really don't see as a problem. > > -josh > > Robert Sparks wrote: >> If you haven't sent comments, please do so now. >> >> RjS >> >> On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: >> >>> This is a SIMPLE working group Last Call for Comments on >>> draft-ietf-simple-xcap-09. >>> >>> This last call ends in two weeks - April 10, 2006 >>> >>> The previous version of this draft was approved for publication, but was >>> removed >>> from the RFC editor's queue to address a technical issue with >>> conditional inserts. >>> The group also agreed to incorporate several clarifying text changes >>> while the document >>> was open. >>> >>> Please review the changes carefully and send feedback to the SIMPLE >>> list, copying >>> Jonathan. >>> >>> RjS >>> >>> On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the SIP for Instant Messaging and Presence >>>> Leveraging Extensions Working Group of the IETF. >>>> >>>> Title : The Extensible Markup Language (XML) Configuration >>>> Access Protocol (XCAP) >>>> Author(s) : J. Rosenberg >>>> Filename : draft-ietf-simple-xcap-09.txt >>>> Pages : 68 >>>> Date : 2006-3-23 >>>> This specification defines the Extensible Markup Language (XML) >>>> Configuration Access Protocol (XCAP). XCAP allows a client to read, >>>> write and modify application configuration data, stored in XML format >>>> on a server. XCAP maps XML document sub-trees and element attributes >>>> to HTTP URIs, so that these components can be directly accessed by >>>> HTTP. >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt >>>> >>>> To remove yourself from the I-D Announcement list, send a message to >>>> i-d-announce-request@ietf.org with the word unsubscribe in the body of >>>> the message. >>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>> to change your subscription settings. >>>> >>>> >>>> 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-simple-xcap-09.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: >>>> mailserv@ietf.org. >>>> In the body type: >>>> "FILE /internet-drafts/draft-ietf-simple-xcap-09.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. >>>> Content-Type: text/plain >>>> Content-ID: <2006-3-23150339.I-D@ietf.org> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 1414 Massachusetts Avenue > tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 07 18:23:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzMO-0008Ob-FG; Fri, 07 Apr 2006 18:23:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRzMM-0008NY-68 for simple@ietf.org; Fri, 07 Apr 2006 18:23:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRzML-0000CO-Jv for simple@ietf.org; Fri, 07 Apr 2006 18:23:18 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 07 Apr 2006 18:23:17 -0400 X-IronPort-AV: i="4.04,99,1144036800"; d="scan'208"; a="85998897:sNHT32696908" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k37MNHVU026797; Fri, 7 Apr 2006 18:23:17 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 18:23:17 -0400 Received: from [161.44.65.139] ([161.44.65.139]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Apr 2006 18:23:16 -0400 Message-ID: <4436E653.9050900@cisco.com> Date: Fri, 07 Apr 2006 18:23:15 -0400 From: Josh Littlefield Organization: Cisco Systems User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Jeroen van Bemmel Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: <4436A828.7020206@cisco.com> <005901c65a8a$78b4f670$31713b51@BEMBUSTER> In-Reply-To: <005901c65a8a$78b4f670$31713b51@BEMBUSTER> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Apr 2006 22:23:16.0409 (UTC) FILETIME=[DDC54A90:01C65A91] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Jeroen van Bemmel wrote: > Josh, > > The concern was about dots in global AUIDs. When dots are allowed, there > is no syntactical distinction between "global" AUIDs and > "vendor-specific" AUIDs, since e.g. "com.example.foo" would also be a > valid global AUID OK, sorry. I was thinking of the part of a vendor AUID to the right of the reverse domain name, not of the global AUID. > > If the distinction is not important, then the ABNF should be changed into: > AUID = 1*pchar > > If on the other hand you want to be able to extract the reverse domain > part from a vendor-specific AUID, then the syntax should also be changed > to be able to detect where the reverse domain part ends and the AUID begins I didn't see the need to extract the reverse domain part from a vendor-specific AUID, since it seemed to me the point was AUID uniqueness, not AUID parsing. Still, if you think it possible that someone will assign a global AUID that would potentially conflict with some vendor's local AUID space, then having dots in global AUIDs is a potential problem. Regards, -josh > Regards, > > jeroen > > ----- Original Message ----- From: "Josh Littlefield" > To: "Robert Sparks" > Cc: > Sent: Friday, April 07, 2006 7:58 PM > Subject: Re: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt > > >> I have read the draft and think it's fine, with the following note: I >> agree with the previously noted concerns except for the concern about >> dots in the custom AUID names, which I really don't see as a problem. >> >> -josh >> >> Robert Sparks wrote: >>> If you haven't sent comments, please do so now. >>> >>> RjS >>> >>> On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: >>> >>>> This is a SIMPLE working group Last Call for Comments on >>>> draft-ietf-simple-xcap-09. >>>> >>>> This last call ends in two weeks - April 10, 2006 >>>> >>>> The previous version of this draft was approved for publication, but >>>> was removed >>>> from the RFC editor's queue to address a technical issue with >>>> conditional inserts. >>>> The group also agreed to incorporate several clarifying text changes >>>> while the document >>>> was open. >>>> >>>> Please review the changes carefully and send feedback to the SIMPLE >>>> list, copying >>>> Jonathan. >>>> >>>> RjS >>>> >>>> On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: >>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the SIP for Instant Messaging and >>>>> Presence Leveraging Extensions Working Group of the IETF. >>>>> >>>>> Title : The Extensible Markup Language (XML) >>>>> Configuration Access Protocol (XCAP) >>>>> Author(s) : J. Rosenberg >>>>> Filename : draft-ietf-simple-xcap-09.txt >>>>> Pages : 68 >>>>> Date : 2006-3-23 >>>>> This specification defines the Extensible Markup Language (XML) >>>>> Configuration Access Protocol (XCAP). XCAP allows a client to read, >>>>> write and modify application configuration data, stored in XML format >>>>> on a server. XCAP maps XML document sub-trees and element attributes >>>>> to HTTP URIs, so that these components can be directly accessed by >>>>> HTTP. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt >>>>> >>>>> To remove yourself from the I-D Announcement list, send a message to >>>>> i-d-announce-request@ietf.org with the word unsubscribe in the body >>>>> of the message. >>>>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >>>>> to change your subscription settings. >>>>> >>>>> >>>>> 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-simple-xcap-09.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: >>>>> mailserv@ietf.org. >>>>> In the body type: >>>>> "FILE /internet-drafts/draft-ietf-simple-xcap-09.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. >>>>> Content-Type: text/plain >>>>> Content-ID: <2006-3-23150339.I-D@ietf.org> >>>>> >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> -- >> ===================================================================== >> Josh Littlefield Cisco Systems, Inc. >> joshl@cisco.com 1414 Massachusetts Avenue >> tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 1414 Massachusetts Avenue tel: 978-936-1379 fax: 978-936-2226 Boxborough, MA 01719-2205 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 10:18:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxE6-0005oS-PU; Mon, 10 Apr 2006 10:18:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxE5-0005oN-GG for simple@ietf.org; Mon, 10 Apr 2006 10:18:45 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxE4-0003Ey-PK for simple@ietf.org; Mon, 10 Apr 2006 10:18:45 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k3AEIhSZ019056; Mon, 10 Apr 2006 16:18:43 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k3AEIgGE003170; Mon, 10 Apr 2006 16:18:43 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 16:18:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Mon, 10 Apr 2006 16:18:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Thread-Index: AcZZ8VTlEwbDxguiTn+xrdTlxs9f1ACt6ZVA From: "Tan, Ya-Ching" To: "Robert Sparks" , X-OriginalArrivalTime: 10 Apr 2006 14:18:42.0839 (UTC) FILETIME=[ABCFD270:01C65CA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org The response code 409 is used throughout this document. I can't find = where it is defined. It is certainly not on the existing IANA list.=20 Ya Ching -----Urspr=FCngliche Nachricht----- Von: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Gesendet: Freitag, 7. April 2006 05:14 An: simple@ietf.org list Betreff: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt=20 If you haven't sent comments, please do so now. RjS On Mar 27, 2006, at 1:32 PM, Robert Sparks wrote: > This is a SIMPLE working group Last Call for Comments on draft-ietf-=20 > simple-xcap-09. > > This last call ends in two weeks - April 10, 2006 > > The previous version of this draft was approved for publication, =20 > but was removed > from the RFC editor's queue to address a technical issue with =20 > conditional inserts. > The group also agreed to incorporate several clarifying text =20 > changes while the document > was open. > > Please review the changes carefully and send feedback to the SIMPLE =20 > list, copying > Jonathan. > > RjS > > On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: > >> A New Internet-Draft is available from the on-line Internet-Drafts =20 >> directories. >> This draft is a work item of the SIP for Instant Messaging and =20 >> Presence Leveraging Extensions Working Group of the IETF. >> >> Title : The Extensible Markup Language (XML) Configuration =20 >> Access Protocol (XCAP) >> Author(s) : J. Rosenberg >> Filename : draft-ietf-simple-xcap-09.txt >> Pages : 68 >> Date : 2006-3-23 >> =09 >> This specification defines the Extensible Markup Language (XML) >> Configuration Access Protocol (XCAP). XCAP allows a client to read, >> write and modify application configuration data, stored in XML format >> on a server. XCAP maps XML document sub-trees and element attributes >> to HTTP URIs, so that these components can be directly accessed by >> HTTP. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt >> >> To remove yourself from the I-D Announcement list, send a message to >> i-d-announce-request@ietf.org with the word unsubscribe in the =20 >> body of the message. >> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-=20 >> announce >> to change your subscription settings. >> >> >> Internet-Drafts are also available by anonymous FTP. Login with =20 >> the username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-ietf-simple-xcap-09.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: >> mailserv@ietf.org. >> In the body type: >> "FILE /internet-drafts/draft-ietf-simple-xcap-09.txt". >> =09 >> 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. >> =09 >> =09 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> Content-Type: text/plain >> Content-ID: <2006-3-23150339.I-D@ietf.org> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 10:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxOP-0004EK-Kz; Mon, 10 Apr 2006 10:29:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxOO-0004EE-MZ for simple@ietf.org; Mon, 10 Apr 2006 10:29:24 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxOK-0003dk-Cj for simple@ietf.org; Mon, 10 Apr 2006 10:29:24 -0400 Received: from [192.168.0.102] (ppp-70-244-170-152.dsl.rcsntx.swbell.net [70.244.170.152]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3AETIBv087346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 09:29:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <443A6BB9.3050208@nostrum.com> Date: Mon, 10 Apr 2006 09:29:13 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tan, Ya-Ching" Subject: Re: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.244.170.152 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Tan, Ya-Ching wrote: >The response code 409 is used throughout this document. I can't find where it is defined. > RFC 2616, section 10.4.10. > It is certainly not on the existing IANA list. > At the current moment, IANA appears to have completely hosed the response code registry: http://www.iana.org/assignments/http-status-codes As I am writing this, only one valid response code is registered for HTTP: 226. I will send a mail to IANA. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 10:33:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxSG-0004gf-Gr; Mon, 10 Apr 2006 10:33:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxSE-0004ga-UH for simple@ietf.org; Mon, 10 Apr 2006 10:33:22 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxSD-0003pF-EF for simple@ietf.org; Mon, 10 Apr 2006 10:33:22 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k3AEXKmh029564; Mon, 10 Apr 2006 16:33:20 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k3AEXKFH014360; Mon, 10 Apr 2006 16:33:20 +0200 Received: from MCHP7I5A.ww002.siemens.net ([139.25.131.136]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 16:33:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Mon, 10 Apr 2006 16:33:18 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Thread-Index: AcZcqzR2MvZvt9SZSga6E/hg0Ai6GQAAGLBg From: "Tan, Ya-Ching" To: "Adam Roach" X-OriginalArrivalTime: 10 Apr 2006 14:33:20.0049 (UTC) FILETIME=[B6AB7210:01C65CAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org =20 Actually, I was talking about the IANA SIP response code registration at = : http://www.iana.org/assignments/sip-parameters Ya Ching -----Urspr=FCngliche Nachricht----- Von: Adam Roach [mailto:adam@nostrum.com]=20 Gesendet: Montag, 10. April 2006 16:29 An: Tan, Ya-Ching Cc: simple@ietf.org Betreff: Re: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Tan, Ya-Ching wrote: >The response code 409 is used throughout this document. I can't find = where it is defined. > RFC 2616, section 10.4.10. > It is certainly not on the existing IANA list. > At the current moment, IANA appears to have completely hosed the=20 response code registry: http://www.iana.org/assignments/http-status-codes As I am writing this, only one valid response code is registered for=20 HTTP: 226. I will send a mail to IANA. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 10:40:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxZG-000825-Gs; Mon, 10 Apr 2006 10:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxZF-000820-LP for simple@ietf.org; Mon, 10 Apr 2006 10:40:37 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxZF-00048g-AW for simple@ietf.org; Mon, 10 Apr 2006 10:40:37 -0400 Received: from [192.168.0.102] (ppp-70-244-170-152.dsl.rcsntx.swbell.net [70.244.170.152]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3AEeanQ088193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Apr 2006 09:40:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <443A6E5F.2000303@nostrum.com> Date: Mon, 10 Apr 2006 09:40:31 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tan, Ya-Ching" Subject: Re: AW: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Received-SPF: pass (nostrum.com: 70.244.170.152 is authenticated by a trusted mechanism) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nostrum.com id k3AEeanQ088193 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Tan, Ya-Ching wrote: >=20 >Actually, I was talking about the IANA SIP response code registration at= : > >http://www.iana.org/assignments/sip-parameters > =20 > Read the document more carefully. XCAP is a usage of HTTP, not a usage=20 of SIP. None of the SIP registries apply. /a > >Ya Ching > >-----Urspr=FCngliche Nachricht----- >Von: Adam Roach [mailto:adam@nostrum.com]=20 >Gesendet: Montag, 10. April 2006 16:29 >An: Tan, Ya-Ching >Cc: simple@ietf.org >Betreff: Re: AW: Reminder: [Simple] WGLC : draft-ietf-simple-xcap-09.txt > >Tan, Ya-Ching wrote: > > =20 > >>The response code 409 is used throughout this document. I can't find w= here it is defined. >> >> =20 >> > >RFC 2616, section 10.4.10. > > =20 > >> It is certainly not on the existing IANA list. >> >> =20 >> > >At the current moment, IANA appears to have completely hosed the=20 >response code registry: > >http://www.iana.org/assignments/http-status-codes > >As I am writing this, only one valid response code is registered for=20 >HTTP: 226. I will send a mail to IANA. > >/a > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > =20 > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 11:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyCr-0001HB-DZ; Mon, 10 Apr 2006 11:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyCp-0001H2-Nc for simple@ietf.org; Mon, 10 Apr 2006 11:21:31 -0400 Received: from pproxy.gmail.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyCo-0006Mn-Hd for simple@ietf.org; Mon, 10 Apr 2006 11:21:31 -0400 Received: by pproxy.gmail.com with SMTP id t32so1091114pyc for ; Mon, 10 Apr 2006 08:21:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Keedv2wI3lhx0RDK0LwcekKzoBcXacZVpzGY0VTQYsjK9raIev3pAWFmUUNi6u5sQNOuPVIT+V09mErtK8FnJecGNhwafzp/pnvXAWUSFh8IedGyHaYVEZw8f/PSvZT8VeWRHktYKMcmgrcV9AkggcK+RaqgJ6/u8HpEEY6PwFo= Received: by 10.35.101.9 with SMTP id d9mr114621pym; Mon, 10 Apr 2006 08:21:29 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Mon, 10 Apr 2006 08:21:29 -0700 (PDT) Message-ID: <9d77d7060604100821y74e498e2scfc0452c14d9d8b7@mail.gmail.com> Date: Mon, 10 Apr 2006 23:21:29 +0800 From: "Xiang Ting" To: simple@ietf.org Subject: [Simple]Does IM need a REPORT? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dgurle@microsoft.com, huitema@microsoft.com, jdrosen@dynamicsoft.com, bcampbell@dynamicsoft.com, schulzrinne@cs.columbia.edu X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org In RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant Messaging, there is no mechanism to ensure an Instant Message deliver to terminal UE from original UE successfully. The protocol only define a 202 Accept response code indicating that a server has received the message, but had no way to let orignal UE know whether a delivery is successful. The RFC 3428 describe this problem as follows: [snip] If confirmation of delivery is required for a message that has been responded to with a 202 Accepted, that confirmation must be delivered via some other mechanism, which is beyond the scope of this specification. [/snip] I want to know whether a success/failure report in telecom network is necessary? And has anyone done such a work yet? Or we need to do such work as a supplement to RFC 3428? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 10 11:59:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyn2-0005pw-2f; Mon, 10 Apr 2006 11:58:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyn0-0005pr-FR for simple@ietf.org; Mon, 10 Apr 2006 11:58:54 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyn0-0007ap-3j for simple@ietf.org; Mon, 10 Apr 2006 11:58:54 -0400 Received: from [172.17.1.114] ([172.17.1.114]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3AFwlp1053879 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 10 Apr 2006 10:58:47 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <9d77d7060604100821y74e498e2scfc0452c14d9d8b7@mail.gmail.com> References: <9d77d7060604100821y74e498e2scfc0452c14d9d8b7@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple]Does IM need a REPORT? Date: Mon, 10 Apr 2006 10:58:42 -0500 To: Xiang Ting X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, dgurle@microsoft.com, simple@ietf.org, huitema@microsoft.com, bcampbell@dynamicsoft.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org It depends on your architecture. If you can deliver to the final destination immediately, you can use the SIP 200 response, which immediately tells you that the message was successfully delivered. If there is some intermediary device such a store and forward server that accepts the message with a 202, and then delivers later, you may optionally want some sort of delivery notification when the delivery actually happens. This is the sort of notification that 3428 is talking about being out of scope. There is currently work going on in the SIMPLE work group on defining a mechanism for this. On Apr 10, 2006, at 10:21 AM, Xiang Ting wrote: > In RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant > Messaging, there is no mechanism to ensure an Instant Message deliver > to terminal UE from original UE successfully. The protocol only define > a 202 Accept response code indicating that a server has received the > message, but had no way to let orignal UE know whether a delivery is > successful. The RFC 3428 describe this problem as follows: > [snip] > If confirmation of delivery is required for a message > that has been responded to with a 202 Accepted, that confirmation > must be delivered via some other mechanism, which is beyond the > scope > of this specification. > [/snip] > > I want to know whether a success/failure report in telecom network is > necessary? And has anyone done such a work yet? Or we need to do such > work as a supplement to RFC 3428? > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 11 10:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK9A-00032o-LF; Tue, 11 Apr 2006 10:47:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTK99-00030A-En for simple@ietf.org; Tue, 11 Apr 2006 10:47:11 -0400 Received: from pproxy.gmail.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTK98-0004NJ-8N for simple@ietf.org; Tue, 11 Apr 2006 10:47:11 -0400 Received: by pproxy.gmail.com with SMTP id t32so1360895pyc for ; Tue, 11 Apr 2006 07:47:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=W3P+SnDrV/LWZY4rtxW+UO3zP4m6nMxkSkXTu0WNbV7EB5BTD7uvQY5XVFc3W9ydBIyootQsQKOgeoyuSRq91kvniDcENKLX0Q+iFemKV/MiUglqRODqUK6QQcyo7YaSw5Lz8qFvVEL2EOlh54lyXQQzvOV4dYIsshWuUz1Y2g0= Received: by 10.35.127.7 with SMTP id e7mr228093pyn; Tue, 11 Apr 2006 07:47:09 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Tue, 11 Apr 2006 07:47:06 -0700 (PDT) Message-ID: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> Date: Tue, 11 Apr 2006 22:47:06 +0800 From: "Xiang Ting" To: simple@ietf.org Subject: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rohan@ekabal.com, fluffy@cisco.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org In SIP,multiple header field rows with the same field-name MAY be present in a message (if the entire field-value for that header field is defined as a comma-separated list ). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. While in RFC2327 and draft-ietf-simple-message-sessions , there is no specific rule that defines how should implementations deal with attribute which can take multiple values separated by space. e.g. If the following example appears ,how should implementations treat it? a=3Daccept-types:message/cpim a=3Daccept-types:text/plain There are alternative means now. One is only accept the first and ignore the others.The other is combining them into one attribute line spacing these accept-types with a space, as below: a=3Daccept-types:message/cpim text/plain But if the accept-types are the same,e.g. a=3Daccept-types:message/cpim a=3Daccept-types:message/cpim then,how to deal with it ? Thanks in advance. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 11 10:51:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKD5-0005RE-OM; Tue, 11 Apr 2006 10:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTKD5-0005R9-0R for simple@ietf.org; Tue, 11 Apr 2006 10:51:15 -0400 Received: from pproxy.gmail.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTKD3-0004UN-Ou for simple@ietf.org; Tue, 11 Apr 2006 10:51:14 -0400 Received: by pproxy.gmail.com with SMTP id t32so1361925pyc for ; Tue, 11 Apr 2006 07:51:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BF8sEI1oqG+zZitVWtToXq0AXjSL7KXqE+LrqfGi4UwNyENVWDMqhYD74XLXjratUyVeBiqIGAiYVopzCOHppQX92lPLyVsrecONP/z1CQZxMZ06e7dOC9bzQ3b/YTXP+rkWkYVcPjH76DQkxnnwYUUZdvigm8e1twBVESbNipg= Received: by 10.35.18.4 with SMTP id v4mr1466785pyi; Tue, 11 Apr 2006 07:51:13 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Tue, 11 Apr 2006 07:51:13 -0700 (PDT) Message-ID: <9d77d7060604110751j58e175dcjeb7407824bce2bae@mail.gmail.com> Date: Tue, 11 Apr 2006 22:51:13 +0800 From: "Xiang Ting" To: "Ben Campbell" Subject: Re: [Simple]Does IM need a REPORT? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9d77d7060604100821y74e498e2scfc0452c14d9d8b7@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, dgurle@microsoft.com, simple@ietf.org, huitema@microsoft.com, bcampbell@dynamicsoft.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org I am appreciated for your reply. On 4/10/06, Ben Campbell wrote: > It depends on your architecture. > > If you can deliver to the final destination immediately, you can use > the SIP 200 response, which immediately tells you that the message > was successfully delivered. > > If there is some intermediary device such a store and forward server > that accepts the message with a 202, and then delivers later, you may > optionally want some sort of delivery notification when the delivery > actually happens. This is the sort of notification that 3428 is > talking about being out of scope. There is currently work going on in > the SIMPLE work group on defining a mechanism for this. > I want to know which ieft-draft describe this requirement? Thanks. > On Apr 10, 2006, at 10:21 AM, Xiang Ting wrote: > > > In RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant > > Messaging, there is no mechanism to ensure an Instant Message deliver > > to terminal UE from original UE successfully. The protocol only define > > a 202 Accept response code indicating that a server has received the > > message, but had no way to let orignal UE know whether a delivery is > > successful. The RFC 3428 describe this problem as follows: > > [snip] > > If confirmation of delivery is required for a message > > that has been responded to with a 202 Accepted, that confirmation > > must be delivered via some other mechanism, which is beyond the > > scope > > of this specification. > > [/snip] > > > > I want to know whether a success/failure report in telecom network is > > necessary? And has anyone done such a work yet? Or we need to do such > > work as a supplement to RFC 3428? > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 11 12:04:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLLg-00037q-PZ; Tue, 11 Apr 2006 12:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLLe-00037l-OH for simple@ietf.org; Tue, 11 Apr 2006 12:04:10 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLLe-0007fi-0f for simple@ietf.org; Tue, 11 Apr 2006 12:04:10 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id EC9921944AB for ; Tue, 11 Apr 2006 18:04:08 +0200 (CEST) Received: from [192.168.1.6] ([192.168.1.6]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:02:19 +0200 In-Reply-To: <9d77d7060604110751j58e175dcjeb7407824bce2bae@mail.gmail.com> References: <9d77d7060604100821y74e498e2scfc0452c14d9d8b7@mail.gmail.com> <9d77d7060604110751j58e175dcjeb7407824bce2bae@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <969c08942dfe67786eb545ece6a6f52f@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple]Does IM need a REPORT? Date: Tue, 11 Apr 2006 18:03:42 +0200 To: "Xiang Ting" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 11 Apr 2006 16:02:19.0231 (UTC) FILETIME=[4F7BB6F0:01C65D81] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: jdrosen@dynamicsoft.com, schulzrinne@cs.columbia.edu, dgurle@microsoft.com, simple@ietf.org, huitema@microsoft.com, bcampbell@dynamicsoft.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 11, 2006, at 4:51 PM, Xiang Ting wrote: > I am appreciated for your reply. > > On 4/10/06, Ben Campbell wrote: >> It depends on your architecture. >> >> If you can deliver to the final destination immediately, you can use >> the SIP 200 response, which immediately tells you that the message >> was successfully delivered. >> >> If there is some intermediary device such a store and forward server >> that accepts the message with a 202, and then delivers later, you may >> optionally want some sort of delivery notification when the delivery >> actually happens. This is the sort of notification that 3428 is >> talking about being out of scope. There is currently work going on in >> the SIMPLE work group on defining a mechanism for this. >> > > I want to know which ieft-draft describe this requirement? There are 2 proposals for this. Within the next week or 2, I will be submitting a converged version. I hope that's not too late for you. Regards, Hisham > Thanks. > > > >> On Apr 10, 2006, at 10:21 AM, Xiang Ting wrote: >> >>> In RFC 3428 - Session Initiation Protocol (SIP) Extension for Instant >>> Messaging, there is no mechanism to ensure an Instant Message deliver >>> to terminal UE from original UE successfully. The protocol only >>> define >>> a 202 Accept response code indicating that a server has received the >>> message, but had no way to let orignal UE know whether a delivery is >>> successful. The RFC 3428 describe this problem as follows: >>> [snip] >>> If confirmation of delivery is required for a message >>> that has been responded to with a 202 Accepted, that confirmation >>> must be delivered via some other mechanism, which is beyond the >>> scope >>> of this specification. >>> [/snip] >>> >>> I want to know whether a success/failure report in telecom network is >>> necessary? And has anyone done such a work yet? Or we need to do such >>> work as a supplement to RFC 3428? >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 11 16:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPDm-0006Ql-N6; Tue, 11 Apr 2006 16:12:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPDk-0006Ps-Is for simple@ietf.org; Tue, 11 Apr 2006 16:12:16 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPDk-00015p-Al for simple@ietf.org; Tue, 11 Apr 2006 16:12:16 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2006 13:12:15 -0700 X-IronPort-AV: i="4.04,112,1144047600"; d="scan'208"; a="268054788:sNHT30803960" Received: from vtg-um-e2k2.sj21ad.cisco.com (vtg-um-e2k2.cisco.com [171.70.93.54]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k3BKCEYg006192; Tue, 11 Apr 2006 13:12:14 -0700 (PDT) Received: from 10.21.145.65 ([10.21.145.65]) by vtg-um-e2k2.sj21ad.cisco.com ([171.70.93.54]) with Microsoft Exchange Server HTTP-DAV ; Tue, 11 Apr 2006 20:12:13 +0000 User-Agent: Microsoft-Entourage/11.2.3.060209 Date: Tue, 11 Apr 2006 12:48:34 -0700 Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? From: Cullen Jennings To: Xiang Ting , "simple@ietf.org" , Adam Roach Message-ID: Thread-Topic: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? Thread-Index: AcZdoOqtKTMuDsmUEdqN7gARJEEJ/A== In-Reply-To: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Rohan Mahy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Adding Adam.... On 4/11/06 7:47 AM, "Xiang Ting" wrote: > In SIP,multiple header field rows with the same field-name MAY be > present in a message (if the entire field-value for that header field is > defined as a comma-separated list ). > It MUST be possible to combine the multiple header field rows into one > "field-name: field-value" pair. > Implementations MUST be able to process multiple header field rows > with the same name in any combination of the single-value-per-line or > comma-separated value forms. > While in RFC2327 and draft-ietf-simple-message-sessions , there is no > specific rule that defines how should implementations deal with attribute > which can take multiple values separated by space. > e.g. > If the following example appears ,how should implementations treat it? > a=accept-types:message/cpim > a=accept-types:text/plain > There are alternative means now. > One is only accept the first and ignore the others.The other is combining > them into one attribute line spacing these accept-types with a space, as > below: > a=accept-types:message/cpim text/plain > > But if the accept-types are the same,e.g. > a=accept-types:message/cpim > a=accept-types:message/cpim > then,how to deal with it ? > > > Thanks in advance. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 11 18:17:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRAh-0004x4-Ca; Tue, 11 Apr 2006 18:17:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRAg-0004wz-RN for simple@ietf.org; Tue, 11 Apr 2006 18:17:14 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRAd-0006Ik-F6 for simple@ietf.org; Tue, 11 Apr 2006 18:17:14 -0400 Received: from [172.17.2.251] ([172.17.2.251]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3BMH58b000849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 17:17:05 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <443C2AE1.3020008@estacado.net> Date: Tue, 11 Apr 2006 17:17:05 -0500 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xiang Ting Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? References: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> In-Reply-To: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Xiang Ting wrote: >In SIP,multiple header field rows with the same field-name MAY be >present in a message (if the entire field-value for that header field is >defined as a comma-separated list ). >It MUST be possible to combine the multiple header field rows into one >"field-name: field-value" pair. >Implementations MUST be able to process multiple header field rows >with the same name in any combination of the single-value-per-line or >comma-separated value forms. >While in RFC2327 and draft-ietf-simple-message-sessions , there is no >specific rule that defines how should implementations deal with attribute >which can take multiple values separated by space. >e.g. >If the following example appears ,how should implementations treat it? >a=accept-types:message/cpim >a=accept-types:text/plain >There are alternative means now. >One is only accept the first and ignore the others.The other is combining >them into one attribute line spacing these accept-types with a space, as >below: >a=accept-types:message/cpim text/plain > >But if the accept-types are the same,e.g. >a=accept-types:message/cpim >a=accept-types:message/cpim >then,how to deal with it ? > > I'm not sure about what would be technically 100% correct handling from a standards perspective. >From an implementation perspective, I would suggest that you will have the best luck interoperating if you: 1. Never send SDP of this form 2. Treat received multiple "a=accept-types:" lines as a single line with multiple values (as you describe above), and 3. Ignore duplicates (meaning that your final example would result in believing the other end supported only "message/cpim"). /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 06:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcQp-0005hx-9u; Wed, 12 Apr 2006 06:18:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTcQn-0005d6-0D for simple@ietf.org; Wed, 12 Apr 2006 06:18:37 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTcQm-0007vc-Ab for simple@ietf.org; Wed, 12 Apr 2006 06:18:36 -0400 Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IXL00DCWTYWT9@mailout1.samsung.com> for simple@ietf.org; Wed, 12 Apr 2006 19:18:32 +0900 (KST) Received: from LocalHost ([165.213.178.95]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IXL008VETYWGU@mmp2.samsung.com> for simple@ietf.org; Wed, 12 Apr 2006 19:18:32 +0900 (KST) Date: Wed, 12 Apr 2006 19:17:19 +0900 From: =?ks_c_5601-1987?B?wMzBvsfK?= Subject: RE: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? In-reply-to: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> To: 'Xiang Ting' , simple@ietf.org Message-id: <000e01c65e1a$47d91ed0$5fb2d5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: fluffy@cisco.com, rohan@ekabal.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi. Xiang Ting. I think that is implementation dependant. If not detailed specified in RFC.. But I recommend as below. First... a=accept-types:message/cpim a=accept-types:text/plain If UA received this message, then UA have two attribute by parsing one line. That is role of SIP parser. If parser didn't support that, that is the problem of parser. And UA recognize two attribute ,then each attribute attached listed structure in media field. After all, UA can use that attribute. Seciond... a=accept-types:message/cpim a=accept-types:message/cpim If UA received this message, then UA have two attribute by parsing one line, even though exactly same attribute value. This is role of SIP Parser. And SIP parser can detect incoming message has two attribute in one line. That is possible that recognize string such as " a=" ("blank + a + '='). If SIP parser is genious, no problem. Third... Recommandation is below.... a=accept-types:message/cpim a=accept-types:text/plain Each UA may use above style, each attribute in a line. But sometimes proxy didn't send above information (two attributes) in each line. Even though UA SIP Parser have to detect that attributes each by each. Commonly UA have a list attributes for one media field. UA can use each attribute for itself. I hope will be help/. JP. -----Original Message----- From: Xiang Ting [mailto:x.victoria@gmail.com] Sent: Tuesday, April 11, 2006 11:47 PM To: simple@ietf.org Cc: rohan@ekabal.com; fluffy@cisco.com Subject: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? In SIP,multiple header field rows with the same field-name MAY be present in a message (if the entire field-value for that header field is defined as a comma-separated list ). It MUST be possible to combine the multiple header field rows into one "field-name: field-value" pair. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma- separated value forms. While in RFC2327 and draft-ietf-simple-message- sessions , there is no specific rule that defines how should implementations deal with attribute which can take multiple values separated by space. e.g. If the following example appears ,how should implementations treat it? a=accept-types:message/cpim a=accept- types:text/plain There are alternative means now. One is only accept the first and ignore the others.The other is combining them into one attribute line spacing these accept-types with a space, as below: a=accept-types:message/cpim text/plain But if the accept-types are the same,e.g. a=accept-types:message/cpim a=accept-types:message/cpim then,how to deal with it ? Thanks in advance. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 08:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeZq-0007DV-Aa; Wed, 12 Apr 2006 08:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTeZp-0007Ai-IG for simple@ietf.org; Wed, 12 Apr 2006 08:36:05 -0400 Received: from pproxy.gmail.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTeZp-0004H0-8b for simple@ietf.org; Wed, 12 Apr 2006 08:36:05 -0400 Received: by pproxy.gmail.com with SMTP id t32so1601650pyc for ; Wed, 12 Apr 2006 05:36:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HvnWwpzlpfQkUMMTvXlRTAuX32vwPVhvsPLhYaCczVwTI5J1GhMjuOUIXH9DALoVZw5+lwj6m86mnm0+JH1LWFpimOsC3oysdgwvARBMZGCAYfZ4uvin1tbuTheoXW4Rx04yBK+iIbzAHEfmqAZrwFyhbBEIUcd5XtYGwwqRHc4= Received: by 10.35.21.1 with SMTP id y1mr80300pyi; Wed, 12 Apr 2006 05:36:03 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Wed, 12 Apr 2006 05:36:03 -0700 (PDT) Message-ID: <9d77d7060604120536r581a968fqc1a057e074e1de9d@mail.gmail.com> Date: Wed, 12 Apr 2006 20:36:03 +0800 From: "Xiang Ting" To: "=?EUC-KR?B?wMzBvsfK?=" Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? In-Reply-To: <000e01c65e1a$47d91ed0$5fb2d5a5@LocalHost> MIME-Version: 1.0 References: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> <000e01c65e1a$47d91ed0$5fb2d5a5@LocalHost> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269367809==" Errors-To: simple-bounces@ietf.org --===============1269367809== Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: base64 Content-Disposition: inline VGhhbmsgeW91ciBmb3IgeW91ciByZXBseS4KCk9uIDQvMTIvMDYsIMDMwb7HyiA8anAueWlAc2Ft c3VuZy5jb20+IHdyb3RlOgo+Cj4gSGkuIFhpYW5nIFRpbmcuCj4KPiBJIHRoaW5rIHRoYXQgaXMg aW1wbGVtZW50YXRpb24gZGVwZW5kYW50LiBJZiBub3QgZGV0YWlsZWQgc3BlY2lmaWVkIGluCj4g UkZDLi4KPiBCdXQgIEkgcmVjb21tZW5kIGFzIGJlbG93Lgo+Cj4gRmlyc3QuLi4KPiBhPWFjY2Vw dC10eXBlczptZXNzYWdlL2NwaW0gYT1hY2NlcHQtdHlwZXM6dGV4dC9wbGFpbgo+Cj4gSWYgVUEg cmVjZWl2ZWQgdGhpcyBtZXNzYWdlLCB0aGVuIFVBIGhhdmUgdHdvIGF0dHJpYnV0ZSBieSBwYXJz aW5nICBvbmUKPiBsaW5lLiBUaGF0IGlzIHJvbGUgb2YgU0lQICBwYXJzZXIuCj4gSWYgcGFyc2Vy IGRpZG4ndCBzdXBwb3J0IHRoYXQsIHRoYXQgaXMgdGhlIHByb2JsZW0gb2YgcGFyc2VyLgo+Cj4g QW5kIFVBIHJlY29nbml6ZSB0d28gYXR0cmlidXRlICx0aGVuIGVhY2ggYXR0cmlidXRlIGF0dGFj aGVkIGxpc3RlZAo+IHN0cnVjdHVyZSBpbiBtZWRpYSBmaWVsZC4KPiBBZnRlciBhbGwsIFVBIGNh biB1c2UgdGhhdCBhdHRyaWJ1dGUuCj4KPiBTZWNpb25kLi4uCj4gYT1hY2NlcHQtdHlwZXM6bWVz c2FnZS9jcGltIGE9YWNjZXB0LXR5cGVzOm1lc3NhZ2UvY3BpbQo+CkkgZG8gbm90IGFncmVlIHdp dGggeW91IGFib3V0IHlvdXIgb3BpbmlvbiwgQWNjb3JkaW5nIHRvIFJGQyAyMzI3IHRoZQpmb3Jt YXQgb2YgYXR0cmlidXRlIGlzICJhPTxmbGFnPjogPHZhbHVlPiIsIHNvIGlmIG9uZSBtb3JlICJh PSIKYXBwZWFycyBpbiB0aGUgc2FtZSBsaW5lLCB0aGUgcGFyc2VyIHdpbGwgdGFrZSAibWVzc2Fn ZS9jcGltCmE9YWNjZXB0LXR5cGVzOm1lc3NhZ2UvY3BpbSIgYXMgdGhlIHZhbHVlIG9mIHRoaXMg YXR0cmlidXRlLgoKPiBJZiBVQSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UsIHRoZW4gVUEgaGF2ZSB0 d28gYXR0cmlidXRlIGJ5IHBhcnNpbmcgb25lCj4gbGluZSwgZXZlbiB0aG91Z2ggZXhhY3RseSBz YW1lIGF0dHJpYnV0ZSB2YWx1ZS4gVGhpcyBpcyByb2xlIG9mIFNJUAo+IFBhcnNlci4KPiBBbmQg U0lQIHBhcnNlciBjYW4gZGV0ZWN0IGluY29taW5nIG1lc3NhZ2UgaGFzIHR3byBhdHRyaWJ1dGUg aW4gb25lCj4gbGluZS4gVGhhdCBpcyBwb3NzaWJsZSB0aGF0IHJlY29nbml6ZSBzdHJpbmcgc3Vj aCBhcyAiICBhPSIgKCJibGFuayArIGEKPiArICc9JykuCj4gSWYgU0lQIHBhcnNlciBpcyBnZW5p b3VzLCBubyBwcm9ibGVtLgo+Cj4gVGhpcmQuLi4KPgo+IFJlY29tbWFuZGF0aW9uIGlzIGJlbG93 Li4uLgo+Cj4gYT1hY2NlcHQtdHlwZXM6bWVzc2FnZS9jcGltCj4gYT1hY2NlcHQtdHlwZXM6dGV4 dC9wbGFpbgo+Cj4gRWFjaCBVQSBtYXkgdXNlIGFib3ZlIHN0eWxlLCBlYWNoIGF0dHJpYnV0ZSBp biBhIGxpbmUuCj4gQnV0IHNvbWV0aW1lcyBwcm94eSBkaWRuJ3Qgc2VuZCBhYm92ZSBpbmZvcm1h dGlvbiAodHdvIGF0dHJpYnV0ZXMpIGluCj4gZWFjaCBsaW5lLiBFdmVuIHRob3VnaCBVQSBTSVAg UGFyc2VyIGhhdmUgdG8gZGV0ZWN0IHRoYXQgYXR0cmlidXRlcwo+IGVhY2ggYnkgZWFjaC4KPgo+ IENvbW1vbmx5IFVBIGhhdmUgYSBsaXN0IGF0dHJpYnV0ZXMgZm9yIG9uZSBtZWRpYSBmaWVsZC4g VUEgY2FuIHVzZSBlYWNoCj4gYXR0cmlidXRlIGZvciBpdHNlbGYuCj4KPiBJIGhvcGUgd2lsbCBi ZSBoZWxwLy4KPgo+IEpQLgo+Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBY aWFuZyBUaW5nIFttYWlsdG86eC52aWN0b3JpYUBnbWFpbC5jb21dCj4gU2VudDogVHVlc2RheSwg QXByaWwgMTEsIDIwMDYgMTE6NDcgUE0KPiBUbzogc2ltcGxlQGlldGYub3JnCj4gQ2M6IHJvaGFu QGVrYWJhbC5jb207IGZsdWZmeUBjaXNjby5jb20KPiBTdWJqZWN0OiBbU2ltcGxlXVtNU1JQXUhv dyB0byBoYW5kbGUgYXR0cmlidXRlIGxpbmVzIHdpdGggdGhlIHNhbWUgZmxhZwo+IGluIFNEUD8K Pgo+Cj4gSW4gU0lQLG11bHRpcGxlIGhlYWRlciBmaWVsZCByb3dzIHdpdGggdGhlIHNhbWUgZmll bGQtbmFtZSBNQVkgYmUKPiBwcmVzZW50IGluIGEgbWVzc2FnZSAoaWYgdGhlIGVudGlyZSBmaWVs ZC12YWx1ZSBmb3IgdGhhdCBoZWFkZXIgZmllbGQKPiBpcyBkZWZpbmVkIGFzIGEgY29tbWEtc2Vw YXJhdGVkIGxpc3QgKS4gSXQgTVVTVCBiZSBwb3NzaWJsZSB0byBjb21iaW5lCj4gdGhlIG11bHRp cGxlIGhlYWRlciBmaWVsZCByb3dzIGludG8gb25lCj4gImZpZWxkLW5hbWU6IGZpZWxkLXZhbHVl IiBwYWlyLgo+IEltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGFibGUgdG8gcHJvY2VzcyBtdWx0aXBs ZSBoZWFkZXIgZmllbGQgcm93cyB3aXRoCj4gdGhlIHNhbWUgbmFtZSBpbiBhbnkgY29tYmluYXRp b24gb2YgdGhlIHNpbmdsZS12YWx1ZS1wZXItbGluZSBvciBjb21tYS0KPiBzZXBhcmF0ZWQgdmFs dWUgZm9ybXMuIFdoaWxlIGluIFJGQzIzMjcgYW5kIGRyYWZ0LWlldGYtc2ltcGxlLW1lc3NhZ2Ut Cj4gc2Vzc2lvbnMgLCB0aGVyZSBpcyBubyBzcGVjaWZpYyBydWxlIHRoYXQgZGVmaW5lcyBob3cg c2hvdWxkCj4gaW1wbGVtZW50YXRpb25zIGRlYWwgd2l0aCBhdHRyaWJ1dGUgd2hpY2ggY2FuIHRh a2UgbXVsdGlwbGUgdmFsdWVzCj4gc2VwYXJhdGVkIGJ5IHNwYWNlLiBlLmcuIElmIHRoZSBmb2xs b3dpbmcgZXhhbXBsZSBhcHBlYXJzICxob3cgc2hvdWxkCj4gaW1wbGVtZW50YXRpb25zIHRyZWF0 IGl0PyBhPWFjY2VwdC10eXBlczptZXNzYWdlL2NwaW0gYT1hY2NlcHQtCj4gdHlwZXM6dGV4dC9w bGFpbiBUaGVyZSBhcmUgYWx0ZXJuYXRpdmUgbWVhbnMgbm93LiBPbmUgaXMgb25seSBhY2NlcHQK PiB0aGUgZmlyc3QgYW5kIGlnbm9yZSB0aGUgb3RoZXJzLlRoZSBvdGhlciBpcyBjb21iaW5pbmcg dGhlbSBpbnRvIG9uZQo+IGF0dHJpYnV0ZSBsaW5lIHNwYWNpbmcgdGhlc2UgYWNjZXB0LXR5cGVz IHdpdGggYSBzcGFjZSwgYXMKPiBiZWxvdzoKPiBhPWFjY2VwdC10eXBlczptZXNzYWdlL2NwaW0g dGV4dC9wbGFpbgo+Cj4gQnV0IGlmIHRoZSBhY2NlcHQtdHlwZXMgYXJlIHRoZSBzYW1lLGUuZy4g YT1hY2NlcHQtdHlwZXM6bWVzc2FnZS9jcGltCj4gYT1hY2NlcHQtdHlwZXM6bWVzc2FnZS9jcGlt IHRoZW4saG93IHRvIGRlYWwgd2l0aCBpdCA/Cj4KPgo+IFRoYW5rcyBpbiBhZHZhbmNlLgo+Cj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBTaW1wbGUg bWFpbGluZyBsaXN0Cj4gU2ltcGxlQGlldGYub3JnCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ltcGxlCj4KPgo+Cg== --===============1269367809== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1269367809==-- From simple-bounces@ietf.org Wed Apr 12 09:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfBS-0006Io-Op; Wed, 12 Apr 2006 09:14:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfBQ-0006Ie-Th for simple@ietf.org; Wed, 12 Apr 2006 09:14:56 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfBQ-00057k-IN for simple@ietf.org; Wed, 12 Apr 2006 09:14:56 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Apr 2006 06:14:56 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,114,1144047600"; d="scan'208"; a="25727895:sNHT23371852" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3CDEtTL014090; Wed, 12 Apr 2006 09:14:56 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 09:14:55 -0400 Received: from [161.44.79.149] ([161.44.79.149]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Apr 2006 09:14:55 -0400 Message-ID: <443CFD4F.2080804@cisco.com> Date: Wed, 12 Apr 2006 09:14:55 -0400 From: Paul Kyzivat User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? References: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> <443C2AE1.3020008@estacado.net> In-Reply-To: <443C2AE1.3020008@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2006 13:14:55.0628 (UTC) FILETIME=[177144C0:01C65E33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Adam Roach wrote: >>If the following example appears ,how should implementations treat it? >>a=accept-types:message/cpim >>a=accept-types:text/plain >>There are alternative means now. >>One is only accept the first and ignore the others.The other is combining >>them into one attribute line spacing these accept-types with a space, as >>below: >>a=accept-types:message/cpim text/plain >> >>But if the accept-types are the same,e.g. >>a=accept-types:message/cpim >>a=accept-types:message/cpim >>then,how to deal with it ? > > I'm not sure about what would be technically 100% correct handling from > a standards perspective. > >>From an implementation perspective, I would suggest that you will have > the best luck interoperating if you: > > 1. Never send SDP of this form > > 2. Treat received multiple "a=accept-types:" lines as a single line > with multiple values (as you describe above), and > > 3. Ignore duplicates (meaning that your final example would result in > believing the other end supported only "message/cpim"). SDP-new doesn't address this. And given the range of ways in which attributes are used, I don't think a single approach works for all. - repeats are important for some attributes (e.g. rtpmap) - repeats are meaningless for others (e.g. sendonly) - repeats are problematic for some others (e.g. desired-status) IMO this ought to be specified on an attribute-by-attribute basis. Of course it currently isn't. Is it too late to get some words about this into draft-ietf-simple-message-sessions? (I would suggest that a specification state that this attribute MUST NOT appear more than once per stream. Best practices can deal with the case where this is violated.) Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 09:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfKt-0003jl-7a; Wed, 12 Apr 2006 09:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTfKs-0003jg-K1 for simple@ietf.org; Wed, 12 Apr 2006 09:24:42 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTfKq-0005Rm-8J for simple@ietf.org; Wed, 12 Apr 2006 09:24:42 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3CDOY2f006242 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Apr 2006 08:24:35 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <443CFD4F.2080804@cisco.com> References: <9d77d7060604110747u76dc8f59g871b22ab3348be4b@mail.gmail.com> <443C2AE1.3020008@estacado.net> <443CFD4F.2080804@cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? Date: Wed, 12 Apr 2006 08:24:30 -0500 To: Paul Kyzivat X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: fluffy@cisco.com, rohan@ekabal.com, Adam Roach , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org On Apr 12, 2006, at 8:14 AM, Paul Kyzivat wrote: > SDP-new doesn't address this. And given the range of ways in which > attributes are used, I don't think a single approach works for all. > > - repeats are important for some attributes (e.g. rtpmap) > > - repeats are meaningless for others (e.g. sendonly) > > - repeats are problematic for some others (e.g. desired-status) > > IMO this ought to be specified on an attribute-by-attribute basis. > Of course it currently isn't. Is it too late to get some words > about this into draft-ietf-simple-message-sessions? (I would > suggest that a specification state that this attribute MUST NOT > appear more than once per stream. Best practices can deal with the > case where this is violated.) I was writing up a similar comment, but you beat me to it. I agree that the meaning of repeated SDP a-line attributes is attribute specific. In the case of MSRP, the meaning of this is undefined. Just as in programming, if it is undefined, you shouldn't do it :-) Also, the original posting in this thread seemed to conflate the ability to repeat SIP headers with an expectation of the same feature in SDP. SDP attributes and SIP headers follow different syntax rules. One should not assume that the existence of a syntax feature in one implies anything about the other. Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 10:46:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgbQ-0005Ry-4m; Wed, 12 Apr 2006 10:45:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgbO-0005Rt-SR for simple@ietf.org; Wed, 12 Apr 2006 10:45:50 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgbN-0008Dg-4l for simple@ietf.org; Wed, 12 Apr 2006 10:45:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Date: Wed, 12 Apr 2006 16:45:38 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798015FB163@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] WGLC : draft-ietf-simple-xcap-09.txt Thread-Index: AcZR1WZseBLT1fS1RJynwa33duLwtAHucNyQASvWnBA= From: To: , , X-OriginalArrivalTime: 12 Apr 2006 14:45:41.0133 (UTC) FILETIME=[C53763D0:01C65E3F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, in my understanding the correct XCAP ROOT is the URI of the form "http://xcap.example.com/services". In the begining of section 6 there is written exatly this: "The URI is constructed by concatenating the XCAP root with the document selector with the node selector separator with a percent-encoded form of the node selector. ..." Then the description of document selector from section 6.2 states: "The first path segment MUST be the XCAP AUID." >From these two fragments it concludes that if xcap root does not contain "services" then this fragment cannot be in the xcap uri at all. However, I must agree that the xcap specification should mention the example of xcap root in uniform way. Best regards, Martin Hynar -----Original Message----- From: Anders Lindgren C (HF/EAB) [mailto:anders.c.lindgren@ericsson.com] Sent: 6. dubna 2006 18:01 To: Robert Sparks; simple@ietf.org Subject: RE: [Simple] WGLC : draft-ietf-simple-xcap-09.txt=20 Hi all, I have some minor editorial comments to the draft 1)In chapter 6.1 the example of an XCAP root URI is "http://xcap.example.com. In chapter 6.2 the example has as xcap root "http://xcap.example.com/services and a statement that the example from chapter 6.1 continues. In chapter 7 the example is back to use a XCAP root URI that looks like "http://xcap.example.com. In chapter 13 the examples are using http://xcap.example.com/services as example of the XCAP root URI My propsal is to use the same XCAP root URI example (http://xcap.example.com) everywhere. Thanks Anders Lindgren -----Original Message----- From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: den 27 mars 2006 21:32 To: simple@ietf.org list Subject: [Simple] WGLC : draft-ietf-simple-xcap-09.txt=20 This is a SIMPLE working group Last Call for Comments on draft-ietf- simple-xcap-09. This last call ends in two weeks - April 10, 2006 The previous version of this draft was approved for publication, but was removed from the RFC editor's queue to address a technical issue with conditional inserts. The group also agreed to incorporate several clarifying text changes while the document was open. Please review the changes carefully and send feedback to the SIMPLE list, copying Jonathan. RjS On Mar 23, 2006, at 5:50 PM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the SIP for Instant Messaging and=20 > Presence Leveraging Extensions Working Group of the IETF. > > Title : The Extensible Markup Language (XML) Configuration Access =20 > Protocol (XCAP) > Author(s) : J. Rosenberg > Filename : draft-ietf-simple-xcap-09.txt > Pages : 68 > Date : 2006-3-23 > =09 > This specification defines the Extensible Markup Language (XML)=20 > Configuration Access Protocol (XCAP). XCAP allows a client to read,=20 > write and modify application configuration data, stored in XML format=20 > on a server. XCAP maps XML document sub-trees and element attributes=20 > to HTTP URIs, so that these components can be directly accessed by=20 > HTTP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-simple-xcap-09.txt > > To remove yourself from the I-D Announcement list, send a message to=20 > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-ietf-simple-xcap-09.txt". > > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-simple-xcap-09.txt". > =09 > 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. > =09 > =09 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > Content-Type: text/plain > Content-ID: <2006-3-23150339.I-D@ietf.org> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 16:36:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTm4u-0002yt-UA; Wed, 12 Apr 2006 16:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTm4t-0002yo-To for simple@ietf.org; Wed, 12 Apr 2006 16:36:39 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTm4s-00072K-Ki for simple@ietf.org; Wed, 12 Apr 2006 16:36:39 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3CKaaxk071045 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 12 Apr 2006 15:36:37 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> References: <6A6473FC-C145-43FC-BC3C-B7B9DD251748@nostrum.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76B881F6-AABF-4585-809F-2EE144EFD8DF@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: WGLC: xml-patch, partial-* (was Re: [Simple] updated last-call schedule) Date: Wed, 12 Apr 2006 15:36:33 -0500 To: Robert Sparks X-Mailer: Apple Mail (2.746.3) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "simple@ietf.org list" , Jon Peterson X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org As per the plan below (except for an unintended two day late start): This is a SIMPLE Working Group Last Call for comments on the following drafts: http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch- ops-02.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf- format-06.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- publish-04.txt http://www.ietf.org/internet-drafts/draft-ietf-simple-partial- notify-06.txt This last call will end Monday May 1st. Please send your comments to the list and the respective draft editors. This is a relatively big bite - please give this priority over other list discussions. Thanks, RjS On Mar 27, 2006, at 1:35 PM, Robert Sparks wrote: > Based on the feedback during last week's meeting, we're adjusting > the last call schedule as follows: > > 3/27-4/10 : xcap > 4/10-5/1 : xml-patch, partial-* (3 weeks - several drafts, overlaps > SIPit) > 5/1-5/15: presence-rules > > RjS > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 12 22:10:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrHO-0006at-7M; Wed, 12 Apr 2006 22:09:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTrHN-0006aj-Dg for simple@ietf.org; Wed, 12 Apr 2006 22:09:53 -0400 Received: from wproxy.gmail.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTrHM-0000wc-7a for simple@ietf.org; Wed, 12 Apr 2006 22:09:53 -0400 Received: by wproxy.gmail.com with SMTP id i22so1340979wra for ; Wed, 12 Apr 2006 19:09:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EP0X/lNZg9tqnBthOmi5jfj6s/tmTZvKGk+tIfclgtBoXjmzZvL9LRA0mHLNPQk/ZZP1uu6xbDdOIoUnzaQgiOriuH2kHyLfV4vzgsFLjiyzXB0DXLsrPJHlvvUoQ1nPadusYvVlRijVCV3Baa5zX3IPSg/74fITv0stiXDTG9w= Received: by 10.65.159.16 with SMTP id l16mr2947796qbo; Wed, 12 Apr 2006 19:09:51 -0700 (PDT) Received: by 10.65.126.20 with HTTP; Wed, 12 Apr 2006 19:09:51 -0700 (PDT) Message-ID: Date: Thu, 13 Apr 2006 03:09:51 +0100 From: "Eduardo Martins" To: simple@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Simple] Version of WatcherInfo document + Subscription's Authorization mechanisms X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, i'm developing a SIMPLE service and i would like to know how is the watcher info doc version incremented. Is it each time a parent event type subscription changes status and a parent event type subscription is added/removed? Also where can i find info on how a SIMPLE entity authorizes (or not) a subscription to his presence, on both agents (client and server)? Best regards, Eduardo Martins _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 13 06:13:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTypJ-0004NZ-Vy; Thu, 13 Apr 2006 06:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTypI-0004LM-Gr for simple@ietf.org; Thu, 13 Apr 2006 06:13:24 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTypH-0006rc-JN for simple@ietf.org; Thu, 13 Apr 2006 06:13:24 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IXN00HT0OE3V7@mailout3.samsung.com> for simple@ietf.org; Thu, 13 Apr 2006 19:13:15 +0900 (KST) Received: from LocalHost ([165.213.225.241]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IXN00EAOOD8T4@mmp2.samsung.com> for simple@ietf.org; Thu, 13 Apr 2006 19:13:15 +0900 (KST) Date: Thu, 13 Apr 2006 19:11:35 +0900 From: =?ks_c_5601-1987?B?wMzBvsfK?= Subject: RE: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? In-reply-to: <9d77d7060604120536r581a968fqc1a057e074e1de9d@mail.gmail.com> To: 'Xiang Ting' Message-id: <000c01c65ee2$b78340d0$0701a8c0@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: fluffy@cisco.com, rohan@ekabal.com, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Thank you for your comment. About your comment for second item a=3Daccept-types:message/cpim a=3Daccept-types:message/cpim Your opinion is below.. I do not agree with you about your opinion, According to RFC 2327 the format of attribute is "a=3D: ", so if one more "a=3D" = appears in the same line, the parser will take "message/cpim a=3Daccept- types:message/cpim" as the value of this attribute. Of course RFC defined as above your comment. right. I mean even though UA received above message, UA have to recognize that line has two attributes. Commonly UA SIP parser will have like this, as your comment. =3D a =3D message/cpim =3D a =3D accept-types:message/cpim In my experience, I have to apply as my comment. I have been wxperience commercial service in Japan with SIP Proxy Server.=20 RFC is RFC.. Field is Field. JP. -----Original Message----- From: Xiang Ting [mailto:x.victoria@gmail.com]=20 Sent: Wednesday, April 12, 2006 9:36 PM=20 To: =C0=CC=C1=BE=C7=CA Cc: simple@ietf.org; rohan@ekabal.com; fluffy@cisco.com Subject: Re: [Simple][MSRP]How to handle attribute lines with the same flag in SDP? Thank your for your reply. On 4/12/06, =C0=CC=C1=BE=C7=CA wrote: > > Hi. Xiang Ting. > > I think that is implementation dependant. If not detailed specified in=20 > RFC.. But I recommend as below. > > First... > a=3Daccept-types:message/cpim a=3Daccept-types:text/plain > > If UA received this message, then UA have two attribute by parsing =20 > one line. That is role of SIP parser. If parser didn't support that,=20 > that is the problem of parser. > > And UA recognize two attribute ,then each attribute attached listed=20 > structure in media field. After all, UA can use that attribute. > > Seciond... > a=3Daccept-types:message/cpim a=3Daccept-types:message/cpim > I do not agree with you about your opinion, According to RFC 2327 the format of attribute is "a=3D: ", so if one more "a=3D" = appears in the same line, the parser will take "message/cpim a=3Daccept- types:message/cpim" as the value of this attribute. > If UA received this message, then UA have two attribute by parsing one=20 > line, even though exactly same attribute value. This is role of SIP=20 > Parser. And SIP parser can detect incoming message has two attribute=20 > in one line. That is possible that recognize string such as " a=3D"=20 > ("blank + a > + '=3D'). > If SIP parser is genious, no problem. > > Third... > > Recommandation is below.... > > a=3Daccept-types:message/cpim > a=3Daccept-types:text/plain > > Each UA may use above style, each attribute in a line. > But sometimes proxy didn't send above information (two attributes) in=20 > each line. Even though UA SIP Parser have to detect that attributes=20 > each by each. > > Commonly UA have a list attributes for one media field. UA can use=20 > each attribute for itself. > > I hope will be help/. > > JP. > > -----Original Message----- > From: Xiang Ting [mailto:x.victoria@gmail.com] > Sent: Tuesday, April 11, 2006 11:47 PM > To: simple@ietf.org > Cc: rohan@ekabal.com; fluffy@cisco.com > Subject: [Simple][MSRP]How to handle attribute lines with the same=20 > flag in SDP? > > > In SIP,multiple header field rows with the same field-name MAY be=20 > present in a message (if the entire field-value for that header field=20 > is defined as a comma-separated list ). It MUST be possible to combine=20 > the multiple header field rows into one > "field-name: field-value" pair. > Implementations MUST be able to process multiple header field rows=20 > with the same name in any combination of the single-value-per-line or=20 > comma- separated value forms. While in RFC2327 and=20 > draft-ietf-simple-message- sessions , there is no specific rule that=20 > defines how should implementations deal with attribute which can take=20 > multiple values separated by space. e.g. If the following example=20 > appears ,how should implementations treat it?=20 > a=3Daccept-types:message/cpim a=3Daccept- types:text/plain There are=20 > alternative means now. One is only accept the first and ignore the=20 > others.The other is combining them into one attribute line spacing=20 > these accept-types with a space, as > below: > a=3Daccept-types:message/cpim text/plain > > But if the accept-types are the same,e.g. = a=3Daccept-types:message/cpim=20 > a=3Daccept-types:message/cpim then,how to deal with it ? > > > Thanks in advance. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 13 11:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3q6-0001dL-55; Thu, 13 Apr 2006 11:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU3q4-0001dB-Du for simple@ietf.org; Thu, 13 Apr 2006 11:34:32 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU3q3-0000Vn-5d for simple@ietf.org; Thu, 13 Apr 2006 11:34:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Apr 2006 17:34:27 +0200 Message-ID: <3ACC9A25264A684F82C71840111F97980163A6A8@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-simple-xcap: how to PUT attribute with namespace Thread-Index: AcZfD7/dz5VF99ciRzmJ/y5ICXsIaA== From: To: X-OriginalArrivalTime: 13 Apr 2006 15:34:29.0752 (UTC) FILETIME=[C138EF80:01C65F0F] X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Simple] draft-ietf-simple-xcap: how to PUT attribute with namespace X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 is it possible to PUT an attribute with namespace?=20 Example: I have document "index": I send following request: =20 PUT /.../index/~~/root/list/@ns:uri?xmlns(ns=3D"ns_url") HTTP/1.1 ... =20 "uri" Will it result following document? Thank you,=20 Silvestr Peknik Software Specialist TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 18 08:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0Y-0003dR-Qm; Tue, 18 Apr 2006 08:08:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVp0X-0003cf-DX for simple@ietf.org; Tue, 18 Apr 2006 08:08:37 -0400 Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVp0X-00027D-1D for simple@ietf.org; Tue, 18 Apr 2006 08:08:37 -0400 Received: from Pavillonquatre ([194.3.133.88]) by smtp12.clb.oleane.net with ESMTP id k3IC8P4J018770 for ; Tue, 18 Apr 2006 14:08:35 +0200 Message-Id: <200604181208.k3IC8P4J018770@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 18 Apr 2006 14:07:33 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZi4KwHkhhczwCqSgysiWJpepHIuA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Simple] Mobile TV World Congress 2007 - Paris - France X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1773393926==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1773393926== Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C8_01C662F1.6FFB7A30" This is a multi-part message in MIME format. ------=_NextPart_000_05C8_01C662F1.6FFB7A30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The Mobile TV World Congress, will be held in Paris January 23 to 26, together with the worldwide leader event TVoDSL 2007. Carriers, content providers and equipment vendors will address technical issues, describe the standardization process and discuss business and content delivery models. A call for proposals is online at: http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm ------=_NextPart_000_05C8_01C662F1.6FFB7A30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Mobile TV World = Congress, will be held in Paris January 23 to 26, together with the worldwide leader event = TVoDSL = 2007.

Carriers, content providers and equipment = vendors will address technical issues, describe the standardization process and = discuss business and content delivery models.

 

A call for proposals is online = at:

http://www.upperside.fr/mobiletv2007/mobiletv2007intro.htm

 

------=_NextPart_000_05C8_01C662F1.6FFB7A30-- --===============1773393926== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1773393926==-- From simple-bounces@ietf.org Tue Apr 18 10:38:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrKv-0002Y1-RT; Tue, 18 Apr 2006 10:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVrKu-0002Xt-MA for simple@ietf.org; Tue, 18 Apr 2006 10:37:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVrKt-0002nT-Dq for simple@ietf.org; Tue, 18 Apr 2006 10:37:48 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 18 Apr 2006 07:37:47 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,131,1144047600"; d="scan'208"; a="26107851:sNHT23165116" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3IEbkvF019513; Tue, 18 Apr 2006 10:37:47 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 10:37:46 -0400 Received: from [192.168.1.101] ([10.86.242.1]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 18 Apr 2006 10:37:46 -0400 Message-ID: <4444F9B9.4000609@cisco.com> Date: Tue, 18 Apr 2006 10:37:45 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] draft-ietf-simple-xcap: how to PUT attribute with namespace References: <3ACC9A25264A684F82C71840111F97980163A6A8@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F97980163A6A8@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Apr 2006 14:37:46.0420 (UTC) FILETIME=[A8BE6F40:01C662F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org inline. Silvestr.Peknik@tietoenator.com wrote: > Hello, > > is it possible to PUT an attribute with namespace? The namespace attribute can appear in a PUT, but its only purpose is to define namespace bindings for the matching operation on the URI. > > Example: > I have document "index": > > > > > > > I send following request: > > PUT /.../index/~~/root/list/@ns:uri?xmlns(ns="ns_url") HTTP/1.1 > ... > > "uri" > > Will it result following document? > > > > No. The xcap server would insert the attribute ns:uri="uri", but then when it verifies that the r-uri selects the thing that was just inserted, it will find that it doesnt since the ns prefix is not defined. Thus, the request will fail with a 409. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 20 21:19:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkJ1-0003Qb-Qw; Thu, 20 Apr 2006 21:19:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWkJ0-0003QT-73; Thu, 20 Apr 2006 21:19:30 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWkIz-0004qY-Tp; Thu, 20 Apr 2006 21:19:30 -0400 Received: from [203.178.157.234] (203-178-157-234.ip.sipit.net [203.178.157.234]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3L1Imr3009533 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 20 Apr 2006 20:18:50 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <276CE187-CF5C-43E0-B2FA-7FCE941F521F@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: sip@ietf.org, simple@ietf.org, sip-implementors@cs.columbia.edu From: Robert Sparks Date: Fri, 21 Apr 2006 10:18:15 +0900 X-Mailer: Apple Mail (2.749.3) Received-SPF: pass (nostrum.com: 203.178.157.234 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Subject: [Simple] preliminary report: SIPit 18 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org 160 people from 16 countries attended SIPit 18 with 73 different SIP implementations. A short summary of some of the capabilities of those implementations follows: UDP 73 TCP 53 TLS 30 SCTP 6 SRTP 10 (7 use sdes) rport 36 GRUU 5 outbound 2 connect-reuse 6 IPv6 19 Full 3263 25 3263 no naptr (SRV on) 13 A only 22 IP only (no DNS) 9 Session timer 38 Prack 32 (9 non-trivial users) Update 25 NIT fixes (4320) 7 Out of Dialog Refer 3 Dialog package 8 Turn 3 XCAP 4 (2 servers) Generally, the level of interoperability was very high. Very few of the attendees were aware of GRUU, but there were some implementations to test (and they interoperated). The big surprise was the number of SIP over SCTP implementations testing at this event. There was significant testing of TLS and SRTP. TLS interoperability is solidifying. SRTP interoperability was poor (key exchange is not working) There were several common implementation errors and questions. Below are rough descriptions of each (in no particular order). I'll send more detailed messages when I'm back online in a couple of weeks. - Several UAs were doing 3263 lookups but ignoring the port from the SRV record, always sending to 5060 - Many UAs are gratuitously putting ports in URIs when the appropriate thing to do would be to only place a domain name. This particularly caused error when the port retrieved from SRV was placed explicitly in the RURI of the message sent - There was non-trivial testing of RPID at this event. There was disagreement around where was legal or had meaning. - More than one implementation still has ACK-200 vs ACK-non200 confused. In particular, more than one implementation used the branch parameter from an INVITE in the ACK-200. There was also some confusion leading to reusing the INVITE branch parameter in PRACKs - Those testing IPv6 made different assumptions about enclosing literal v6 addresses in Vias in []. By the end of the event, most implementations were accepting either. Its about 50/50 on what gets sent. - The SIP over SCTP implementers point out a need for clarification around using the 1 to many vs 1 to 1 mode. - Several implementations (including a few mature ones) are still having case-insensitivity related interop problems. I saw arguments over "Digest" vs "DIGEST", and case sensitivity around mime-types. - There were many questions about record-routing when changing transports, and where the double-record-routing technique we've been suggesting people use is documented. - Implementers are looking for better guidance for solving the issue we identified with discarding transactions state on an ACK-200. We need to get more guidance into current bugzilla report and/or issue a draft on this soon. - There were a few XCAP tests at this event. Interoperability was mixed. Very little "just worked", but after agreements were made about URI paths and versions of schemas most tests were successful. - Several UAs still miss that request-merging and handling multiple-200s (or multiple 183s) is even a concern. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 21 00:35:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWnMc-0006S0-0Y; Fri, 21 Apr 2006 00:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWnMa-0006Ru-OE for simple@ietf.org; Fri, 21 Apr 2006 00:35:24 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWnMZ-0005Y3-AA for simple@ietf.org; Fri, 21 Apr 2006 00:35:24 -0400 Received: from unknown (HELO sinse211.ap.infineon.com) ([172.17.65.149]) by smtp3.infineon.com with ESMTP; 21 Apr 2006 12:35:20 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse211.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 21 Apr 2006 12:35:19 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Apr 2006 10:05:18 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MSRP SDP max size a-line thread-index: AcZk/P2iL5t4yxBLRGyKs1F8wLuI2A== From: To: , X-OriginalArrivalTime: 21 Apr 2006 04:35:20.0192 (UTC) FILETIME=[FF270000:01C664FC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [Simple] MSRP SDP max size a-line X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi All, In section 8.6 of draft-ietf-simple-message-sessions-13.txt =20 Max-size refers to the complete message in octets, not the size of any one chunk. Senders SHOULD NOT exceed the max-size limit for any message sent in the resulting session.=20 Does max size refer to max body size of the message or max message size which includes message headers and message body? Regards, Amit Kumar Goel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 21 02:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWov3-000642-SU; Fri, 21 Apr 2006 02:15:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWov1-00063x-Ro for simple@ietf.org; Fri, 21 Apr 2006 02:15:03 -0400 Received: from [130.94.222.106] (helo=citilindia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWoux-0001vO-3F for simple@ietf.org; Fri, 21 Apr 2006 02:15:03 -0400 Received: (qmail 8280 invoked by uid 24170); 21 Apr 2006 06:14:52 -0000 Received: from unknown (HELO IN00201) ([61.14.7.242]) (envelope-sender ) by 130.94.222.106 (qmail-ldap-1.03) with SMTP for ; 21 Apr 2006 06:14:52 -0000 Message-ID: <002e01c6650a$e7065cb0$6b0019ac@Trinity.local> From: "Abhijit A. Mahajani" To: Date: Fri, 21 Apr 2006 11:44:50 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Simple] where do i find Presence server? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1893046812==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1893046812== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C66538.FF436A60" This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C66538.FF436A60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 I am in process of developing SIP Instant Message and Presence Client. = For testing purposes i need Presence Server. where can i find Presence = Server ? either a freeware or paid one? As far as i know ONdo SIP proxy = server at present is not presence supported. is there any other SIP = server which supports Presence?Can somebody help me on this? Thanks in advance. Abhijit ------=_NextPart_000_0029_01C66538.FF436A60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi
I am in process of developing SIP = Instant Message=20 and Presence Client. For testing purposes i need Presence Server. where = can i=20 find Presence Server ? either a freeware or paid one?  As far as i = know=20 ONdo SIP proxy server at present is not presence supported. is there any = other=20 SIP server which supports Presence?Can somebody help me on = this?
Thanks in advance.
Abhijit
------=_NextPart_000_0029_01C66538.FF436A60-- --===============1893046812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1893046812==-- From simple-bounces@ietf.org Fri Apr 21 04:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWqwz-0008Rn-W1; Fri, 21 Apr 2006 04:25:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWqwy-0008QK-Vf for simple@ietf.org; Fri, 21 Apr 2006 04:25:12 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWqwv-00005r-6R for simple@ietf.org; Fri, 21 Apr 2006 04:25:12 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IY2002K3CPS6U@mailout3.samsung.com> for simple@ietf.org; Fri, 21 Apr 2006 17:25:04 +0900 (KST) Received: from LocalHost ([165.213.178.95]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IY2000XWCPRN6@mmp2.samsung.com> for simple@ietf.org; Fri, 21 Apr 2006 17:25:03 +0900 (KST) Date: Fri, 21 Apr 2006 17:23:57 +0900 From: =?ks_c_5601-1987?B?wMzBvsfK?= Subject: RE: [Simple] where do i find Presence server? In-reply-to: <002e01c6650a$e7065cb0$6b0019ac@Trinity.local> To: "'Abhijit A. Mahajani'" , simple@ietf.org Message-id: <003a01c6651c$ef78f850$5fb2d5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0224868268==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0224868268== Content-type: multipart/alternative; boundary="Boundary_(ID_qvlodb9cr2U8RhzeXDOzyA)" This is a multi-part message in MIME format. --Boundary_(ID_qvlodb9cr2U8RhzeXDOzyA) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Hi. I recommand that you may implement SIP Server emulator for Presence. If you can implement presence client, then you can make presence server emulator. That's the good approach, in my opinion. Best jp. -----Original Message----- From: Abhijit A. Mahajani [mailto:abhijit_m@citilindia.com] Sent: Friday, April 21, 2006 3:15 PM To: simple@ietf.org Subject: [Simple] where do i find Presence server? Hi I am in process of developing SIP Instant Message and Presence Client. For testing purposes i need Presence Server. where can i find Presence Server ? either a freeware or paid one? As far as i know ONdo SIP proxy server at present is not presence supported. is there any other SIP server which supports Presence?Can somebody help me on this? Thanks in advance. Abhijit --Boundary_(ID_qvlodb9cr2U8RhzeXDOzyA) Content-type: text/html; charset=ks_c_5601-1987 Content-transfer-encoding: quoted-printable =B8=DE=BD=C3=C1=F6
Hi.
 
I=20 recommand that you may implement SIP Server emulator for=20 Presence.
 
If you can implement presence client, then = you can make=20 presence server emulator.
 
That's the good approach, in my=20 opinion.
 
Best jp.
-----Original Message-----
From: Abhijit A. = Mahajani=20 [mailto:abhijit_m@citilindia.com]
Sent: Friday, April 21, = 2006 3:15=20 PM
To: simple@ietf.org
Subject: [Simple] where do = i find=20 Presence server?

Hi
I am in process of developing SIP = Instant Message=20 and Presence Client. For testing purposes i need Presence Server. = where can i=20 find Presence Server ? either a freeware or paid one?  As far as = i know=20 ONdo SIP proxy server at present is not presence supported. is there = any other=20 SIP server which supports Presence?Can somebody help me on = this?
Thanks in advance.
Abhijit
--Boundary_(ID_qvlodb9cr2U8RhzeXDOzyA)-- --===============0224868268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0224868268==-- From simple-bounces@ietf.org Fri Apr 21 09:19:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvXT-0005Lj-9t; Fri, 21 Apr 2006 09:19:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvXS-0005LH-89 for simple@ietf.org; Fri, 21 Apr 2006 09:19:10 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWvXP-00071N-S5 for simple@ietf.org; Fri, 21 Apr 2006 09:19:10 -0400 Received: from [192.168.1.105] (c-24-1-44-191.hsd1.tx.comcast.net [24.1.44.191]) (authenticated bits=0) by vicuna.estacado.net (8.13.4/8.13.4) with ESMTP id k3LDJ6PP040789 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 21 Apr 2006 08:19:06 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4FAD0A25-1EEA-4277-8346-7340671324ED@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] MSRP SDP max size a-line Date: Fri, 21 Apr 2006 08:19:01 -0500 To: "" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 1.1 (+) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: msrp@list.sipfoundry.org, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Neither really. The term "message" in this context refers to a MIME encapsulated unit of content sent by the user. It can chuncked across more than one SEND request. Thanks! Ben. On Apr 20, 2006, at 11:35 PM, wrote: > > Hi All, > > In section 8.6 of draft-ietf-simple-message-sessions-13.txt > Max-size refers to the complete message in octets, not the size of any > one chunk. Senders SHOULD NOT exceed the max-size limit for any > message > sent in the resulting session. > > Does max size refer to max body size of the message or max message > size > which includes message headers and message body? > > Regards, > Amit Kumar Goel > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Sun Apr 23 15:34:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXkLV-0007qh-FZ; Sun, 23 Apr 2006 15:34:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXkLU-0007qc-IW for simple@ietf.org; Sun, 23 Apr 2006 15:34:12 -0400 Received: from smtp2.versatel.nl ([62.58.50.89]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXkLU-0004bN-4s for simple@ietf.org; Sun, 23 Apr 2006 15:34:12 -0400 Received: (qmail 5751 invoked by uid 0); 23 Apr 2006 19:34:08 -0000 Received: from ip49-113-59-81.dyndsl.versatel.nl (HELO BEMBUSTER) ([81.59.113.49]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 23 Apr 2006 19:34:08 -0000 Message-ID: <002501c6670c$e1509160$31713b51@BEMBUSTER> From: "Jeroen van Bemmel" To: Date: Sun, 23 Apr 2006 21:34:04 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [Simple] route set handling for forked SUBSCRIBEs X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1917720580==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1917720580== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01C6671D.A4A754E0" This is a multi-part message in MIME format. ------=_NextPart_000_0022_01C6671D.A4A754E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, A question about RFC3265 regarding route set handling: Suppose I have a = setup with a Subscriber (S), a forking proxy (P) and two notifiers (N1 = and N2). S sends a SUBSCRIBE, P forks it to N1 and N2 while adding a = Record-Route header specific for each notifier. P will receive a 2xx response from both N1 and N2. Whichever response is = received first will be passed on to S, the second response is discarded = (since P forks, it must behave transaction statefully). P then receives = 2 NOTIFY requests, one from N1 and one from N2. It forwards both to S, = which creates a new dialog for each. Question is now: how does S establish the correct route set for the = NOTIFY, for which no 2xx response was received? According to RFC3265 P is required to Record-Route all NOTIFYs resulting = from a forked SUBSCRIBE, probably because that enables S to construct = the route set for each subscription. The rule should then probably be = something like "if 2xx was received for SUBSCRIBE, use the route set = from that, else use the route set found in the first NOTIFY" However, RFC3265 is silent on this Best regards, Jeroen van Bemmel ------=_NextPart_000_0022_01C6671D.A4A754E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
A question about RFC3265 regarding = route set=20 handling: Suppose I have a setup with a Subscriber (S), a forking = proxy=20 (P) and two notifiers (N1 and N2). S sends a SUBSCRIBE, P forks it = to N1=20 and N2 while adding a Record-Route header specific for each=20 notifier.
 
P will receive a 2xx response from both = N1 and N2.=20 Whichever response is received first will be passed on to S, the second = response=20 is discarded (since P forks, it must behave transaction = statefully). P then=20 receives 2 NOTIFY requests, one from N1 and one from N2. It forwards = both to S,=20 which creates a new dialog for each.
 
Question is now: how does S establish = the correct=20 route set for the NOTIFY, for which no 2xx response was = received?
 
According to RFC3265 P is required to = Record-Route=20 all NOTIFYs resulting from a forked SUBSCRIBE, probably because that = enables S=20 to construct the route set for each subscription. The rule should then = probably=20 be something like "if 2xx was received for SUBSCRIBE, use the route set = from=20 that, else use the route set found in the first NOTIFY"
 
However, RFC3265 is silent on = this
 
Best regards,
 
Jeroen van Bemmel
 
------=_NextPart_000_0022_01C6671D.A4A754E0-- --===============1917720580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1917720580==-- From simple-bounces@ietf.org Sun Apr 23 19:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXoJw-0005PQ-89; Sun, 23 Apr 2006 19:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXoJu-0005OC-4C for simple@ietf.org; Sun, 23 Apr 2006 19:48:50 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXoJr-0000pY-2V for simple@ietf.org; Sun, 23 Apr 2006 19:48:50 -0400 Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IY700F938T2FZ@mailout1.samsung.com> for simple@ietf.org; Mon, 24 Apr 2006 08:48:38 +0900 (KST) Received: from LocalHost ([165.213.178.95]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IY700GCK8T1B7@mmp1.samsung.com> for simple@ietf.org; Mon, 24 Apr 2006 08:48:38 +0900 (KST) Date: Mon, 24 Apr 2006 08:47:41 +0900 From: =?ks_c_5601-1987?B?wMzBvsfK?= Subject: RE: [Simple] route set handling for forked SUBSCRIBEs In-reply-to: <002501c6670c$e1509160$31713b51@BEMBUSTER> To: 'Jeroen van Bemmel' , simple@ietf.org Message-id: <000701c66730$4f856070$5fb2d5a5@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0814972262==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============0814972262== Content-type: multipart/alternative; boundary="Boundary_(ID_d1o1zTW7g4/IOrfuaWDJMw)" This is a multi-part message in MIME format. --Boundary_(ID_d1o1zTW7g4/IOrfuaWDJMw) Content-type: text/plain; charset=ks_c_5601-1987 Content-transfer-encoding: 7BIT Hi. In my experience, that situation will be happened freequently, and have to solve that routing route for each UA. SUBSCRIBE and NOTIFY is request method. So at that case, receiver side have to make route set regarding as request message. BEST, JP. -----Original Message----- From: Jeroen van Bemmel [mailto:jbemmel@zonnet.nl] Sent: Monday, April 24, 2006 4:34 AM To: simple@ietf.org Subject: [Simple] route set handling for forked SUBSCRIBEs Hi, A question about RFC3265 regarding route set handling: Suppose I have a setup with a Subscriber (S), a forking proxy (P) and two notifiers (N1 and N2). S sends a SUBSCRIBE, P forks it to N1 and N2 while adding a Record-Route header specific for each notifier. P will receive a 2xx response from both N1 and N2. Whichever response is received first will be passed on to S, the second response is discarded (since P forks, it must behave transaction statefully). P then receives 2 NOTIFY requests, one from N1 and one from N2. It forwards both to S, which creates a new dialog for each. Question is now: how does S establish the correct route set for the NOTIFY, for which no 2xx response was received? According to RFC3265 P is required to Record-Route all NOTIFYs resulting from a forked SUBSCRIBE, probably because that enables S to construct the route set for each subscription. The rule should then probably be something like "if 2xx was received for SUBSCRIBE, use the route set from that, else use the route set found in the first NOTIFY" However, RFC3265 is silent on this Best regards, Jeroen van Bemmel --Boundary_(ID_d1o1zTW7g4/IOrfuaWDJMw) Content-type: text/html; charset=ks_c_5601-1987 Content-transfer-encoding: quoted-printable =B8=DE=BD=C3=C1=F6
Hi.
 
In my experience, that situation will be happened freequently, = and have=20 to solve that routing route for each UA.
 
SUBSCRIBE and NOTIFY is request method. =
 
So at that case,  receiver side have to make route = set=20 regarding as request message.
 
BEST,=20 JP.
-----Original Message-----
From: Jeroen van Bemmel=20 [mailto:jbemmel@zonnet.nl]
Sent: Monday, April 24, 2006 = 4:34=20 AM
To: simple@ietf.org
Subject: [Simple] route set = handling for forked SUBSCRIBEs

Hi,
 
A question about RFC3265 = regarding route set=20 handling: Suppose I have a setup with a Subscriber (S), a forking = proxy=20 (P) and two notifiers (N1 and N2). S sends a SUBSCRIBE, P forks = it to N1=20 and N2 while adding a Record-Route header specific for each=20 notifier.
 
P will receive a 2xx response from = both N1 and=20 N2. Whichever response is received first will be passed on to S, the = second=20 response is discarded (since P forks, it must behave transaction=20 statefully). P then receives 2 NOTIFY requests, one from N1 and = one from=20 N2. It forwards both to S, which creates a new dialog for=20 each.
 
Question is now: how does S establish = the correct=20 route set for the NOTIFY, for which no 2xx response was = received?
 
According to RFC3265 P is required to = Record-Route all NOTIFYs resulting from a forked SUBSCRIBE, probably = because=20 that enables S to construct the route set for each subscription. The = rule=20 should then probably be something like "if 2xx was received for = SUBSCRIBE, use=20 the route set from that, else use the route set found in the first=20 NOTIFY"
 
However, RFC3265 is silent on = this
 
Best regards,
 
Jeroen van Bemmel
 
--Boundary_(ID_d1o1zTW7g4/IOrfuaWDJMw)-- --===============0814972262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0814972262==-- From simple-bounces@ietf.org Mon Apr 24 06:26:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyGd-0003tW-KC; Mon, 24 Apr 2006 06:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyGc-0003tR-73 for simple@ietf.org; Mon, 24 Apr 2006 06:26:06 -0400 Received: from mail.tieto.com ([194.110.47.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXyGa-0002ut-DR for simple@ietf.org; Mon, 24 Apr 2006 06:26:06 -0400 Received: from viper.eu.tieto.com ([194.110.47.167]) by mail.tieto.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Apr 2006 13:25:25 +0300 Received: from stingray.eu.tieto.com ([192.176.143.14]) by viper.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 13:26:02 +0300 Received: from carrera.eu.tieto.com ([192.176.158.112]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 12:25:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Apr 2006 12:25:53 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798016CB865@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-simple-event-list: identifying list subscriptions Thread-Index: AcZniXcW6KUyfA30RReEGEuF/z4rOg== From: To: X-OriginalArrivalTime: 24 Apr 2006 10:25:59.0391 (UTC) FILETIME=[7ABB3EF0:01C66789] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Simple] draft-ietf-simple-event-list: identifying list subscriptions X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 As mentioned in the draft, SIP URI does not indicate whether it belongs to list of resources or to single resource. Can I assume that Supported: eventlist header means that the subscription is a list subscription, or can it happen that also subscription to single resource contains Supported: eventlist? This differentiation is needed if the server handles both subscriptions to list and subscriptions to single resources ... Thank you,=20 Silvestr Peknik Software Specialist TietoEnator _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 24 14:16:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5bx-0002Qb-54; Mon, 24 Apr 2006 14:16:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5bv-0002QI-F2 for simple@ietf.org; Mon, 24 Apr 2006 14:16:35 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY4pW-00077r-W0 for simple@ietf.org; Mon, 24 Apr 2006 13:26:35 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FY4f0-0006Td-Qn for simple@ietf.org; Mon, 24 Apr 2006 13:15:46 -0400 Received: from [172.17.2.251] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.4) with ESMTP id k3OHFcL1084760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 12:15:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <444D07B9.5000109@nostrum.com> Date: Mon, 24 Apr 2006 12:15:37 -0500 From: Adam Roach User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Silvestr.Peknik@tietoenator.com Subject: Re: [Simple] draft-ietf-simple-event-list: identifying list subscriptions References: <3ACC9A25264A684F82C71840111F9798016CB865@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F9798016CB865@carrera.eu.tieto.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: -2.0 (--) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Silvestr.Peknik@tietoenator.com wrote: > As mentioned in the draft, SIP URI does not indicate whether it belongs > to list of resources or to single resource. Can I assume that Supported: > eventlist header means that the subscription is a list subscription, or > can it happen that also subscription to single resource contains > Supported: eventlist? The "Supported: eventlist" header field in the request simply means that the client *understands* list subscriptions. It has no implication regarding whether the client expects the indicated resource to be a list or not. So, the statement is even stronger than you put it: it's not just that a subscription to a single resource *CAN* contain "Supported: eventlist" -- it's that it *MUST* contain "Supported: eventlist" if the subscriber understands the event list format. (I'm using this "must" as a "this is the only way, in my opinion, a reasonable implementation can behave," not as a standards statement. The specification would technically allow the client to pick and choose which subscriptions to indicate event list support -- but not indicating support for event lists would always make things work worse, and never better). > This differentiation is needed if the server > handles both subscriptions to list and subscriptions to single resources No, it's not. It *is* true that the server needs to know whether a subscription is to be treated as a list subscription or as a subscription to a single resource. This is exactly the same statement that a terminating MTA needs to know whether an email message is intended for a single account or for a mailing list. In both cases, the server knows this *independent* of what the client sends. The server knows whether it's a single resource or whether it's a list because it's *provisioned* to know which URIs (or email addresses) correspond to single resources and which URIs (or email addresses) correspond to lists. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 26 02:56:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYdwd-0004h7-Bg; Wed, 26 Apr 2006 02:56:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FV9Gk-0002uZ-Sn for simple@ietf.org; Sun, 16 Apr 2006 11:34:34 -0400 Received: from il-tlv-smtpgateway.comverse.com ([192.118.48.242] helo=il-tlv-smtpout1.icomverse.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FV9Gj-0004E9-9R for simple@ietf.org; Sun, 16 Apr 2006 11:34:34 -0400 Received: from il-tlv-bridge01.comverse.com (il-tlv-bridge01.comverse.com [10.115.242.136]) by il-tlv-smtpout1.icomverse.com (8.13.4/8.13.4) with ESMTP id k3GFYSxP024572; Sun, 16 Apr 2006 18:34:29 +0300 Received: from il-tlv-mail01.comverse.com ([10.115.242.87]) by il-tlv-bridge01.comverse.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 16 Apr 2006 18:34:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Apr 2006 18:34:27 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions regarding Presence Internet Drafts Thread-Index: AcZhaz8UNXKV5c1WTpiiVHWZ9xTEHg== From: "Tor Noga" To: X-OriginalArrivalTime: 16 Apr 2006 15:34:28.0611 (UTC) FILETIME=[3FC81530:01C6616B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Wed, 26 Apr 2006 02:56:12 -0400 Cc: jdrosen@jdrosen.net Subject: [Simple] Questions regarding Presence Internet Drafts X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772658461==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1772658461== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6616B.3F761DC2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6616B.3F761DC2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I was wondering to where I can forward regarding various presence issues, appearing in the IETF darfts. Thanks Noga Tor ------_=_NextPart_001_01C6616B.3F761DC2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Questions regarding Presence Internet Drafts

Hi

I was = wondering to where I can forward regarding various presence issues, = appearing in the IETF darfts.

Thanks

Noga = Tor

------_=_NextPart_001_01C6616B.3F761DC2-- --===============1772658461== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1772658461==-- From simple-bounces@ietf.org Wed Apr 26 04:12:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYf7s-0006su-7Y; Wed, 26 Apr 2006 04:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYf7q-0006sp-Sp for simple@ietf.org; Wed, 26 Apr 2006 04:11:54 -0400 Received: from hq-smtp-01.telio.no ([82.196.203.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYf7p-00057T-Dw for simple@ietf.org; Wed, 26 Apr 2006 04:11:54 -0400 Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119]) by hq-smtp-01.telio.no (Postfix) with ESMTP id 15834194492 for ; Wed, 26 Apr 2006 10:11:52 +0200 (CEST) Received: from [192.168.1.26] ([192.168.1.26]) by office-owa-01.HQ.TELIO.NO with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Apr 2006 10:09:51 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Questions regarding Presence Internet Drafts Date: Wed, 26 Apr 2006 10:11:35 +0200 To: "Tor Noga" X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 26 Apr 2006 08:09:51.0022 (UTC) FILETIME=[CAD48CE0:01C66908] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jdrosen@jdrosen.net, simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org If you are referring to the SIP/SIMPLE presence drafts, then this is the right place. Thanks, Hisham On Apr 16, 2006, at 5:34 PM, Tor Noga wrote: > Hi > > I was wondering to where I can forward regarding various presence > issues, appearing in the IETF darfts. > > Thanks > > Noga Tor > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 27 07:52:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ527-0008Lg-61; Thu, 27 Apr 2006 07:51:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ526-0008Ft-0v for simple@ietf.org; Thu, 27 Apr 2006 07:51:42 -0400 Received: from nproxy.gmail.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ522-0007rD-N1 for simple@ietf.org; Thu, 27 Apr 2006 07:51:41 -0400 Received: by nproxy.gmail.com with SMTP id l36so1281631nfa for ; Thu, 27 Apr 2006 04:51:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=LzPp5+laLzXp2Dg0PbJiKhqsILmCQQFy7wXGnLf3hP+yZLwCzAiVEB2kt9y22g7CQhCwH6H4w9F3cDFM0YTYAYSdOtpTLl3XHJ9tj3W6LfL6RCfraDn0lLnHrvsrRx1ij1gNz/UtVfZeSBFw300Rn19R1Q65pSFu7Aj4whXAVOA= Received: by 10.48.12.19 with SMTP id 19mr4883038nfl; Thu, 27 Apr 2006 04:51:35 -0700 (PDT) Received: by 10.48.225.18 with HTTP; Thu, 27 Apr 2006 04:51:35 -0700 (PDT) Message-ID: <44781c350604270451m1d7be71bx2a3c94be70d7472c@mail.gmail.com> Date: Thu, 27 Apr 2006 14:51:35 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Simple] Merging PIDF documents from multiple sources X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1360478030==" Errors-To: simple-bounces@ietf.org --===============1360478030== Content-Type: multipart/alternative; boundary="----=_Part_2302_52818.1146138695664" ------=_Part_2302_52818.1146138695664 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Im trying to understand what should be the strategy when merging doucments that were published from different sources. Should all published person\tuple\device elements be sent to the Watcher as received? Or should a merge strategy be implemented? How should the Notify message look like? (assuming the watcher did not add any filters to the subscription) Should it contain all the published elements? (multiple person/device elements) Or should it contain merged publish elements? (one person/device element) Or should it contain just the last published elements? (one person/device element) Thanks Noga Tor ------=_Part_2302_52818.1146138695664 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi

Im tryi= ng to understand what should be the strategy when merging doucments that we= re published from different sources.

Should = all published person\tuple\device elements be sent to the Watcher as receiv= ed?

Or shou= ld a merge strategy be implemented?

How sho= uld the Notify message look like? (assuming the watcher did not add any fil= ters to the subscription)

Shoul= d it contain all the published elements? (multiple person/device elements)<= /font>
 =
Or should it contain merged publish elements? (one p= erson/device element)

Or shou= ld it contain just the last published elements? (one person/device element)=

Thanks<= /font>

Noga To= r


------=_Part_2302_52818.1146138695664-- --===============1360478030== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1360478030==-- From simple-bounces@ietf.org Thu Apr 27 08:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5Gc-0006dG-I8; Thu, 27 Apr 2006 08:06:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ5Gb-0006d8-Ee; Thu, 27 Apr 2006 08:06:41 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ5GZ-0008Tj-Vl; Thu, 27 Apr 2006 08:06:41 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 27 Apr 2006 20:06:36 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 Apr 2006 20:06:36 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 27 Apr 2006 17:36:11 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Handling of incoming INVITE request for different MSRP session thread-index: AcZp8vityjmnW2ngShiAQ5dKpqJBjQ== From: To: , X-OriginalArrivalTime: 27 Apr 2006 12:06:36.0459 (UTC) FILETIME=[0857F7B0:01C669F3] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: OMA-MWG-IM@MAIL.OPENMOBILEALLIANCE.ORG Subject: [Simple] Handling of incoming INVITE request for different MSRP session X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Garcia, Ben and all, draft-garcia-sipping-file-transfer-mech-00.txt mandates that there should be separate msrp session (separate m-line) for the file transfer. But draft-ietf-simple-message-sessions-14.txt does not really differentiate between normal chat session and file transfer session. Also, it also does not mention the direction attribute. So User can also have uni directional MSRP session.=20 If user wants to create a session for chat and file transfer in the single SIP INVITE. Considering the above mentioned drafts, our understanding is that we will get two different m-lines in SDP offer for msrp sessions.=20 In such a scenario, how do we handle a case where we receive a SIP INVITE with a SDP offer containing both types of attributes (for text messaging and file transfer) in a single m-line? For example if we receive an OFFER. v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com s=3D c=3DIN IP4 host.atlanta.example.com t=3D0 0 m=3Dmessage 7654 TCP/MSRP * a=3Dsendonly a=3Daccept-types:text/plain * a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp a=3Dfilename:My cool picture.jpg a=3Dfiletype:image/jpeg a=3Ddisposition:inline a=3Dfilesize:32349 a=3Dicon:cid:id2@alicepc.example.com a=3Dhash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e Regards, Amit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 27 09:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6tV-0002yT-8p; Thu, 27 Apr 2006 09:50:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6tS-0002yE-N6; Thu, 27 Apr 2006 09:50:54 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6tR-0005xO-5w; Thu, 27 Apr 2006 09:50:54 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3RDledP014720; Thu, 27 Apr 2006 16:47:41 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 16:49:51 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Apr 2006 16:49:51 +0300 Message-ID: <4450CC00.7010904@nokia.com> Date: Thu, 27 Apr 2006 16:49:52 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Amitkumar.Goel@infineon.com Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2006 13:49:51.0669 (UTC) FILETIME=[74F9FE50:01C66A01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: sipping@ietf.org, simple@ietf.org, OMA-MWG-IM@MAIL.OPENMOBILEALLIANCE.ORG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Amit: As you correctly mentioned, the spirit of the file transfer draft is to reuse existing MSRP sessions, if they are available. But we always signal them in different m= lines. Notice that in the example you provided below there is only one m= line (for file transfer), so if you wanted to have chat and file transfer, you should have two m=message lines, one is a regular MSRP (chat), the other specific for file transfer. So, your question... "how do we handle a case where we receive a SIP INVITE with a SDP offer containing both types of attributes (for text messaging and file transfer) in a single m-line? " seems to be not applicable. We will have two m=message line, each one can have its own direction attribute if needed. BR, Miguel simple-bounces@ietf.org wrote: > Hi Garcia, Ben and all, > > draft-garcia-sipping-file-transfer-mech-00.txt mandates that there > should be separate msrp session (separate m-line) for the file transfer. > But draft-ietf-simple-message-sessions-14.txt does not really > differentiate between normal chat session and file transfer session. > Also, it also does not mention the direction attribute. So User can also > have uni directional MSRP session. > > If user wants to create a session for chat and file transfer in the > single SIP INVITE. Considering the above mentioned drafts, our > understanding is that we will get two different m-lines in SDP offer for > msrp sessions. > > In such a scenario, how do we handle a case where we receive a SIP > INVITE with a SDP offer containing both types of attributes (for text > messaging and file transfer) in a single m-line? For example if we > receive an OFFER. > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s= > c=IN IP4 host.atlanta.example.com > t=0 0 > m=message 7654 TCP/MSRP * > a=sendonly > a=accept-types:text/plain * > a=path:msrp://atlanta.example.com:7654/jshA7we;tcp > a=filename:My cool picture.jpg > a=filetype:image/jpeg > a=disposition:inline > a=filesize:32349 > a=icon:cid:id2@alicepc.example.com > a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e > > Regards, > Amit > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 27 10:15:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Go-0005Bw-9M; Thu, 27 Apr 2006 10:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Gn-0005Bo-0o for simple@ietf.org; Thu, 27 Apr 2006 10:15:01 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7Gh-0007RS-Lz for simple@ietf.org; Thu, 27 Apr 2006 10:15:00 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k3REEnN0010458; Thu, 27 Apr 2006 09:14:50 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 Apr 2006 15:14:49 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB00C29086D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Noga Tor'" , simple@ietf.org Subject: RE: [Simple] Merging PIDF documents from multiple sources Date: Thu, 27 Apr 2006 15:14:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0350337504==" Errors-To: simple-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0350337504== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66A04.7356F06E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C66A04.7356F06E Content-Type: text/plain; charset="iso-8859-1" I believe this was intended to be covered by: draft-rosenberg-simple-presence-processing-model-01.txt which expired in February and is therefore no longer on the i-d area. It can however be found here: http://www.softarmor.com/wgdb/docs/draft-rosenberg-simple-presence-processing-model-01.txt regards Keith -----Original Message----- From: Noga Tor [mailto:noga.tor@gmail.com] Sent: 27 April 2006 12:52 To: simple@ietf.org Subject: [Simple] Merging PIDF documents from multiple sources Hi Im trying to understand what should be the strategy when merging doucments that were published from different sources. Should all published person\tuple\device elements be sent to the Watcher as received? Or should a merge strategy be implemented? How should the Notify message look like? (assuming the watcher did not add any filters to the subscription) Should it contain all the published elements? (multiple person/device elements) Or should it contain merged publish elements? (one person/device element) Or should it contain just the last published elements? (one person/device element) Thanks Noga Tor ------_=_NextPart_001_01C66A04.7356F06E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 believe this was intended to be covered by:
 
draft-rosenberg-simple-presence-processing-model-01.txt<= /FONT>
 
which expired in February and is therefore = no longer on=20 the i-d area.
 
It can however be found=20 here:
 
http://www.softarmor.com/wgdb/docs/draft-ros= enberg-simple-presence-processing-model-01.txt
 
regards
 
Keith
-----Original Message-----
From: Noga Tor=20 [mailto:noga.tor@gmail.com]
Sent: 27 April 2006 = 12:52
To:=20 simple@ietf.org
Subject: [Simple] Merging PIDF documents = from=20 multiple sources

Hi =

Im trying = to understand=20 what should be the strategy when merging doucments that were = published from=20 different sources.

Should = all published=20 person\tuple\device elements be sent to the Watcher as=20 received?

Or should = a merge strategy=20 be implemented?

How = should the Notify=20 message look like? (assuming the watcher did not add any filters to = the=20 subscription)

Should = it contain all=20 the published elements? (multiple person/device = elements)
 
Or should it contain merged publish elements? (one = person/device=20 element)

Or should = it contain just=20 the last published elements? (one person/device = element)

Thanks

Noga=20 Tor


------_=_NextPart_001_01C66A04.7356F06E-- --===============0350337504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0350337504==-- From simple-bounces@ietf.org Thu Apr 27 10:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7H3-0005En-T2; Thu, 27 Apr 2006 10:15:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7H2-0005DZ-6U; Thu, 27 Apr 2006 10:15:16 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7Gx-0007T0-9O; Thu, 27 Apr 2006 10:15:16 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3REEwM4000486; Thu, 27 Apr 2006 19:45:03 +0530 Date: Thu, 27 Apr 2006 19:44:11 +0530 To: "Miguel Garcia" , Amitkumar.Goel@infineon.com Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146146474" MIME-Version: 1.0 Message-ID: In-Reply-To: <4450CC00.7010904@nokia.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: sipping@ietf.org, simple@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ------=neXtPaRt_1146146474 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, Is it valid to have two m= lines in a single INVITE? If such is a case, Is it valid to have two MSRP sessions created for each of the media line? As per the draft on File transfer using MSRP, once the File transfer is completed, the MSRP Session associated with it will be closed. So it should be apt to have 2 sessions for each of the media line. Regds, Sudha On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia wrote: > Hi Amit: > > As you correctly mentioned, the spirit of the file transfer draft is to > reuse existing MSRP sessions, if they are available. But we always > signal them in different m= lines. Notice that in the example you > provided below there is only one m= line (for file transfer), so if you > wanted to have chat and file transfer, you should have two m=message > lines, one is a regular MSRP (chat), the other specific for file > transfer. > > So, your question... "how do we handle a case where we receive a SIP > INVITE with a SDP offer containing both types of attributes (for text > messaging and file transfer) in a single m-line? " seems to be not > applicable. We will have two m=message line, each one can have its own > direction attribute if needed. > > BR, > > Miguel > > > simple-bounces@ietf.org wrote: >> Hi Garcia, Ben and all, >> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >> should be separate msrp session (separate m-line) for the file transfer. >> But draft-ietf-simple-message-sessions-14.txt does not really >> differentiate between normal chat session and file transfer session. >> Also, it also does not mention the direction attribute. So User can also >> have uni directional MSRP session. If user wants to create a session >> for chat and file transfer in the >> single SIP INVITE. Considering the above mentioned drafts, our >> understanding is that we will get two different m-lines in SDP offer for >> msrp sessions. In such a scenario, how do we handle a case where we >> receive a SIP >> INVITE with a SDP offer containing both types of attributes (for text >> messaging and file transfer) in a single m-line? For example if we >> receive an OFFER. >> v=0 >> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >> s= >> c=IN IP4 host.atlanta.example.com >> t=0 0 >> m=message 7654 TCP/MSRP * >> a=sendonly >> a=accept-types:text/plain * >> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >> a=filename:My cool picture.jpg >> a=filetype:image/jpeg >> a=disposition:inline >> a=filesize:32349 >> a=icon:cid:id2@alicepc.example.com >> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >> Regards, >> Amit >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > -- Best Regards, Sudha V.S ------=neXtPaRt_1146146474 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146146474 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=neXtPaRt_1146146474-- From simple-bounces@ietf.org Thu Apr 27 10:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7RZ-0007lo-1U; Thu, 27 Apr 2006 10:26:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7RX-0007ld-PL; Thu, 27 Apr 2006 10:26:07 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7RX-00085o-9G; Thu, 27 Apr 2006 10:26:07 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3RENV6b003141; Thu, 27 Apr 2006 17:23:34 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 17:26:00 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 Apr 2006 17:26:00 +0300 Message-ID: <4450D479.8090603@nokia.com> Date: Thu, 27 Apr 2006 17:26:01 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sudha Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2006 14:26:00.0595 (UTC) FILETIME=[81C1D630:01C66A06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: OMA-MWG-IM@mail.openmobilealliance.org, sipping@ietf.org, simple@ietf.org, Amitkumar.Goel@infineon.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Sudha: Inline discussion. Sudha wrote: > Hi all, > Is it valid to have two m= lines in a single INVITE? Yes, of course. > If such is a case, Is it valid to have two MSRP sessions created for > each of the media line? yes, why not? > As per the draft on File transfer using MSRP, > once the File transfer is completed, the MSRP Session associated with it > will be closed. So it should be apt to have 2 sessions for each of the > media line. I am not sure what you mean with "2 sessions fr each of the media line". Each m=message represents an MSRP media stream. Both can use the same MSRP session (TCP connection + session-id in MSRP), but they are different media streams, just multiplexed over the same TCP connection and MSRP session. BR, Miguel > > Regds, > Sudha > > On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia > wrote: > >> Hi Amit: >> >> As you correctly mentioned, the spirit of the file transfer draft is >> to reuse existing MSRP sessions, if they are available. But we always >> signal them in different m= lines. Notice that in the example you >> provided below there is only one m= line (for file transfer), so if >> you wanted to have chat and file transfer, you should have two >> m=message lines, one is a regular MSRP (chat), the other specific for >> file transfer. >> >> So, your question... "how do we handle a case where we receive a SIP >> INVITE with a SDP offer containing both types of attributes (for text >> messaging and file transfer) in a single m-line? " seems to be not >> applicable. We will have two m=message line, each one can have its own >> direction attribute if needed. >> >> BR, >> >> Miguel >> >> >> simple-bounces@ietf.org wrote: >>> Hi Garcia, Ben and all, >>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>> should be separate msrp session (separate m-line) for the file transfer. >>> But draft-ietf-simple-message-sessions-14.txt does not really >>> differentiate between normal chat session and file transfer session. >>> Also, it also does not mention the direction attribute. So User can also >>> have uni directional MSRP session. If user wants to create a session >>> for chat and file transfer in the >>> single SIP INVITE. Considering the above mentioned drafts, our >>> understanding is that we will get two different m-lines in SDP offer for >>> msrp sessions. In such a scenario, how do we handle a case where we >>> receive a SIP >>> INVITE with a SDP offer containing both types of attributes (for text >>> messaging and file transfer) in a single m-line? For example if we >>> receive an OFFER. >>> v=0 >>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>> s= >>> c=IN IP4 host.atlanta.example.com >>> t=0 0 >>> m=message 7654 TCP/MSRP * >>> a=sendonly >>> a=accept-types:text/plain * >>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>> a=filename:My cool picture.jpg >>> a=filetype:image/jpeg >>> a=disposition:inline >>> a=filesize:32349 >>> a=icon:cid:id2@alicepc.example.com >>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>> Regards, >>> Amit >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> > > > > --Best Regards, > Sudha V.S -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 27 10:34:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Yx-0002Pe-4J; Thu, 27 Apr 2006 10:33:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7Yv-0002OY-Pk; Thu, 27 Apr 2006 10:33:45 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7Yt-00008B-KZ; Thu, 27 Apr 2006 10:33:45 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3REXNGH002567; Thu, 27 Apr 2006 20:03:23 +0530 Date: Thu, 27 Apr 2006 20:02:34 +0530 To: Sudha , "Miguel Garcia" , Amitkumar.Goel@infineon.com Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146147587" MIME-Version: 1.0 Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: sipping@ietf.org, simple@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ------=neXtPaRt_1146147587 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, Having two media lines(m=) in the same INVITE for MSRP, is quiet impossible because, - Two Media lines would result in 2 "path" attributes which complicates the situation. - It is quiet impossible to distinguish the accept types of normal MSRP chat session and MSRP File Transfer Session Regds, Sudha On Thu, 27 Apr 2006 19:44:11 +0530, Sudha wrote: > Hi all, > Is it valid to have two m= lines in a single INVITE? > If such is a case, Is it valid to have two MSRP sessions created for > each of the media line? As per the draft on File transfer using MSRP, > once the File transfer is completed, the MSRP Session associated with it > will be closed. So it should be apt to have 2 sessions for each of the > media line. > > Regds, > Sudha > > On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia > wrote: > >> Hi Amit: >> >> As you correctly mentioned, the spirit of the file transfer draft is to >> reuse existing MSRP sessions, if they are available. But we always >> signal them in different m= lines. Notice that in the example you >> provided below there is only one m= line (for file transfer), so if you >> wanted to have chat and file transfer, you should have two m=message >> lines, one is a regular MSRP (chat), the other specific for file >> transfer. >> >> So, your question... "how do we handle a case where we receive a SIP >> INVITE with a SDP offer containing both types of attributes (for text >> messaging and file transfer) in a single m-line? " seems to be not >> applicable. We will have two m=message line, each one can have its own >> direction attribute if needed. >> >> BR, >> >> Miguel >> >> >> simple-bounces@ietf.org wrote: >>> Hi Garcia, Ben and all, >>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>> should be separate msrp session (separate m-line) for the file >>> transfer. >>> But draft-ietf-simple-message-sessions-14.txt does not really >>> differentiate between normal chat session and file transfer session. >>> Also, it also does not mention the direction attribute. So User can >>> also >>> have uni directional MSRP session. If user wants to create a session >>> for chat and file transfer in the >>> single SIP INVITE. Considering the above mentioned drafts, our >>> understanding is that we will get two different m-lines in SDP offer >>> for >>> msrp sessions. In such a scenario, how do we handle a case where we >>> receive a SIP >>> INVITE with a SDP offer containing both types of attributes (for text >>> messaging and file transfer) in a single m-line? For example if we >>> receive an OFFER. >>> v=0 >>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>> s= >>> c=IN IP4 host.atlanta.example.com >>> t=0 0 >>> m=message 7654 TCP/MSRP * >>> a=sendonly >>> a=accept-types:text/plain * >>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>> a=filename:My cool picture.jpg >>> a=filetype:image/jpeg >>> a=disposition:inline >>> a=filesize:32349 >>> a=icon:cid:id2@alicepc.example.com >>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>> Regards, >>> Amit >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> > > > -- Best Regards, Sudha V.S ------=neXtPaRt_1146147587 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146147587 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=neXtPaRt_1146147587-- From simple-bounces@ietf.org Thu Apr 27 11:07:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ84u-0000sy-0O; Thu, 27 Apr 2006 11:06:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ84s-0000sq-W4; Thu, 27 Apr 2006 11:06:46 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ84r-0002Gz-Pv; Thu, 27 Apr 2006 11:06:46 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3RF6aC0005039; Thu, 27 Apr 2006 20:36:36 +0530 Date: Thu, 27 Apr 2006 20:35:49 +0530 To: "Miguel Garcia" Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146149569" MIME-Version: 1.0 Message-ID: In-Reply-To: <4450D479.8090603@nokia.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: OMA-MWG-IM@mail.openmobilealliance.org, sipping@ietf.org, simple@ietf.org, Amitkumar.Goel@infineon.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ------=neXtPaRt_1146149569 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Miguel, -Does "m=" lines have different port numbers? If so, it would result in 2 TCP Connections and hence 2 MSRP Sessions. This would naturally result in two "a=path:" attributes which would complicate the message parsing. else if the media lines have the same port numbers it is like duplication of the previous media line and it doesnt carry any meaning. -How to distinguish between which media line is for normal MSRP Chat and MSRP File Transfer. -In the previous mail you had stated that, "Each m=message represents an MSRP media stream. Both can use the same MSRP session (TCP connection + session-id in MSRP), but they are different media streams, just multiplexed over the same TCP connection and MSRP session." It is possible to mutliplex MSRP Sessions(Identified by the session Id) over the same TCP Connection. But I am not very clear with what you meant here by "MSRP media stream". Can you please give some info on how to identify the media streams in the "m=" lines. Regds, Sudha. On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia wrote: > Hi Sudha: > > Inline discussion. > > Sudha wrote: >> Hi all, >> Is it valid to have two m= lines in a single INVITE? > > Yes, of course. > >> If such is a case, Is it valid to have two MSRP sessions created for >> each of the media line? > > yes, why not? > >> As per the draft on File transfer using MSRP, once the File transfer is >> completed, the MSRP Session associated with it will be closed. So it >> should be apt to have 2 sessions for each of the media line. > > I am not sure what you mean with "2 sessions fr each of the media line". > Each m=message represents an MSRP media stream. Both can use the same > MSRP session (TCP connection + session-id in MSRP), but they are > different media streams, just multiplexed over the same TCP connection > and MSRP session. > > BR, > > Miguel > > >> Regds, >> Sudha >> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia >> wrote: >> >>> Hi Amit: >>> >>> As you correctly mentioned, the spirit of the file transfer draft is >>> to reuse existing MSRP sessions, if they are available. But we always >>> signal them in different m= lines. Notice that in the example you >>> provided below there is only one m= line (for file transfer), so if >>> you wanted to have chat and file transfer, you should have two >>> m=message lines, one is a regular MSRP (chat), the other specific for >>> file transfer. >>> >>> So, your question... "how do we handle a case where we receive a SIP >>> INVITE with a SDP offer containing both types of attributes (for text >>> messaging and file transfer) in a single m-line? " seems to be not >>> applicable. We will have two m=message line, each one can have its own >>> direction attribute if needed. >>> >>> BR, >>> >>> Miguel >>> >>> >>> simple-bounces@ietf.org wrote: >>>> Hi Garcia, Ben and all, >>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>>> should be separate msrp session (separate m-line) for the file >>>> transfer. >>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>> differentiate between normal chat session and file transfer session. >>>> Also, it also does not mention the direction attribute. So User can >>>> also >>>> have uni directional MSRP session. If user wants to create a session >>>> for chat and file transfer in the >>>> single SIP INVITE. Considering the above mentioned drafts, our >>>> understanding is that we will get two different m-lines in SDP offer >>>> for >>>> msrp sessions. In such a scenario, how do we handle a case where we >>>> receive a SIP >>>> INVITE with a SDP offer containing both types of attributes (for text >>>> messaging and file transfer) in a single m-line? For example if we >>>> receive an OFFER. >>>> v=0 >>>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>>> s= >>>> c=IN IP4 host.atlanta.example.com >>>> t=0 0 >>>> m=message 7654 TCP/MSRP * >>>> a=sendonly >>>> a=accept-types:text/plain * >>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>> a=filename:My cool picture.jpg >>>> a=filetype:image/jpeg >>>> a=disposition:inline >>>> a=filesize:32349 >>>> a=icon:cid:id2@alicepc.example.com >>>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>> Regards, >>>> Amit >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/simple >>>> >>> >> --Best Regards, >> Sudha V.S > -- Best Regards, Sudha V.S ------=neXtPaRt_1146149569 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146149569 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=neXtPaRt_1146149569-- From simple-bounces@ietf.org Fri Apr 28 02:28:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZMSV-0003WH-D5; Fri, 28 Apr 2006 02:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZMS9-0002zG-H4; Fri, 28 Apr 2006 02:27:45 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZMHk-0001eR-N7; Fri, 28 Apr 2006 02:17:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3S6GprI016758; Fri, 28 Apr 2006 09:16:57 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:16:53 +0300 Received: from [127.0.0.1] ([172.21.34.203]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 28 Apr 2006 09:16:53 +0300 Message-ID: <4451B34A.30200@nokia.com> Date: Fri, 28 Apr 2006 09:16:42 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Sudha Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 06:16:53.0055 (UTC) FILETIME=[57AC5CF0:01C66A8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: OMA-MWG-IM@mail.openmobilealliance.org, sipping@ietf.org, simple@ietf.org, Amitkumar.Goel@infineon.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Inline discussion. Sudha wrote: > Hi Miguel, > -Does "m=" lines have different port numbers? > If so, it would result in 2 TCP Connections and hence 2 MSRP > Sessions. This would naturally result in two "a=path:" attributes which > would complicate the message parsing. > else if the media lines have the same port numbers it is like > duplication of the previous media line and it doesnt carry any meaning. Different m= lines will have the same port number, because they will be sharing the same TCP connection. There is nothing new here, the MSRP draft already discusses the TCP sharing in Sections 5.1 and 8.1. What we say in our draft is that each file transfer is identified with a different MSRP session. We can discuss if we need to share the same session, but at the moment the draft says each m= line has a unique MSRP sessionId. Still the port number used for the TCP connection is the same. > > -How to distinguish between which media line is for normal MSRP Chat and > MSRP File Transfer. MSRP for File Transfer will have a file selector in the SDP. The file selector is described in Section 6.1 of the File Transfer draft. > > -In the previous mail you had stated that, > "Each m=message represents an MSRP media stream. Both can use the same > MSRP session (TCP connection + session-id in MSRP), but they are > different media streams, just multiplexed over the same TCP connection > and MSRP session." > Note that sharing the same MSRP session is not correct, at least, according to what we have in the draft now, my apologies. > It is possible to mutliplex MSRP Sessions(Identified by the session Id) > over the same TCP Connection. But I am not very clear with what you > meant here by "MSRP media stream". Can you please give some info on how > to identify the media streams in the "m=" lines. That is probably the main point, we need a unique identifier, and that is the session Id in MSRP. That is the reason why the session ID has to be different. BR, Miguel > > Regds, > Sudha. > > > On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia > wrote: > >> Hi Sudha: >> >> Inline discussion. >> >> Sudha wrote: >>> Hi all, >>> Is it valid to have two m= lines in a single INVITE? >> >> Yes, of course. >> >>> If such is a case, Is it valid to have two MSRP sessions created for >>> each of the media line? >> >> yes, why not? >> >>> As per the draft on File transfer using MSRP, once the File transfer >>> is completed, the MSRP Session associated with it will be closed. So >>> it should be apt to have 2 sessions for each of the media line. >> >> I am not sure what you mean with "2 sessions fr each of the media >> line". Each m=message represents an MSRP media stream. Both can use >> the same MSRP session (TCP connection + session-id in MSRP), but they >> are different media streams, just multiplexed over the same TCP >> connection and MSRP session. >> >> BR, >> >> Miguel >> >> >>> Regds, >>> Sudha >>> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia >>> wrote: >>> >>>> Hi Amit: >>>> >>>> As you correctly mentioned, the spirit of the file transfer draft is >>>> to reuse existing MSRP sessions, if they are available. But we >>>> always signal them in different m= lines. Notice that in the example >>>> you provided below there is only one m= line (for file transfer), so >>>> if you wanted to have chat and file transfer, you should have two >>>> m=message lines, one is a regular MSRP (chat), the other specific >>>> for file transfer. >>>> >>>> So, your question... "how do we handle a case where we receive a SIP >>>> INVITE with a SDP offer containing both types of attributes (for >>>> text messaging and file transfer) in a single m-line? " seems to be >>>> not applicable. We will have two m=message line, each one can have >>>> its own direction attribute if needed. >>>> >>>> BR, >>>> >>>> Miguel >>>> >>>> >>>> simple-bounces@ietf.org wrote: >>>>> Hi Garcia, Ben and all, >>>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>>>> should be separate msrp session (separate m-line) for the file >>>>> transfer. >>>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>>> differentiate between normal chat session and file transfer session. >>>>> Also, it also does not mention the direction attribute. So User can >>>>> also >>>>> have uni directional MSRP session. If user wants to create a >>>>> session for chat and file transfer in the >>>>> single SIP INVITE. Considering the above mentioned drafts, our >>>>> understanding is that we will get two different m-lines in SDP >>>>> offer for >>>>> msrp sessions. In such a scenario, how do we handle a case where >>>>> we receive a SIP >>>>> INVITE with a SDP offer containing both types of attributes (for text >>>>> messaging and file transfer) in a single m-line? For example if we >>>>> receive an OFFER. >>>>> v=0 >>>>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>>>> s= >>>>> c=IN IP4 host.atlanta.example.com >>>>> t=0 0 >>>>> m=message 7654 TCP/MSRP * >>>>> a=sendonly >>>>> a=accept-types:text/plain * >>>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>>> a=filename:My cool picture.jpg >>>>> a=filetype:image/jpeg >>>>> a=disposition:inline >>>>> a=filesize:32349 >>>>> a=icon:cid:id2@alicepc.example.com >>>>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>>> Regards, >>>>> Amit >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>> >>> --Best Regards, >>> Sudha V.S >> > > > > --Best Regards, > Sudha V.S -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 28 03:33:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNTF-00039C-BZ; Fri, 28 Apr 2006 03:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNTD-000392-00; Fri, 28 Apr 2006 03:32:55 -0400 Received: from gesmail.globaledgesoft.com ([203.76.137.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNT8-0006v3-GV; Fri, 28 Apr 2006 03:32:54 -0400 Received: from localhost.localdomain ([172.16.4.194]) by gesmail.globaledgesoft.com (8.13.1/8.13.1) with ESMTP id k3S7WfJa002448; Fri, 28 Apr 2006 13:02:41 +0530 Date: Fri, 28 Apr 2006 13:01:54 +0530 To: "Miguel Garcia" Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: <4450CC00.7010904@nokia.com> <4450D479.8090603@nokia.com> <4451B34A.30200@nokia.com> From: Sudha Organization: GESL Content-Type: multipart/mixed; boundary="----=neXtPaRt_1146208727" MIME-Version: 1.0 Message-ID: In-Reply-To: <4451B34A.30200@nokia.com> User-Agent: Opera M2/8.01 (Linux, build 1204) X-Spam-Status: No, score=-1.4 required=2.5 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on gesmail.globaledgesoft.com X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: OMA-MWG-IM@mail.openmobilealliance.org, sipping@ietf.org, simple@ietf.org, Amitkumar.Goel@infineon.com X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org ------=neXtPaRt_1146208727 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks Miguel. Inline discussion On Fri, 28 Apr 2006 11:46:42 +0530, Miguel Garcia wrote: > Inline discussion. > > Sudha wrote: >> Hi Miguel, >> -Does "m=" lines have different port numbers? >> If so, it would result in 2 TCP Connections and hence 2 MSRP >> Sessions. This would naturally result in two "a=path:" attributes which >> would complicate the message parsing. >> else if the media lines have the same port numbers it is like >> duplication of the previous media line and it doesnt carry any meaning. > > Different m= lines will have the same port number, because they will be > sharing the same TCP connection. There is nothing new here, the MSRP > draft already discusses the TCP sharing in Sections 5.1 and 8.1. > > What we say in our draft is that each file transfer is identified with a > different MSRP session. We can discuss if we need to share the same > session, but at the moment the draft says each m= line has a unique MSRP > sessionId. Still the port number used for the TCP connection is the same. With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt the format of the m= line is: m= The format list field MUST be set to "*". The media doesn't accomadate for the MSRP sessionId. The SessionId is specified in the url of the "a=path" attribute. Can the session Id be specified in the format list? >> -How to distinguish between which media line is for normal MSRP Chat >> and MSRP File Transfer. > > MSRP for File Transfer will have a file selector in the SDP. The file > selector is described in Section 6.1 of the File Transfer draft. > >> -In the previous mail you had stated that, >> "Each m=message represents an MSRP media stream. Both can use the same >> MSRP session (TCP connection + session-id in MSRP), but they are >> different media streams, just multiplexed over the same TCP connection >> and MSRP session." >> > > Note that sharing the same MSRP session is not correct, at least, > according to what we have in the draft now, my apologies. > >> It is possible to mutliplex MSRP Sessions(Identified by the session Id) >> over the same TCP Connection. But I am not very clear with what you >> meant here by "MSRP media stream". Can you please give some info on how >> to identify the media streams in the "m=" lines. > > That is probably the main point, we need a unique identifier, and that > is the session Id in MSRP. That is the reason why the session ID has to > be different. > > > BR, > > Miguel > >> Regds, >> Sudha. >> On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia >> wrote: >> >>> Hi Sudha: >>> >>> Inline discussion. >>> >>> Sudha wrote: >>>> Hi all, >>>> Is it valid to have two m= lines in a single INVITE? >>> >>> Yes, of course. >>> >>>> If such is a case, Is it valid to have two MSRP sessions created for >>>> each of the media line? >>> >>> yes, why not? >>> >>>> As per the draft on File transfer using MSRP, once the File transfer >>>> is completed, the MSRP Session associated with it will be closed. So >>>> it should be apt to have 2 sessions for each of the media line. >>> >>> I am not sure what you mean with "2 sessions fr each of the media >>> line". Each m=message represents an MSRP media stream. Both can use >>> the same MSRP session (TCP connection + session-id in MSRP), but they >>> are different media streams, just multiplexed over the same TCP >>> connection and MSRP session. >>> >>> BR, >>> >>> Miguel >>> >>> >>>> Regds, >>>> Sudha >>>> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia >>>> wrote: >>>> >>>>> Hi Amit: >>>>> >>>>> As you correctly mentioned, the spirit of the file transfer draft is >>>>> to reuse existing MSRP sessions, if they are available. But we >>>>> always signal them in different m= lines. Notice that in the example >>>>> you provided below there is only one m= line (for file transfer), so >>>>> if you wanted to have chat and file transfer, you should have two >>>>> m=message lines, one is a regular MSRP (chat), the other specific >>>>> for file transfer. >>>>> >>>>> So, your question... "how do we handle a case where we receive a SIP >>>>> INVITE with a SDP offer containing both types of attributes (for >>>>> text messaging and file transfer) in a single m-line? " seems to be >>>>> not applicable. We will have two m=message line, each one can have >>>>> its own direction attribute if needed. >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> simple-bounces@ietf.org wrote: >>>>>> Hi Garcia, Ben and all, >>>>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>>>>> should be separate msrp session (separate m-line) for the file >>>>>> transfer. >>>>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>>>> differentiate between normal chat session and file transfer session. >>>>>> Also, it also does not mention the direction attribute. So User can >>>>>> also >>>>>> have uni directional MSRP session. If user wants to create a >>>>>> session for chat and file transfer in the >>>>>> single SIP INVITE. Considering the above mentioned drafts, our >>>>>> understanding is that we will get two different m-lines in SDP >>>>>> offer for >>>>>> msrp sessions. In such a scenario, how do we handle a case where >>>>>> we receive a SIP >>>>>> INVITE with a SDP offer containing both types of attributes (for >>>>>> text >>>>>> messaging and file transfer) in a single m-line? For example if we >>>>>> receive an OFFER. >>>>>> v=0 >>>>>> o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>>>>> s= >>>>>> c=IN IP4 host.atlanta.example.com >>>>>> t=0 0 >>>>>> m=message 7654 TCP/MSRP * >>>>>> a=sendonly >>>>>> a=accept-types:text/plain * >>>>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>>>> a=filename:My cool picture.jpg >>>>>> a=filetype:image/jpeg >>>>>> a=disposition:inline >>>>>> a=filesize:32349 >>>>>> a=icon:cid:id2@alicepc.example.com >>>>>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>>>> Regards, >>>>>> Amit >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>> --Best Regards, >>>> Sudha V.S >>> >> --Best Regards, >> Sudha V.S > -- Best Regards, Sudha V.S ------=neXtPaRt_1146208727 Content-Type: text/plain; This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address ------=neXtPaRt_1146208727 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------=neXtPaRt_1146208727-- From simple-bounces@ietf.org Fri Apr 28 03:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNmu-0007PW-Rx; Fri, 28 Apr 2006 03:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNms-0007PH-Tp; Fri, 28 Apr 2006 03:53:14 -0400 Received: from smtp3.infineon.com ([203.126.106.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNmo-00080G-Mg; Fri, 28 Apr 2006 03:53:14 -0400 Received: from unknown (HELO sinse212.ap.infineon.com) ([172.17.65.148]) by smtp3.infineon.com with ESMTP; 28 Apr 2006 15:53:08 +0800 X-SBRS: None Received: from blrse201.ap.infineon.com ([172.20.20.12]) by sinse212.ap.infineon.com over TLS secured channel with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 Apr 2006 15:53:07 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Handling of incoming INVITE request for different MSRP session Date: Fri, 28 Apr 2006 13:23:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Handling of incoming INVITE request for different MSRP session thread-index: AcZqlzYR+8n4MqmnTQ+TpLyLgRD3aAAANGMg From: To: , X-OriginalArrivalTime: 28 Apr 2006 07:53:07.0822 (UTC) FILETIME=[C9B3E0E0:01C66A98] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: sipping@ietf.org, simple@ietf.org, OMA-MWG-IM@mail.openmobilealliance.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi Miguel, If SDP offer/answer m-line ulr does not contain session id,as session ID is a optional param, Is it mean that the offerer/answerer does not support MSRP session multiplexing for sharing the same TCP connection?=20 Regards, Amit=20 =20 -----Original Message----- From: Sudha [mailto:sudha.vs@globaledgesoft.com]=20 Sent: Friday, April 28, 2006 1:02 PM To: Miguel Garcia Cc: Goel Amitkumar (IFIN SW WS); sipping@ietf.org; simple@ietf.org; OMA-MWG-IM@mail.openmobilealliance.org Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session Thanks Miguel. Inline discussion On Fri, 28 Apr 2006 11:46:42 +0530, Miguel Garcia wrote: > Inline discussion. > > Sudha wrote: >> Hi Miguel, >> -Does "m=3D" lines have different port numbers? >> If so, it would result in 2 TCP Connections and hence 2 MSRP=20 >> Sessions. This would naturally result in two "a=3Dpath:" attributes=20 >> which would complicate the message parsing. >> else if the media lines have the same port numbers it is like=20 >> duplication of the previous media line and it doesnt carry any meaning. > > Different m=3D lines will have the same port number, because they will = > be sharing the same TCP connection. There is nothing new here, the=20 > MSRP draft already discusses the TCP sharing in Sections 5.1 and 8.1. > > What we say in our draft is that each file transfer is identified with > a different MSRP session. We can discuss if we need to share the same=20 > session, but at the moment the draft says each m=3D line has a unique=20 > MSRP sessionId. Still the port number used for the TCP connection is the same. With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt the format of the m=3D line is: m=3D The format list field MUST = be set to "*". The media doesn't accomadate for the MSRP sessionId. The SessionId is specified in the url of the "a=3Dpath" attribute. Can = the session Id be specified in the format list? >> -How to distinguish between which media line is for normal MSRP Chat >> and MSRP File Transfer. > > MSRP for File Transfer will have a file selector in the SDP. The file=20 > selector is described in Section 6.1 of the File Transfer draft. > >> -In the previous mail you had stated that, "Each m=3Dmessage=20 >> represents an MSRP media stream. Both can use the same MSRP session=20 >> (TCP connection + session-id in MSRP), but they are different media=20 >> streams, just multiplexed over the same TCP connection and MSRP=20 >> session." >> > > Note that sharing the same MSRP session is not correct, at least, =20 > according to what we have in the draft now, my apologies. > >> It is possible to mutliplex MSRP Sessions(Identified by the session Id) =20 >> over the same TCP Connection. But I am not very clear with what you =20 >> meant here by "MSRP media stream". Can you please give some info on how =20 >> to identify the media streams in the "m=3D" lines. > > That is probably the main point, we need a unique identifier, and that > is the session Id in MSRP. That is the reason why the session ID has to =20 > be different. > > > BR, > > Miguel > >> Regds, >> Sudha. >> On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia =20 >> wrote: >> >>> Hi Sudha: >>> >>> Inline discussion. >>> >>> Sudha wrote: >>>> Hi all, >>>> Is it valid to have two m=3D lines in a single INVITE? >>> >>> Yes, of course. >>> >>>> If such is a case, Is it valid to have two MSRP sessions created for =20 >>>> each of the media line? >>> >>> yes, why not? >>> >>>> As per the draft on File transfer using MSRP, once the File transfer =20 >>>> is completed, the MSRP Session associated with it will be closed. So =20 >>>> it should be apt to have 2 sessions for each of the media line. >>> >>> I am not sure what you mean with "2 sessions fr each of the media =20 >>> line". Each m=3Dmessage represents an MSRP media stream. Both can = use >>> the same MSRP session (TCP connection + session-id in MSRP), but they =20 >>> are different media streams, just multiplexed over the same TCP =20 >>> connection and MSRP session. >>> >>> BR, >>> >>> Miguel >>> >>> >>>> Regds, >>>> Sudha >>>> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia =20 >>>> wrote: >>>> >>>>> Hi Amit: >>>>> >>>>> As you correctly mentioned, the spirit of the file transfer draft is =20 >>>>> to reuse existing MSRP sessions, if they are available. But we =20 >>>>> always signal them in different m=3D lines. Notice that in the example =20 >>>>> you provided below there is only one m=3D line (for file = transfer), so =20 >>>>> if you wanted to have chat and file transfer, you should have two >>>>> m=3Dmessage lines, one is a regular MSRP (chat), the other = specific >>>>> for file transfer. >>>>> >>>>> So, your question... "how do we handle a case where we receive a SIP >>>>> INVITE with a SDP offer containing both types of attributes (for =20 >>>>> text messaging and file transfer) in a single m-line? " seems to be =20 >>>>> not applicable. We will have two m=3Dmessage line, each one can = have >>>>> its own direction attribute if needed. >>>>> >>>>> BR, >>>>> >>>>> Miguel >>>>> >>>>> >>>>> simple-bounces@ietf.org wrote: >>>>>> Hi Garcia, Ben and all, >>>>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that there >>>>>> should be separate msrp session (separate m-line) for the file =20 >>>>>> transfer. >>>>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>>>> differentiate between normal chat session and file transfer session. >>>>>> Also, it also does not mention the direction attribute. So User can =20 >>>>>> also >>>>>> have uni directional MSRP session. If user wants to create a =20 >>>>>> session for chat and file transfer in the >>>>>> single SIP INVITE. Considering the above mentioned drafts, our >>>>>> understanding is that we will get two different m-lines in SDP =20 >>>>>> offer for >>>>>> msrp sessions. In such a scenario, how do we handle a case where >>>>>> we receive a SIP >>>>>> INVITE with a SDP offer containing both types of attributes (for >>>>>> text >>>>>> messaging and file transfer) in a single m-line? For example if we >>>>>> receive an OFFER. >>>>>> v=3D0 >>>>>> o=3Dalice 2890844526 2890844526 IN IP4 host.atlanta.example.com >>>>>> s=3D >>>>>> c=3DIN IP4 host.atlanta.example.com >>>>>> t=3D0 0 >>>>>> m=3Dmessage 7654 TCP/MSRP * >>>>>> a=3Dsendonly >>>>>> a=3Daccept-types:text/plain * >>>>>> a=3Dpath:msrp://atlanta.example.com:7654/jshA7we;tcp >>>>>> a=3Dfilename:My cool picture.jpg >>>>>> a=3Dfiletype:image/jpeg >>>>>> a=3Ddisposition:inline >>>>>> a=3Dfilesize:32349 >>>>>> a=3Dicon:cid:id2@alicepc.example.com >>>>>> a=3Dhash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>>>> Regards, >>>>>> Amit >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>> >>>> --Best Regards, >>>> Sudha V.S >>> >> --Best Regards, >> Sudha V.S > --=20 Best Regards, Sudha V.S _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 28 03:59:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNsZ-0001n3-Aw; Fri, 28 Apr 2006 03:59:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZNsX-0001ls-G0; Fri, 28 Apr 2006 03:59:05 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZNsV-000879-Jb; Fri, 28 Apr 2006 03:59:05 -0400 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E333F4F003F; Fri, 28 Apr 2006 09:59:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:59:02 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Apr 2006 09:59:02 +0200 Received: from [131.160.126.3] (rvi2-126-3.lmf.ericsson.se [131.160.126.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 07B4F236E; Fri, 28 Apr 2006 10:59:01 +0300 (EEST) Message-ID: <4451CB44.7050602@ericsson.com> Date: Fri, 28 Apr 2006 10:59:00 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Amitkumar.Goel@infineon.com Subject: Re: [Simple] Handling of incoming INVITE request for different MSRP session References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2006 07:59:02.0620 (UTC) FILETIME=[9D2DC1C0:01C66A99] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: mmusic , OMA-MWG-IM@mail.openmobilealliance.org, Miguel.An.Garcia@nokia.com, simple@ietf.org, sipping@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, note that the policy we currently use is not to cross-post to the SIP, SIPPING, and SIMPLE mailing lists. A particular discussion should take place in one and only one of those lists. In any case, in the last IETF it was decided that this draft will be discussed in MMUSIC. I have cc:ed the MMUSIC mailing list in this message. Please, remove the SIPPING and SIMPLE mailing lists in your replies from now on. Thanks, Gonzalo SIPPING co-chair Amitkumar.Goel@infineon.com wrote: > Hi Miguel, > > If SDP offer/answer m-line ulr does not contain session id,as session ID > is a optional param, Is it mean that the offerer/answerer does not > support MSRP session multiplexing for sharing the same TCP connection? > > Regards, > Amit > > > > -----Original Message----- > From: Sudha [mailto:sudha.vs@globaledgesoft.com] > Sent: Friday, April 28, 2006 1:02 PM > To: Miguel Garcia > Cc: Goel Amitkumar (IFIN SW WS); sipping@ietf.org; simple@ietf.org; > OMA-MWG-IM@mail.openmobilealliance.org > Subject: Re: [Simple] Handling of incoming INVITE request for different > MSRP session > > Thanks Miguel. > Inline discussion > > > On Fri, 28 Apr 2006 11:46:42 +0530, Miguel Garcia > wrote: > >> Inline discussion. >> >> Sudha wrote: >>> Hi Miguel, >>> -Does "m=" lines have different port numbers? >>> If so, it would result in 2 TCP Connections and hence 2 MSRP >>> Sessions. This would naturally result in two "a=path:" attributes >>> which would complicate the message parsing. >>> else if the media lines have the same port numbers it is like >>> duplication of the previous media line and it doesnt carry any > meaning. >> Different m= lines will have the same port number, because they will >> be sharing the same TCP connection. There is nothing new here, the >> MSRP draft already discusses the TCP sharing in Sections 5.1 and 8.1. >> >> What we say in our draft is that each file transfer is identified with > >> a different MSRP session. We can discuss if we need to share the same >> session, but at the moment the draft says each m= line has a unique >> MSRP sessionId. Still the port number used for the TCP connection is > the same. > > With reference to sec. 8.1 of draft-ietf-simple-message-sessions-14.txt > the format of the m= line is: > m= The format list field MUST be > set to "*". > The media doesn't accomadate for the MSRP sessionId. > The SessionId is specified in the url of the "a=path" attribute. Can the > session Id be specified in the format list? > >>> -How to distinguish between which media line is for normal MSRP Chat > >>> and MSRP File Transfer. >> MSRP for File Transfer will have a file selector in the SDP. The file >> selector is described in Section 6.1 of the File Transfer draft. >> >>> -In the previous mail you had stated that, "Each m=message >>> represents an MSRP media stream. Both can use the same MSRP session >>> (TCP connection + session-id in MSRP), but they are different media >>> streams, just multiplexed over the same TCP connection and MSRP >>> session." >>> >> Note that sharing the same MSRP session is not correct, at least, >> according to what we have in the draft now, my apologies. >> >>> It is possible to mutliplex MSRP Sessions(Identified by the session > Id) >>> over the same TCP Connection. But I am not very clear with what you >>> meant here by "MSRP media stream". Can you please give some info on > how >>> to identify the media streams in the "m=" lines. >> That is probably the main point, we need a unique identifier, and that > >> is the session Id in MSRP. That is the reason why the session ID has > to >> be different. >> >> >> BR, >> >> Miguel >> >>> Regds, >>> Sudha. >>> On Thu, 27 Apr 2006 19:56:01 +0530, Miguel Garcia >>> wrote: >>> >>>> Hi Sudha: >>>> >>>> Inline discussion. >>>> >>>> Sudha wrote: >>>>> Hi all, >>>>> Is it valid to have two m= lines in a single INVITE? >>>> Yes, of course. >>>> >>>>> If such is a case, Is it valid to have two MSRP sessions created > for >>>>> each of the media line? >>>> yes, why not? >>>> >>>>> As per the draft on File transfer using MSRP, once the File > transfer >>>>> is completed, the MSRP Session associated with it will be closed. > So >>>>> it should be apt to have 2 sessions for each of the media line. >>>> I am not sure what you mean with "2 sessions fr each of the media >>>> line". Each m=message represents an MSRP media stream. Both can use > >>>> the same MSRP session (TCP connection + session-id in MSRP), but > they >>>> are different media streams, just multiplexed over the same TCP >>>> connection and MSRP session. >>>> >>>> BR, >>>> >>>> Miguel >>>> >>>> >>>>> Regds, >>>>> Sudha >>>>> On Thu, 27 Apr 2006 19:19:52 +0530, Miguel Garcia >>>>> wrote: >>>>> >>>>>> Hi Amit: >>>>>> >>>>>> As you correctly mentioned, the spirit of the file transfer draft > is >>>>>> to reuse existing MSRP sessions, if they are available. But we >>>>>> always signal them in different m= lines. Notice that in the > example >>>>>> you provided below there is only one m= line (for file transfer), > so >>>>>> if you wanted to have chat and file transfer, you should have two > >>>>>> m=message lines, one is a regular MSRP (chat), the other specific > >>>>>> for file transfer. >>>>>> >>>>>> So, your question... "how do we handle a case where we receive a > SIP >>>>>> INVITE with a SDP offer containing both types of attributes (for >>>>>> text messaging and file transfer) in a single m-line? " seems to > be >>>>>> not applicable. We will have two m=message line, each one can have > >>>>>> its own direction attribute if needed. >>>>>> >>>>>> BR, >>>>>> >>>>>> Miguel >>>>>> >>>>>> >>>>>> simple-bounces@ietf.org wrote: >>>>>>> Hi Garcia, Ben and all, >>>>>>> draft-garcia-sipping-file-transfer-mech-00.txt mandates that > there >>>>>>> should be separate msrp session (separate m-line) for the file >>>>>>> transfer. >>>>>>> But draft-ietf-simple-message-sessions-14.txt does not really >>>>>>> differentiate between normal chat session and file transfer > session. >>>>>>> Also, it also does not mention the direction attribute. So User > can >>>>>>> also >>>>>>> have uni directional MSRP session. If user wants to create a >>>>>>> session for chat and file transfer in the >>>>>>> single SIP INVITE. Considering the above mentioned drafts, our >>>>>>> understanding is that we will get two different m-lines in SDP >>>>>>> offer for >>>>>>> msrp sessions. In such a scenario, how do we handle a case where > >>>>>>> we receive a SIP >>>>>>> INVITE with a SDP offer containing both types of attributes (for > >>>>>>> text >>>>>>> messaging and file transfer) in a single m-line? For example if > we >>>>>>> receive an OFFER. >>>>>>> v=0 >>>>>>> o=alice 2890844526 2890844526 IN IP4 > host.atlanta.example.com >>>>>>> s= >>>>>>> c=IN IP4 host.atlanta.example.com >>>>>>> t=0 0 >>>>>>> m=message 7654 TCP/MSRP * >>>>>>> a=sendonly >>>>>>> a=accept-types:text/plain * >>>>>>> a=path:msrp://atlanta.example.com:7654/jshA7we;tcp >>>>>>> a=filename:My cool picture.jpg >>>>>>> a=filetype:image/jpeg >>>>>>> a=disposition:inline >>>>>>> a=filesize:32349 >>>>>>> a=icon:cid:id2@alicepc.example.com >>>>>>> a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e >>>>>>> Regards, >>>>>>> Amit >>>>>>> _______________________________________________ >>>>>>> Simple mailing list >>>>>>> Simple@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/simple >>>>>>> >>>>> --Best Regards, >>>>> Sudha V.S >>> --Best Regards, >>> Sudha V.S > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 28 04:54:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOju-0005sm-5u; Fri, 28 Apr 2006 04:54:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZOjt-0005sD-1R for simple@ietf.org; Fri, 28 Apr 2006 04:54:13 -0400 Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZOjr-00032o-Jj for simple@ietf.org; Fri, 28 Apr 2006 04:54:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 28 Apr 2006 10:54:08 +0200 Message-ID: <3ACC9A25264A684F82C71840111F979801740E6F@carrera.eu.tieto.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: publishing presence state - sip and pres uris Thread-Index: AcZqoU9kxA68+oMESUODpLQx/pk/Ng== From: To: X-OriginalArrivalTime: 28 Apr 2006 08:54:10.0377 (UTC) FILETIME=[50C16B90:01C66AA1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Simple] publishing presence state - sip and pres uris X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hello,=20 I am not sure how presence server should handle PUBLISH requests, if = they have sip uri in To: header and pres uri in entity attribute in the = presence document: PUBLISH ... To: sip:alan@example.com ... ... It seems that client should not create such requests (why use pres uri, = if it knows sip uri?) but I think that it can happen thanks to RFC3863 = (pidf) which mentions only pres uri to be inserted to the entity = parameter. Could someone explain what is the correct behavior here? Is it possible = to have different uri's in To header and in the entity attribute? Thank you,=20 Silvestr Peknik Software Specialist TietoEnator Czech Software Center Phone=A0+420 599 096 027 Fax +420 599 096 110 E-mail silvestr.peknik@tietoenator.com=A0=A0 =A0 Vystavni 292/13 CZ-709=A016 Ostrava =A0 www.tietoenator.com =09 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 28 10:24:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZTtI-0000eo-Eq; Fri, 28 Apr 2006 10:24:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZTtG-0000eg-KS for simple@ietf.org; Fri, 28 Apr 2006 10:24:14 -0400 Received: from pproxy.gmail.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZTtF-0005EG-EU for simple@ietf.org; Fri, 28 Apr 2006 10:24:14 -0400 Received: by pproxy.gmail.com with SMTP id t32so2226302pyc for ; Fri, 28 Apr 2006 07:24:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Qj4zOAoLJYYVv4CpbvDOdLPW6EKZOJo78liysO6FMGQwdrDbzE5gCwNwGSjpkfxVm4SE8Ql8EUTV9W9LUEBYIWKDOke9ZQeyvvo0d7GaDhSwBP/WWZwK09aM655MigwO33HrFeUK/g9uQa6F8kJ6zAF0cUtd/ct6N48dDb/PMpQ= Received: by 10.35.18.4 with SMTP id v4mr1004838pyi; Fri, 28 Apr 2006 07:24:13 -0700 (PDT) Received: by 10.35.89.19 with HTTP; Fri, 28 Apr 2006 07:24:13 -0700 (PDT) Message-ID: <9d77d7060604280724j8ba0b60w42b18e30f9529c89@mail.gmail.com> Date: Fri, 28 Apr 2006 22:24:13 +0800 From: "Xiang Ting" To: simple@ietf.org Subject: [Simple]Can Message/CPIM be without MIME message-body MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 1.9 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Graham Klyne , Derek Atkins , Derek Atkins X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org RFC 3862 describes CPIM message format as following: [snip1] A complete message looks something like this: m: Content-type: Message/CPIM s: h: (message-metadata-headers) s: e: (encapsulated MIME message-body) [/snip1] [snip2] 2.4. Message Content The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2]. The MIME content headers MUST include at least a Content-Type header. The content may be any MIME type. [/snip2] In practice, I encountered a CPIM message without body. My parser judged it as an invalid message format, but the opposers said that there aren't specifications pointing out that CPIM MUST have a body. I want to know whether the standard CPIM must have a encapsulated MIME message body? Thanks in advance. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple