From simple-admin@ietf.org Mon Dec 1 08:54:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10342; Mon, 1 Dec 2003 08:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoVE-0001ur-00; Mon, 01 Dec 2003 08:54:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQoVD-0001um-00; Mon, 01 Dec 2003 08:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoUz-0007yE-Sr; Mon, 01 Dec 2003 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoUL-0007xg-OK for simple@optimus.ietf.org; Mon, 01 Dec 2003 08:53:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10318 for ; Mon, 1 Dec 2003 08:53:05 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoUK-0001uF-00 for simple@ietf.org; Mon, 01 Dec 2003 08:53:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AQoUJ-0001uC-00 for simple@ietf.org; Mon, 01 Dec 2003 08:53:19 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1DrHR19135 for ; Mon, 1 Dec 2003 15:53:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Dec 2003 15:53:17 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 15:53:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 15:53:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B812.777CB555" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> Thread-Topic: Couple of issues about partial notification draft Thread-Index: AcO4Enbu6ssGjqIjRAe7kj9aSxdRjA== To: X-OriginalArrivalTime: 01 Dec 2003 13:53:16.0243 (UTC) FILETIME=[78390230:01C3B812] Subject: [Simple] Couple of issues about partial notification draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 15:53:15 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B812.777CB555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am currently writing an update to draft-ietf-simple-partial-notify-00 and there seems to be couple of issues which probably need some discussion. -Security Considerations section: 01 version currently has following security considerations section "Presence information may contain highly sensitive information about the presentities. The protocol used to distribute it SHOULD ensure privacy, message integrity and authentication. Furthermore, the protocol should provide access controls which restrict who can see who else's presence information. Presence related security considerations are extensively discussed in [draft-ietf-simple-presence-10] and all those identified security consideration apply to this document as well. Partial notification mechanism does not add any new considerations=20 and relies on the mechanisms specified in [draft-ietf-simple-presence-10] and [RFC3261]" Do people on the list think this is sufficient or is there a need to have more text about security in this draft?=20 - IMPP interoperability Partial notification mechanism is not compatible with IMPP work. I think it might be good to have own chapter about this in the draft. Basically I think it should say that mechanism does not by default work with other IMPP compliant systems but this should not be an issue as partial notifications will not be used if requesting end does not understand it. =20 - Mikko ------_=_NextPart_001_01C3B812.777CB555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Couple of issues about partial notification draft

Hi,

I am currently = writing an update to draft-ietf-simple-partial-notify-00 and there seems = to be couple of issues which probably need some = discussion.

-Security = Considerations section:
01 version currently = has following security considerations section

"Presence = information may contain highly sensitive information about
   the = presentities. The protocol used to distribute it SHOULD = ensure
   = privacy, message integrity and authentication. Furthermore, = the
   = protocol should provide access controls which restrict who can = see
   who = else's presence information. Presence related security
   = considerations are extensively discussed in = [draft-ietf-simple-presence-10] and all those
   = identified security consideration apply to this document as = well.
   Partial notification mechanism does not = add  any new considerations
   and = relies on the mechanisms specified in [draft-ietf-simple-presence-10] = and [RFC3261]"

Do people on the list = think this is sufficient or is there a need to have more text about = security in this draft?

- IMPP = interoperability
Partial notification = mechanism is not compatible with IMPP work. I think it might be good to = have own chapter about this in the draft. Basically I think it should = say that mechanism does not by default work with other IMPP compliant = systems but this should not be an issue as partial notifications will = not be used if requesting end does not understand it.

    =
- = Mikko

------_=_NextPart_001_01C3B812.777CB555-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 08:54:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10411 for ; Mon, 1 Dec 2003 08:54:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoVG-00086b-3D for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 08:54:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1DsIUC031151 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 08:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoVF-00086M-Rf for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 08:54:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10342; Mon, 1 Dec 2003 08:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoVE-0001ur-00; Mon, 01 Dec 2003 08:54:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQoVD-0001um-00; Mon, 01 Dec 2003 08:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoUz-0007yE-Sr; Mon, 01 Dec 2003 08:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQoUL-0007xg-OK for simple@optimus.ietf.org; Mon, 01 Dec 2003 08:53:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10318 for ; Mon, 1 Dec 2003 08:53:05 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQoUK-0001uF-00 for simple@ietf.org; Mon, 01 Dec 2003 08:53:20 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AQoUJ-0001uC-00 for simple@ietf.org; Mon, 01 Dec 2003 08:53:19 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1DrHR19135 for ; Mon, 1 Dec 2003 15:53:17 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Dec 2003 15:53:17 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 15:53:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 15:53:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B812.777CB555" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> Thread-Topic: Couple of issues about partial notification draft Thread-Index: AcO4Enbu6ssGjqIjRAe7kj9aSxdRjA== To: X-OriginalArrivalTime: 01 Dec 2003 13:53:16.0243 (UTC) FILETIME=[78390230:01C3B812] Subject: [Simple] Couple of issues about partial notification draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 15:53:15 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3B812.777CB555 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am currently writing an update to draft-ietf-simple-partial-notify-00 and there seems to be couple of issues which probably need some discussion. -Security Considerations section: 01 version currently has following security considerations section "Presence information may contain highly sensitive information about the presentities. The protocol used to distribute it SHOULD ensure privacy, message integrity and authentication. Furthermore, the protocol should provide access controls which restrict who can see who else's presence information. Presence related security considerations are extensively discussed in [draft-ietf-simple-presence-10] and all those identified security consideration apply to this document as well. Partial notification mechanism does not add any new considerations=20 and relies on the mechanisms specified in [draft-ietf-simple-presence-10] and [RFC3261]" Do people on the list think this is sufficient or is there a need to have more text about security in this draft?=20 - IMPP interoperability Partial notification mechanism is not compatible with IMPP work. I think it might be good to have own chapter about this in the draft. Basically I think it should say that mechanism does not by default work with other IMPP compliant systems but this should not be an issue as partial notifications will not be used if requesting end does not understand it. =20 - Mikko ------_=_NextPart_001_01C3B812.777CB555 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Couple of issues about partial notification draft

Hi,

I am currently = writing an update to draft-ietf-simple-partial-notify-00 and there seems = to be couple of issues which probably need some = discussion.

-Security = Considerations section:
01 version currently = has following security considerations section

"Presence = information may contain highly sensitive information about
   the = presentities. The protocol used to distribute it SHOULD = ensure
   = privacy, message integrity and authentication. Furthermore, = the
   = protocol should provide access controls which restrict who can = see
   who = else's presence information. Presence related security
   = considerations are extensively discussed in = [draft-ietf-simple-presence-10] and all those
   = identified security consideration apply to this document as = well.
   Partial notification mechanism does not = add  any new considerations
   and = relies on the mechanisms specified in [draft-ietf-simple-presence-10] = and [RFC3261]"

Do people on the list = think this is sufficient or is there a need to have more text about = security in this draft?

- IMPP = interoperability
Partial notification = mechanism is not compatible with IMPP work. I think it might be good to = have own chapter about this in the draft. Basically I think it should = say that mechanism does not by default work with other IMPP compliant = systems but this should not be an issue as partial notifications will = not be used if requesting end does not understand it.

    =
- = Mikko

------_=_NextPart_001_01C3B812.777CB555-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 10:29:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14786; Mon, 1 Dec 2003 10:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQq02-0003KW-00; Mon, 01 Dec 2003 10:30:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQq02-0003KT-00; Mon, 01 Dec 2003 10:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpzt-0005YK-Ou; Mon, 01 Dec 2003 10:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpyw-0005X2-5m for simple@optimus.ietf.org; Mon, 01 Dec 2003 10:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14735 for ; Mon, 1 Dec 2003 10:28:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQpyp-0003JD-00 for simple@ietf.org; Mon, 01 Dec 2003 10:28:55 -0500 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx with esmtp (Exim 4.12) id 1AQpyj-0003II-00 for simple@ietf.org; Mon, 01 Dec 2003 10:28:50 -0500 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id hB1FSCs08311 for ; Mon, 1 Dec 2003 10:28:12 -0500 (EST) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg01.cc.telcordia.com (SAVSMTP 3.1.2.35) with SMTP id M2003120110281321469 for ; Mon, 01 Dec 2003 10:28:13 -0500 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Dec 2003 10:28:13 -0500 Message-ID: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> From: "Song, Youngsun" To: Simple WG MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] Few questions on Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 10:27:33 -0500 Hi, In , it mentions "application/cpim-pidf+xml" as the presence data format content type. However in , it defines the presence content type as "application/pidf+xml". Are these different types of content types? In Section 6.11.2, Migration, of , it seems that the migration is likely to be used to migrate subscriptions from PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate the subscription if it is composing aggregated presence documents received from multiple PUA." Since it is likely that there will be multiple PUAs where the PA will act as State Agent for presence, it seems that the subscription migration is not likely to occur. Is this right? I am trying to understand the usage of migration for presence. Thanks, YoungSun _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 10:30:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14839 for ; Mon, 1 Dec 2003 10:30:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq06-0005ZT-2S for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 10:30:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1FUES1021408 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 10:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq05-0005ZC-U6 for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 10:30:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14786; Mon, 1 Dec 2003 10:29:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQq02-0003KW-00; Mon, 01 Dec 2003 10:30:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQq02-0003KT-00; Mon, 01 Dec 2003 10:30:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpzt-0005YK-Ou; Mon, 01 Dec 2003 10:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQpyw-0005X2-5m for simple@optimus.ietf.org; Mon, 01 Dec 2003 10:29:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14735 for ; Mon, 1 Dec 2003 10:28:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQpyp-0003JD-00 for simple@ietf.org; Mon, 01 Dec 2003 10:28:55 -0500 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by ietf-mx with esmtp (Exim 4.12) id 1AQpyj-0003II-00 for simple@ietf.org; Mon, 01 Dec 2003 10:28:50 -0500 Received: from rrc-its-ieg01.cc.telcordia.com (rrc-its-ieg01.cc.telcordia.com [128.96.109.78]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id hB1FSCs08311 for ; Mon, 1 Dec 2003 10:28:12 -0500 (EST) Received: from rrc-its-exbh01.mail.saic.com ([128.96.109.61]) by rrc-its-ieg01.cc.telcordia.com (SAVSMTP 3.1.2.35) with SMTP id M2003120110281321469 for ; Mon, 01 Dec 2003 10:28:13 -0500 Received: by rrc-its-exbh01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Dec 2003 10:28:13 -0500 Message-ID: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> From: "Song, Youngsun" To: Simple WG MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Simple] Few questions on Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 10:27:33 -0500 Hi, In , it mentions "application/cpim-pidf+xml" as the presence data format content type. However in , it defines the presence content type as "application/pidf+xml". Are these different types of content types? In Section 6.11.2, Migration, of , it seems that the migration is likely to be used to migrate subscriptions from PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate the subscription if it is composing aggregated presence documents received from multiple PUA." Since it is likely that there will be multiple PUAs where the PA will act as State Agent for presence, it seems that the subscription migration is not likely to occur. Is this right? I am trying to understand the usage of migration for presence. Thanks, YoungSun _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 10:40:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15261; Mon, 1 Dec 2003 10:40:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQq9t-0003T7-00; Mon, 01 Dec 2003 10:40:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQq9s-0003Sz-00; Mon, 01 Dec 2003 10:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQq9Z-0006Ga-EB; Mon, 01 Dec 2003 10:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOvMw-0004bI-S5 for simple@optimus.ietf.org; Wed, 26 Nov 2003 03:49:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27726 for ; Wed, 26 Nov 2003 03:49:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOvMu-0001dx-00 for simple@ietf.org; Wed, 26 Nov 2003 03:49:52 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AOvMt-0001du-00 for simple@ietf.org; Wed, 26 Nov 2003 03:49:51 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAQ8nlI2006739; Wed, 26 Nov 2003 09:49:47 +0100 (MET) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 09:49:55 +0100 Message-ID: From: "Vesa Torvinen (JO/LMF)" To: "'Jonathan Rosenberg'" , Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 26 Nov 2003 09:48:23 +0100 Hi, I think this mechanism goes back to a use case where a policy would define that "anyone that knows this password is allowed to subscribe". The user wouldn't exactly be interested in identities - just to be sure that the watcher knows the password. This use case is similar to the policies currently used in phone conferencing systems where the caller just needs to know the conference id, and related password - and not really to authenticate itself. I agree with you that forcing the use of S/MIME, TLS or P-Asserted-Identity may not be meaningful. However, having policies that mandates the use of HTTP Digest (or some other password based mechanism) may still be useful. Vesa -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of Jonathan Rosenberg Sent: 24. marraskuuta 2003 8:13 To: Simple WG Subject: [Simple] xcap/geopriv alignment issue 4: authentication Folks, Currently, xcap-auth defines an authentication condition. This allows you to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request. The geopriv policy specification currently has no such mechanism. This was discussed during the geopriv meeting in Minneapolis. If you think about it for a bit, its not clear how this would actually get used. Remember, it is end users that will set these policies. What kind of meaningful information can be provided to a user about the differences between p-asserted-id and sip-identity and digest authentication? What would make a user give permission for one type or authentication, and not another? Practically speaking, it doesnt seem like its easy to use at all. As a result, I would propose to remove the authentication condition from xcap-auth. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Mon Dec 1 11:17:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16365; Mon, 1 Dec 2003 11:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqja-0004dW-00; Mon, 01 Dec 2003 11:17:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQqjZ-0004dT-00; Mon, 01 Dec 2003 11:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjN-00083J-8z; Mon, 01 Dec 2003 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjJ-00082y-1U for simple@optimus.ietf.org; Mon, 01 Dec 2003 11:16:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16359 for ; Mon, 1 Dec 2003 11:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqjI-0004aA-00 for simple@ietf.org; Mon, 01 Dec 2003 11:16:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQqjH-0004Ck-00 for simple@ietf.org; Mon, 01 Dec 2003 11:16:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 08:19:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1GGHAt005242; Mon, 1 Dec 2003 08:16:18 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI14843; Mon, 1 Dec 2003 11:16:17 -0500 (EST) Message-ID: <3FCB6950.7000602@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Song, Youngsun" CC: Simple WG Subject: Re: [Simple] Few questions on References: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 11:16:16 -0500 Content-Transfer-Encoding: 7bit Song, Youngsun wrote: > Hi, > > In , it mentions > "application/cpim-pidf+xml" as the presence data format content type. > However in , it defines the presence > content type as "application/pidf+xml". Are these different types of content > types? Looks like a bug to me. > In Section 6.11.2, Migration, of , it > seems that the migration is likely to be used to migrate subscriptions from > PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate > the subscription if it is composing aggregated presence documents received > from multiple PUA." Since it is likely that there will be multiple PUAs > where the PA will act as State Agent for presence, it seems that the > subscription migration is not likely to occur. Is this right? I am trying to > understand the usage of migration for presence. There are many ways to implement this, and I'm not sure I understand what one you have in mind. One way that seems likely is for there to be a single PA acting on behalf of many presentities. For each presentity there may be zero, one, or more PUAs providing presence documents to be composed. The decision the PA must make about migrating a subscription needs to be made independently for each presentity. If the PA is aggregating presence from multiple PUAs on behalf of a particular presentity, then it would be unwise to migrate the presence subscriptions to one of the PUAs. But it can be fine to do so for a presentity that has only one PUA reporting. Clearly there are logistical problems if a second PUA comes online when subscriptions have been migrated to what had been the only PUA. Either that case needs to be avoided by configuration, or else it must be detected so that subscriptions can be migrated back to the PA. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 11:17:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16384 for ; Mon, 1 Dec 2003 11:17:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjb-000847-Tm for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 11:17:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1GHFui031003 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 11:17:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjb-00083y-Hk for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 11:17:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16365; Mon, 1 Dec 2003 11:17:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqja-0004dW-00; Mon, 01 Dec 2003 11:17:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQqjZ-0004dT-00; Mon, 01 Dec 2003 11:17:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjN-00083J-8z; Mon, 01 Dec 2003 11:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQqjJ-00082y-1U for simple@optimus.ietf.org; Mon, 01 Dec 2003 11:16:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16359 for ; Mon, 1 Dec 2003 11:16:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQqjI-0004aA-00 for simple@ietf.org; Mon, 01 Dec 2003 11:16:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQqjH-0004Ck-00 for simple@ietf.org; Mon, 01 Dec 2003 11:16:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 08:19:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB1GGHAt005242; Mon, 1 Dec 2003 08:16:18 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI14843; Mon, 1 Dec 2003 11:16:17 -0500 (EST) Message-ID: <3FCB6950.7000602@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Song, Youngsun" CC: Simple WG Subject: Re: [Simple] Few questions on References: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 11:16:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Song, Youngsun wrote: > Hi, > > In , it mentions > "application/cpim-pidf+xml" as the presence data format content type. > However in , it defines the presence > content type as "application/pidf+xml". Are these different types of content > types? Looks like a bug to me. > In Section 6.11.2, Migration, of , it > seems that the migration is likely to be used to migrate subscriptions from > PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate > the subscription if it is composing aggregated presence documents received > from multiple PUA." Since it is likely that there will be multiple PUAs > where the PA will act as State Agent for presence, it seems that the > subscription migration is not likely to occur. Is this right? I am trying to > understand the usage of migration for presence. There are many ways to implement this, and I'm not sure I understand what one you have in mind. One way that seems likely is for there to be a single PA acting on behalf of many presentities. For each presentity there may be zero, one, or more PUAs providing presence documents to be composed. The decision the PA must make about migrating a subscription needs to be made independently for each presentity. If the PA is aggregating presence from multiple PUAs on behalf of a particular presentity, then it would be unwise to migrate the presence subscriptions to one of the PUAs. But it can be fine to do so for a presentity that has only one PUA reporting. Clearly there are logistical problems if a second PUA comes online when subscriptions have been migrated to what had been the only PUA. Either that case needs to be avoided by configuration, or else it must be detected so that subscriptions can be migrated back to the PA. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 11:42:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17135; Mon, 1 Dec 2003 11:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr8g-0004y2-00; Mon, 01 Dec 2003 11:43:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQr8f-0004xz-00; Mon, 01 Dec 2003 11:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8X-0000rq-9W; Mon, 01 Dec 2003 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8Q-0000r2-EP for simple@optimus.ietf.org; Mon, 01 Dec 2003 11:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17097 for ; Mon, 1 Dec 2003 11:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr8P-0004xB-00 for simple@ietf.org; Mon, 01 Dec 2003 11:42:53 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AQr0g-0004lT-00 for simple@ietf.org; Mon, 01 Dec 2003 11:34:54 -0500 Received: from [208.21.192.130] (helo=magus.nostrum.com ident=root) by manatick with esmtp (Exim 4.24) id 1AQqnB-0006EF-RP for simple@ietf.org; Mon, 01 Dec 2003 11:20:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1GKDnG065238; Mon, 1 Dec 2003 10:20:24 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB6A2D.801@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> <3FC4B951.2090508@dynamicsoft.com> <1070038227.935.18.camel@RjS.localdomain> In-Reply-To: <1070038227.935.18.camel@RjS.localdomain> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 10:19:57 -0600 Content-Transfer-Encoding: 7bit Robert Sparks wrote: > On Wed, 2003-11-26 at 08:31, Ben Campbell wrote: > >>Robert Sparks wrote: >> >> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >> >>I do have to point out that most of the existing, big commercially >>deployed systems, are single-domain, non-interoperable systems. We make >>due with them because that is what exists. I did not think that is what >>we are trying to build here. > > > No, but the question starting this thread is whether or not it would > be acceptable to have a base authorization system that didn't support > exceptions. My point is that there are environments where such a system > would be useful. (And I don't think the single-domain/non-interoperable > characteristics of the existing systems I refer to is pertainant to that > statement.) > > >>Let me back off from saying you cannot build a useful system without >>exceptions. Let me instead state that I have endured a number of >>customer requests for authorization models that cannot be implemented >>without exceptions. > > > Is there something in this set of requests that would make having > exceptions as an extension to the core protocol unacceptable? > It really does not matter how it is structured, as long as we have the capability. For the scenarios I refer to, I think XCAP will not likely get significant use until exceptions are available. > >>>On reflection, when using future systems I think I will prefer the model >>>of explicitly listing those people I wish to authorize over excepting >>>individuals from a set I cannot control and possibly cannot know. >>> >>>Thus, I don't think it is absolutely necessary to have that kind of >>>statement in the initial xcap-auth mechanism. >>> >> >>Out of curiosity, do you see it necessary to be able to say a rule >>applies to a domain at all? Or to generalize, to any "group" where >>membership is determined when the rule is applied, rather than when it >>is created? > > > Useful. Useful enough that I want a system that supports the concept. > But absolutely necessary? No. A core authorization system that did not > support this concept would still be useful. Certainly, there are scenarios for which exceptions are not needed to have a useful system. For that matter, there are scenarios where XCAP is not needed to have a useful system. This seems a specious argument, unless we are able to bound what scenarios are important to us. > > >>>I do see the power of having such a statement to some applications >>>that may consume presence, and I would very much like to have such >>>a statement available. I think it is acceptable for this functionality >>>to be an extension of the base xcap-auth tool. I am not convinced that the cost of including a very simplistic exception mechanism (that is, no external resolution allowed for the exception clause) is that much of an incremental effort compared to the rest of the language. If we are talking about core plus extensions, I would prefer to see a limited exception clause in the core, and perhaps a more general one as an extension. >>> >>>RjS >>> >>>On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: >>> >>> >>>>>>So you have allowed John, Alice, Ben and Adam. That is _not_ >>>>>>the same as >>>>>>"Everyone but Bob". For example, what if Carol joins example.com >>>>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>>>>>not include >>>>>>her, but the "Everyone but Bob rule" would. >>>>> >>>>> >>>>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. >>>>> >>>> >>>>That assumes you know about Carol. My point is, these two cases are not >>>>the same thing. You might be able to simulate something like exceptions >>>>by doing this, if and only if you have full knowledge of the membership >>>>of example.com. I suspect that will commonly be false. >>>> >>> >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 11:43:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17164 for ; Mon, 1 Dec 2003 11:43:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8i-0000t0-JD for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 11:43:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1GhCSX003400 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 11:43:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8i-0000sl-FP for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 11:43:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17135; Mon, 1 Dec 2003 11:42:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr8g-0004y2-00; Mon, 01 Dec 2003 11:43:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQr8f-0004xz-00; Mon, 01 Dec 2003 11:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8X-0000rq-9W; Mon, 01 Dec 2003 11:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQr8Q-0000r2-EP for simple@optimus.ietf.org; Mon, 01 Dec 2003 11:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17097 for ; Mon, 1 Dec 2003 11:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQr8P-0004xB-00 for simple@ietf.org; Mon, 01 Dec 2003 11:42:53 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AQr0g-0004lT-00 for simple@ietf.org; Mon, 01 Dec 2003 11:34:54 -0500 Received: from [208.21.192.130] (helo=magus.nostrum.com ident=root) by manatick with esmtp (Exim 4.24) id 1AQqnB-0006EF-RP for simple@ietf.org; Mon, 01 Dec 2003 11:20:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1GKDnG065238; Mon, 1 Dec 2003 10:20:24 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB6A2D.801@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Hisham Khartabil , jdrosen@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <2038BCC78B1AD641891A0D1AE133DBB70118B10A@esebe019.ntc.nokia.com> <3FC3C480.5080908@dynamicsoft.com> <1069828552.1007.56.camel@RjS.localdomain> <3FC4B951.2090508@dynamicsoft.com> <1070038227.935.18.camel@RjS.localdomain> In-Reply-To: <1070038227.935.18.camel@RjS.localdomain> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 10:19:57 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Robert Sparks wrote: > On Wed, 2003-11-26 at 08:31, Ben Campbell wrote: > >>Robert Sparks wrote: >> >> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >> >>I do have to point out that most of the existing, big commercially >>deployed systems, are single-domain, non-interoperable systems. We make >>due with them because that is what exists. I did not think that is what >>we are trying to build here. > > > No, but the question starting this thread is whether or not it would > be acceptable to have a base authorization system that didn't support > exceptions. My point is that there are environments where such a system > would be useful. (And I don't think the single-domain/non-interoperable > characteristics of the existing systems I refer to is pertainant to that > statement.) > > >>Let me back off from saying you cannot build a useful system without >>exceptions. Let me instead state that I have endured a number of >>customer requests for authorization models that cannot be implemented >>without exceptions. > > > Is there something in this set of requests that would make having > exceptions as an extension to the core protocol unacceptable? > It really does not matter how it is structured, as long as we have the capability. For the scenarios I refer to, I think XCAP will not likely get significant use until exceptions are available. > >>>On reflection, when using future systems I think I will prefer the model >>>of explicitly listing those people I wish to authorize over excepting >>>individuals from a set I cannot control and possibly cannot know. >>> >>>Thus, I don't think it is absolutely necessary to have that kind of >>>statement in the initial xcap-auth mechanism. >>> >> >>Out of curiosity, do you see it necessary to be able to say a rule >>applies to a domain at all? Or to generalize, to any "group" where >>membership is determined when the rule is applied, rather than when it >>is created? > > > Useful. Useful enough that I want a system that supports the concept. > But absolutely necessary? No. A core authorization system that did not > support this concept would still be useful. Certainly, there are scenarios for which exceptions are not needed to have a useful system. For that matter, there are scenarios where XCAP is not needed to have a useful system. This seems a specious argument, unless we are able to bound what scenarios are important to us. > > >>>I do see the power of having such a statement to some applications >>>that may consume presence, and I would very much like to have such >>>a statement available. I think it is acceptable for this functionality >>>to be an extension of the base xcap-auth tool. I am not convinced that the cost of including a very simplistic exception mechanism (that is, no external resolution allowed for the exception clause) is that much of an incremental effort compared to the rest of the language. If we are talking about core plus extensions, I would prefer to see a limited exception clause in the core, and perhaps a more general one as an extension. >>> >>>RjS >>> >>>On Tue, 2003-11-25 at 15:07, Ben Campbell wrote: >>> >>> >>>>>>So you have allowed John, Alice, Ben and Adam. That is _not_ >>>>>>the same as >>>>>>"Everyone but Bob". For example, what if Carol joins example.com >>>>>>tomorrow. The "Allow John, Alice, Ben, and Adam" rule will >>>>>>not include >>>>>>her, but the "Everyone but Bob rule" would. >>>>> >>>>> >>>>>Then you add a permission statement for Carol. This works. Jonathan did not suggest throwing away exceptions indefinitely. He questioned the usability of the first cut of xcap-auth without exceptions, and my opinion is that it is usable in the manner I described. >>>>> >>>> >>>>That assumes you know about Carol. My point is, these two cases are not >>>>the same thing. You might be able to simulate something like exceptions >>>>by doing this, if and only if you have full knowledge of the membership >>>>of example.com. I suspect that will commonly be false. >>>> >>> >>> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 12:22:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18615; Mon, 1 Dec 2003 12:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrlK-0005Yr-00; Mon, 01 Dec 2003 12:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQrlK-0005Ym-00; Mon, 01 Dec 2003 12:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrlF-0003NH-Dw; Mon, 01 Dec 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrkj-0003Me-47 for simple@optimus.ietf.org; Mon, 01 Dec 2003 12:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18583 for ; Mon, 1 Dec 2003 12:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrkh-0005Ya-00 for simple@ietf.org; Mon, 01 Dec 2003 12:22:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AQrkh-0005Xt-00 for simple@ietf.org; Mon, 01 Dec 2003 12:22:27 -0500 Received: from dynamicsoft.com ([63.113.46.43]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB1HLnca025072; Mon, 1 Dec 2003 12:21:49 -0500 (EST) Message-ID: <3FCB78A8.8050205@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Song, Youngsun" , Simple WG Subject: Re: [Simple] Few questions on References: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> <3FCB6950.7000602@cisco.com> In-Reply-To: <3FCB6950.7000602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 12:21:44 -0500 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Song, Youngsun wrote: > >> Hi, >> >> In , it mentions >> "application/cpim-pidf+xml" as the presence data format content type. >> However in , it defines the presence >> content type as "application/pidf+xml". Are these different types of >> content >> types? > > > Looks like a bug to me. Yup, and a big one. I'll be sure it gets fixed in authors 48. > >> In Section 6.11.2, Migration, of , it >> seems that the migration is likely to be used to migrate subscriptions >> from >> PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate >> the subscription if it is composing aggregated presence documents >> received >> from multiple PUA." Since it is likely that there will be multiple PUAs >> where the PA will act as State Agent for presence, it seems that the >> subscription migration is not likely to occur. Is this right? I am >> trying to >> understand the usage of migration for presence. My general sense is that migration will not be terribly common. Over time, I would expect that the common case is multiple PUA, in which case migration is not possible. I think the system is overall easier to design and manage when presence is stored and processed in a single, reliable place. > > > There are many ways to implement this, and I'm not sure I understand > what one you have in mind. One way that seems likely is for there to be > a single PA acting on behalf of many presentities. For each presentity > there may be zero, one, or more PUAs providing presence documents to be > composed. > > The decision the PA must make about migrating a subscription needs to be > made independently for each presentity. If the PA is aggregating > presence from multiple PUAs on behalf of a particular presentity, then > it would be unwise to migrate the presence subscriptions to one of the > PUAs. But it can be fine to do so for a presentity that has only one PUA > reporting. > > Clearly there are logistical problems if a second PUA comes online when > subscriptions have been migrated to what had been the only PUA. Either > that case needs to be avoided by configuration, or else it must be > detected so that subscriptions can be migrated back to the PA. I believe it can be detected if the second PUA uses PUBLISH. When the publish reaches the presence server for the domain, it would presumably forward the request to the UA that is currently acting as PA. If that UA cannot compose together presence documents, it can reject the PUBLISH (with a Retry-After), terminate all subscriptions, and unregster support for the SUBSCRIBE method. This would force migration back to the server. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 12:23:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18654 for ; Mon, 1 Dec 2003 12:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrlM-0003OL-QL for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 12:23:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1HN83F013031 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 12:23:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrlM-0003O6-NN for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 12:23:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18615; Mon, 1 Dec 2003 12:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrlK-0005Yr-00; Mon, 01 Dec 2003 12:23:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQrlK-0005Ym-00; Mon, 01 Dec 2003 12:23:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrlF-0003NH-Dw; Mon, 01 Dec 2003 12:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQrkj-0003Me-47 for simple@optimus.ietf.org; Mon, 01 Dec 2003 12:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18583 for ; Mon, 1 Dec 2003 12:22:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQrkh-0005Ya-00 for simple@ietf.org; Mon, 01 Dec 2003 12:22:27 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AQrkh-0005Xt-00 for simple@ietf.org; Mon, 01 Dec 2003 12:22:27 -0500 Received: from dynamicsoft.com ([63.113.46.43]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB1HLnca025072; Mon, 1 Dec 2003 12:21:49 -0500 (EST) Message-ID: <3FCB78A8.8050205@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: "Song, Youngsun" , Simple WG Subject: Re: [Simple] Few questions on References: <7B762A7337179544B02B707FAC7F6F1903C98FC1@rrc-its-exs03.mail.saic.com> <3FCB6950.7000602@cisco.com> In-Reply-To: <3FCB6950.7000602@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 12:21:44 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Song, Youngsun wrote: > >> Hi, >> >> In , it mentions >> "application/cpim-pidf+xml" as the presence data format content type. >> However in , it defines the presence >> content type as "application/pidf+xml". Are these different types of >> content >> types? > > > Looks like a bug to me. Yup, and a big one. I'll be sure it gets fixed in authors 48. > >> In Section 6.11.2, Migration, of , it >> seems that the migration is likely to be used to migrate subscriptions >> from >> PA to PUAs. At the end of the section, it states "A PA SHOULD NOT migrate >> the subscription if it is composing aggregated presence documents >> received >> from multiple PUA." Since it is likely that there will be multiple PUAs >> where the PA will act as State Agent for presence, it seems that the >> subscription migration is not likely to occur. Is this right? I am >> trying to >> understand the usage of migration for presence. My general sense is that migration will not be terribly common. Over time, I would expect that the common case is multiple PUA, in which case migration is not possible. I think the system is overall easier to design and manage when presence is stored and processed in a single, reliable place. > > > There are many ways to implement this, and I'm not sure I understand > what one you have in mind. One way that seems likely is for there to be > a single PA acting on behalf of many presentities. For each presentity > there may be zero, one, or more PUAs providing presence documents to be > composed. > > The decision the PA must make about migrating a subscription needs to be > made independently for each presentity. If the PA is aggregating > presence from multiple PUAs on behalf of a particular presentity, then > it would be unwise to migrate the presence subscriptions to one of the > PUAs. But it can be fine to do so for a presentity that has only one PUA > reporting. > > Clearly there are logistical problems if a second PUA comes online when > subscriptions have been migrated to what had been the only PUA. Either > that case needs to be avoided by configuration, or else it must be > detected so that subscriptions can be migrated back to the PA. I believe it can be detected if the second PUA uses PUBLISH. When the publish reaches the presence server for the domain, it would presumably forward the request to the UA that is currently acting as PA. If that UA cannot compose together presence documents, it can reject the PUBLISH (with a Retry-After), terminate all subscriptions, and unregster support for the SUBSCRIBE method. This would force migration back to the server. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 14:13:49 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23103; Mon, 1 Dec 2003 14:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtUh-00070X-00; Mon, 01 Dec 2003 14:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtUg-00070T-00; Mon, 01 Dec 2003 14:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtUe-0002gC-Q0; Mon, 01 Dec 2003 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtTj-0002ct-Gg for simple@optimus.ietf.org; Mon, 01 Dec 2003 14:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23052 for ; Mon, 1 Dec 2003 14:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtTh-0006zL-00 for simple@ietf.org; Mon, 01 Dec 2003 14:13:01 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AQtTg-0006z9-00 for simple@ietf.org; Mon, 01 Dec 2003 14:13:00 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1JChnG079355 for ; Mon, 1 Dec 2003 13:12:54 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB929A.4060703@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MS(r)P: Reconnect issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 13:12:26 -0600 Content-Transfer-Encoding: 7bit In Minneapolis, the wg expressed a consensus that MS(r)P (pending rename) should allow reconnection of dropped TCP connections without requiring a new offer/answer. In that meeting, I mentioned that there was a reason we had originally chose not to allow that, but I could not remember the details at the time. Having slept since then, I now remember: Consider a visitor V has a TCP connection to a host H, with an active session. That TCP connection is then dropped due to something in the network. I don't know why, maybe a stateful firewall dropped state, or a length of fiber was accidentally eaten by a sabre-tooth tiger. In any case, the connection is dropped without a proper FIN handshake at the endpoints. It may take each endpoint sometime to actually notice that this has occurred. Using common TCP state machine defaults, it will typically take just under 10 minutes. It is also likely that the participants will not figure it out at the same time. If H figures it out first, then things are reasonable ok. It just waits some period of time for V to notice, reconnect, and send a VISIT with the session URI. But if V figures it out first, we have a problem. V will reconnect, and attempt a VISIT with the session URI. The problem is, H thinks it already has a perfectly good connection for that session. It has two possible choices: 1) Fail the new VISIT, and assume the old one is still good, or 2) Disconnect the old connection, and accept the VISIT request on the new connection. Option 1 is the currently defined behavior. It seems pretty obvious that this pretty much prevents reconnections. Option 2 would allow reconnections, but it allows a really nasty session hijacking attack if an attacker happens to learn the session URI. I discussed this with several people a while back, and the consensus seemed to be that option 2 was not feasible, so we had to require a new sdp exchange with a new session URI in order to reconnect. Option 1 _might_ be acceptable if we could guarantee the confidentiality of the session URI. If we were to accept option 1, we would then have a strong reason to _require_ the sdp exchange be protected by using either SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also requires the host to listen for new connections pretty much forever, which is not particularly pleasant. Thoughts? Have I missed an option? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 14:14:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23148 for ; Mon, 1 Dec 2003 14:14:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtUk-0002hA-IO for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 14:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1JE68i010356 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 14:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtUk-0002gx-EY for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23103; Mon, 1 Dec 2003 14:13:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtUh-00070X-00; Mon, 01 Dec 2003 14:14:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQtUg-00070T-00; Mon, 01 Dec 2003 14:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtUe-0002gC-Q0; Mon, 01 Dec 2003 14:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQtTj-0002ct-Gg for simple@optimus.ietf.org; Mon, 01 Dec 2003 14:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23052 for ; Mon, 1 Dec 2003 14:12:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQtTh-0006zL-00 for simple@ietf.org; Mon, 01 Dec 2003 14:13:01 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AQtTg-0006z9-00 for simple@ietf.org; Mon, 01 Dec 2003 14:13:00 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1JChnG079355 for ; Mon, 1 Dec 2003 13:12:54 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB929A.4060703@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MS(r)P: Reconnect issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 13:12:26 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In Minneapolis, the wg expressed a consensus that MS(r)P (pending rename) should allow reconnection of dropped TCP connections without requiring a new offer/answer. In that meeting, I mentioned that there was a reason we had originally chose not to allow that, but I could not remember the details at the time. Having slept since then, I now remember: Consider a visitor V has a TCP connection to a host H, with an active session. That TCP connection is then dropped due to something in the network. I don't know why, maybe a stateful firewall dropped state, or a length of fiber was accidentally eaten by a sabre-tooth tiger. In any case, the connection is dropped without a proper FIN handshake at the endpoints. It may take each endpoint sometime to actually notice that this has occurred. Using common TCP state machine defaults, it will typically take just under 10 minutes. It is also likely that the participants will not figure it out at the same time. If H figures it out first, then things are reasonable ok. It just waits some period of time for V to notice, reconnect, and send a VISIT with the session URI. But if V figures it out first, we have a problem. V will reconnect, and attempt a VISIT with the session URI. The problem is, H thinks it already has a perfectly good connection for that session. It has two possible choices: 1) Fail the new VISIT, and assume the old one is still good, or 2) Disconnect the old connection, and accept the VISIT request on the new connection. Option 1 is the currently defined behavior. It seems pretty obvious that this pretty much prevents reconnections. Option 2 would allow reconnections, but it allows a really nasty session hijacking attack if an attacker happens to learn the session URI. I discussed this with several people a while back, and the consensus seemed to be that option 2 was not feasible, so we had to require a new sdp exchange with a new session URI in order to reconnect. Option 1 _might_ be acceptable if we could guarantee the confidentiality of the session URI. If we were to accept option 1, we would then have a strong reason to _require_ the sdp exchange be protected by using either SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also requires the host to listen for new connections pretty much forever, which is not particularly pleasant. Thoughts? Have I missed an option? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 14:54:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24484; Mon, 1 Dec 2003 14:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQu8P-0007Nt-00; Mon, 01 Dec 2003 14:55:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQu8P-0007Nq-00; Mon, 01 Dec 2003 14:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu8M-0004x1-9e; Mon, 01 Dec 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu7O-0004wG-7y for simple@optimus.ietf.org; Mon, 01 Dec 2003 14:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24419 for ; Mon, 1 Dec 2003 14:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQu7L-0007NE-00 for simple@ietf.org; Mon, 01 Dec 2003 14:53:59 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AQu7K-0007N9-00 for simple@ietf.org; Mon, 01 Dec 2003 14:53:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1JrvnG082956; Mon, 1 Dec 2003 13:53:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB9C43.4070508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FCB929A.4060703@dynamicsoft.com> In-Reply-To: <3FCB929A.4060703@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: MS(r)P: Reconnect issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 13:53:39 -0600 Content-Transfer-Encoding: 7bit Oops, got my options mixed up. See clarification below. Ben Campbell wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > For the above paragraph, I meant option 2. My apologies if anyone hurt their brain trying to figure out how that paragraph applied to option 1. > Thoughts? Have I missed an option? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 14:55:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24508 for ; Mon, 1 Dec 2003 14:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu8T-0004y5-8n for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 14:55:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Jt9WL019091 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 14:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu8T-0004xq-4E for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 14:55:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24484; Mon, 1 Dec 2003 14:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQu8P-0007Nt-00; Mon, 01 Dec 2003 14:55:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQu8P-0007Nq-00; Mon, 01 Dec 2003 14:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu8M-0004x1-9e; Mon, 01 Dec 2003 14:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQu7O-0004wG-7y for simple@optimus.ietf.org; Mon, 01 Dec 2003 14:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24419 for ; Mon, 1 Dec 2003 14:53:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQu7L-0007NE-00 for simple@ietf.org; Mon, 01 Dec 2003 14:53:59 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AQu7K-0007N9-00 for simple@ietf.org; Mon, 01 Dec 2003 14:53:58 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB1JrvnG082956; Mon, 1 Dec 2003 13:53:57 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCB9C43.4070508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG References: <3FCB929A.4060703@dynamicsoft.com> In-Reply-To: <3FCB929A.4060703@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: MS(r)P: Reconnect issue Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 13:53:39 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Oops, got my options mixed up. See clarification below. Ben Campbell wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > For the above paragraph, I meant option 2. My apologies if anyone hurt their brain trying to figure out how that paragraph applied to option 1. > Thoughts? Have I missed an option? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 15:40:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28226; Mon, 1 Dec 2003 15:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuqw-0000AO-00; Mon, 01 Dec 2003 15:41:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuqw-0000AL-00; Mon, 01 Dec 2003 15:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqr-0000sO-Td; Mon, 01 Dec 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqO-0000rx-Sr for simple@optimus.ietf.org; Mon, 01 Dec 2003 15:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28198 for ; Mon, 1 Dec 2003 15:40:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuqN-00009y-00 for simple@ietf.org; Mon, 01 Dec 2003 15:40:31 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AQuqM-00009v-00 for simple@ietf.org; Mon, 01 Dec 2003 15:40:30 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 7FD56B65AF for ; Mon, 1 Dec 2003 15:40:14 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120115400206455 for ; Mon, 01 Dec 2003 15:40:02 -0500 content-class: urn:content-classes:message Subject: RE: [Simple] Re: MS(r)P: Reconnect issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO4RRkH3QZgn4O9RqmHXw2jOzvcEQAArOGQ From: "Andrew Allen" To: "Ben Campbell" Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 15:39:02 -0500 Content-Transfer-Encoding: quoted-printable Ben=20 Ben, If Option 2 requires end-to-end encryption of the SDP to protect the URL then it is not going to be suitable for use by 3GPP for message sessions at the present time. The 3GPP network currently needs to examine the SDP to perform authorization and allocation of radio resources for the session. In the wireless case the chances of dropped connections are probably a lot higher with the mobile potentially moving in and out of coverage (especially if going through tunnels on a train) so this is likely to be a more common scenario in wireless. What were the main objections to re-invitation as a solution? Why not use UPDATE to attempt to re-establish connections in the case when the dialog still exists? UPDATE is less expensive in terms of SIP messages to re-establish (no ACK required). In the 3GPP case the sending of a SIP request is likely to trigger a network initiated termination of the session (a BYE) if the mobile is still out of coverage, which I expect is what is desired in the wireless case to release the network resources. Andrew =20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, December 01, 2003 2:54 PM > To: Ben Campbell > Cc: Simple WG > Subject: [Simple] Re: MS(r)P: Reconnect issue >=20 > Oops, got my options mixed up. See clarification below. >=20 > Ben Campbell wrote: >=20 > > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > rename) should allow reconnection of dropped TCP connections without > > requiring a new offer/answer. In that meeting, I mentioned that there > > was a reason we had originally chose not to allow that, but I could not > > remember the details at the time. Having slept since then, I now > remember: > > > > Consider a visitor V has a TCP connection to a host H, with an active > > session. That TCP connection is then dropped due to something in the > > network. I don't know why, maybe a stateful firewall dropped state, or a > > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > > case, the connection is dropped without a proper FIN handshake at the > > endpoints. > > > > It may take each endpoint sometime to actually notice that this has > > occurred. Using common TCP state machine defaults, it will typically > > take just under 10 minutes. It is also likely that the participants will > > not figure it out at the same time. > > > > If H figures it out first, then things are reasonable ok. It just waits > > some period of time for V to notice, reconnect, and send a VISIT with > > the session URI. > > > > But if V figures it out first, we have a problem. V will reconnect, and > > attempt a VISIT with the session URI. The problem is, H thinks it > > already has a perfectly good connection for that session. It has two > > possible choices: 1) Fail the new VISIT, and assume the old one is still > > good, or 2) Disconnect the old connection, and accept the VISIT request > > on the new connection. > > > > Option 1 is the currently defined behavior. It seems pretty obvious that > > this pretty much prevents reconnections. Option 2 would allow > > reconnections, but it allows a really nasty session hijacking attack if > > an attacker happens to learn the session URI. > > > > I discussed this with several people a while back, and the consensus > > seemed to be that option 2 was not feasible, so we had to require a new > > sdp exchange with a new session URI in order to reconnect. > > > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > > of the session URI. If we were to accept option 1, we would then have a > > strong reason to _require_ the sdp exchange be protected by using either > > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > > requires the host to listen for new connections pretty much forever, > > which is not particularly pleasant. > > >=20 > For the above paragraph, I meant option 2. My apologies if anyone hurt > their brain trying to figure out how that paragraph applied to option 1. >=20 >=20 > > Thoughts? Have I missed an option? > > >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 1 15:41:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28266 for ; Mon, 1 Dec 2003 15:41:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqy-0000tX-Tz for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 15:41:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1Kf8Os003433 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 15:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqy-0000tI-NF for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 15:41:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28226; Mon, 1 Dec 2003 15:40:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuqw-0000AO-00; Mon, 01 Dec 2003 15:41:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQuqw-0000AL-00; Mon, 01 Dec 2003 15:41:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqr-0000sO-Td; Mon, 01 Dec 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQuqO-0000rx-Sr for simple@optimus.ietf.org; Mon, 01 Dec 2003 15:40:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28198 for ; Mon, 1 Dec 2003 15:40:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQuqN-00009y-00 for simple@ietf.org; Mon, 01 Dec 2003 15:40:31 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AQuqM-00009v-00 for simple@ietf.org; Mon, 01 Dec 2003 15:40:30 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 7FD56B65AF for ; Mon, 1 Dec 2003 15:40:14 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120115400206455 for ; Mon, 01 Dec 2003 15:40:02 -0500 content-class: urn:content-classes:message Subject: RE: [Simple] Re: MS(r)P: Reconnect issue MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO4RRkH3QZgn4O9RqmHXw2jOzvcEQAArOGQ From: "Andrew Allen" To: "Ben Campbell" Cc: "Simple WG" Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 15:39:02 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben=20 Ben, If Option 2 requires end-to-end encryption of the SDP to protect the URL then it is not going to be suitable for use by 3GPP for message sessions at the present time. The 3GPP network currently needs to examine the SDP to perform authorization and allocation of radio resources for the session. In the wireless case the chances of dropped connections are probably a lot higher with the mobile potentially moving in and out of coverage (especially if going through tunnels on a train) so this is likely to be a more common scenario in wireless. What were the main objections to re-invitation as a solution? Why not use UPDATE to attempt to re-establish connections in the case when the dialog still exists? UPDATE is less expensive in terms of SIP messages to re-establish (no ACK required). In the 3GPP case the sending of a SIP request is likely to trigger a network initiated termination of the session (a BYE) if the mobile is still out of coverage, which I expect is what is desired in the wireless case to release the network resources. Andrew =20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Monday, December 01, 2003 2:54 PM > To: Ben Campbell > Cc: Simple WG > Subject: [Simple] Re: MS(r)P: Reconnect issue >=20 > Oops, got my options mixed up. See clarification below. >=20 > Ben Campbell wrote: >=20 > > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > rename) should allow reconnection of dropped TCP connections without > > requiring a new offer/answer. In that meeting, I mentioned that there > > was a reason we had originally chose not to allow that, but I could not > > remember the details at the time. Having slept since then, I now > remember: > > > > Consider a visitor V has a TCP connection to a host H, with an active > > session. That TCP connection is then dropped due to something in the > > network. I don't know why, maybe a stateful firewall dropped state, or a > > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > > case, the connection is dropped without a proper FIN handshake at the > > endpoints. > > > > It may take each endpoint sometime to actually notice that this has > > occurred. Using common TCP state machine defaults, it will typically > > take just under 10 minutes. It is also likely that the participants will > > not figure it out at the same time. > > > > If H figures it out first, then things are reasonable ok. It just waits > > some period of time for V to notice, reconnect, and send a VISIT with > > the session URI. > > > > But if V figures it out first, we have a problem. V will reconnect, and > > attempt a VISIT with the session URI. The problem is, H thinks it > > already has a perfectly good connection for that session. It has two > > possible choices: 1) Fail the new VISIT, and assume the old one is still > > good, or 2) Disconnect the old connection, and accept the VISIT request > > on the new connection. > > > > Option 1 is the currently defined behavior. It seems pretty obvious that > > this pretty much prevents reconnections. Option 2 would allow > > reconnections, but it allows a really nasty session hijacking attack if > > an attacker happens to learn the session URI. > > > > I discussed this with several people a while back, and the consensus > > seemed to be that option 2 was not feasible, so we had to require a new > > sdp exchange with a new session URI in order to reconnect. > > > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > > of the session URI. If we were to accept option 1, we would then have a > > strong reason to _require_ the sdp exchange be protected by using either > > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > > requires the host to listen for new connections pretty much forever, > > which is not particularly pleasant. > > >=20 > For the above paragraph, I meant option 2. My apologies if anyone hurt > their brain trying to figure out how that paragraph applied to option 1. >=20 >=20 > > Thoughts? Have I missed an option? > > >=20 >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Mon Dec 1 16:20:24 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00542; Mon, 1 Dec 2003 16:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvTA-0001e5-00; Mon, 01 Dec 2003 16:20:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvT9-0001dU-00; Mon, 01 Dec 2003 16:20:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvSc-00036f-Rp; Mon, 01 Dec 2003 16:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvSI-00035o-Qh for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00459 for ; Mon, 1 Dec 2003 16:19:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvSG-0001ct-00 for simple@ietf.org; Mon, 01 Dec 2003 16:19:40 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQvSB-0001bl-00 for simple@ietf.org; Mon, 01 Dec 2003 16:19:35 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hB1LIicb001817; Mon, 1 Dec 2003 15:18:44 -0600 (CST) Message-ID: <3FCBB032.75A7B96A@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vesa Torvinen (JO/LMF)" CC: "'Jonathan Rosenberg'" , "'Simple WG'" Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 15:18:43 -0600 Content-Transfer-Encoding: 7bit I think being able to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request is useful. That would allow me, for example, to reject clients using a less secure authentication scheme or force them to use a more secure one (e.g. Basic Access Authentication vs Digest Access Authentication). Regards, Alex. "Vesa Torvinen (JO/LMF)" wrote: > Hi, > > [Tried to send something on this before but haven't seen my mail on the list... this is the second try.] > > I think this was originally related to a use case where a policy would define that "anyone that knows the password is allowed to subscribe". The presentity wouldn't exactly be interested in authentication in terms of identities (the watcher could be "anonymous") - just to be sure that all authorized watchers know the password. This use case is similar to the policies currently used in phone conferencing systems, i.e. the participant just needs to know the conference id, and related password - and not really to authenticate himself in terms of real identity. One problem is, of course, that the password should be specific to the presentity, e.g. "realm=alice@domain.com", not to the "realm=domain.com" as a whole. > > There has also been some discussion in 3GPP/SA3 on having an option for using a password based authentication in addition to the P-Asserted-Identity header based "authentication". Not all people like this idea, however, it could provide some additional security for 3GPP IP multimedia subsystem. For example, HTTP Digest AKA (that is used to create the P-Asserted-Identity) does not really authenticate the end-user - it authenticates the subscription/device. > > I agree that forcing the use of S/MIME, TLS or P-Asserted-Identity is not really meaningful. However, having policies that mandate the use of HTTP Digest (or some other password based mechanism) may still be useful. > > Vesa > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > Folks, > > Currently, xcap-auth defines an authentication condition. This allows > you to decide whether to accept or reject a subscription based on the > type of authentication used in the SUBSCRIBE request. > > The geopriv policy specification currently has no such mechanism. > > This was discussed during the geopriv meeting in Minneapolis. If you > think about it for a bit, its not clear how this would actually get > used. Remember, it is end users that will set these policies. What > kind of meaningful information can be provided to a user about the > differences between p-asserted-id and sip-identity and digest > authentication? What would make a user give permission for one type or > authentication, and not another? Practically speaking, it doesnt seem > like its easy to use at all. > > As a result, I would propose to remove the authentication condition > from xcap-auth. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 1 16:20:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00625 for ; Mon, 1 Dec 2003 16:20:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvTE-0003Bf-Dl for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 16:20:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LKelJ012245 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 16:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvTD-0003BE-Uu for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00542; Mon, 1 Dec 2003 16:20:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvTA-0001e5-00; Mon, 01 Dec 2003 16:20:36 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvT9-0001dU-00; Mon, 01 Dec 2003 16:20:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvSc-00036f-Rp; Mon, 01 Dec 2003 16:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvSI-00035o-Qh for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00459 for ; Mon, 1 Dec 2003 16:19:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvSG-0001ct-00 for simple@ietf.org; Mon, 01 Dec 2003 16:19:40 -0500 Received: from auds953.usa.alcatel.com ([143.209.238.6]) by ietf-mx with esmtp (Exim 4.12) id 1AQvSB-0001bl-00 for simple@ietf.org; Mon, 01 Dec 2003 16:19:35 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hB1LIicb001817; Mon, 1 Dec 2003 15:18:44 -0600 (CST) Message-ID: <3FCBB032.75A7B96A@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Vesa Torvinen (JO/LMF)" CC: "'Jonathan Rosenberg'" , "'Simple WG'" Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 15:18:43 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think being able to decide whether to accept or reject a subscription based on the type of authentication used in the SUBSCRIBE request is useful. That would allow me, for example, to reject clients using a less secure authentication scheme or force them to use a more secure one (e.g. Basic Access Authentication vs Digest Access Authentication). Regards, Alex. "Vesa Torvinen (JO/LMF)" wrote: > Hi, > > [Tried to send something on this before but haven't seen my mail on the list... this is the second try.] > > I think this was originally related to a use case where a policy would define that "anyone that knows the password is allowed to subscribe". The presentity wouldn't exactly be interested in authentication in terms of identities (the watcher could be "anonymous") - just to be sure that all authorized watchers know the password. This use case is similar to the policies currently used in phone conferencing systems, i.e. the participant just needs to know the conference id, and related password - and not really to authenticate himself in terms of real identity. One problem is, of course, that the password should be specific to the presentity, e.g. "realm=alice@domain.com", not to the "realm=domain.com" as a whole. > > There has also been some discussion in 3GPP/SA3 on having an option for using a password based authentication in addition to the P-Asserted-Identity header based "authentication". Not all people like this idea, however, it could provide some additional security for 3GPP IP multimedia subsystem. For example, HTTP Digest AKA (that is used to create the P-Asserted-Identity) does not really authenticate the end-user - it authenticates the subscription/device. > > I agree that forcing the use of S/MIME, TLS or P-Asserted-Identity is not really meaningful. However, having policies that mandate the use of HTTP Digest (or some other password based mechanism) may still be useful. > > Vesa > > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > Folks, > > Currently, xcap-auth defines an authentication condition. This allows > you to decide whether to accept or reject a subscription based on the > type of authentication used in the SUBSCRIBE request. > > The geopriv policy specification currently has no such mechanism. > > This was discussed during the geopriv meeting in Minneapolis. If you > think about it for a bit, its not clear how this would actually get > used. Remember, it is end users that will set these policies. What > kind of meaningful information can be provided to a user about the > differences between p-asserted-id and sip-identity and digest > authentication? What would make a user give permission for one type or > authentication, and not another? Practically speaking, it doesnt seem > like its easy to use at all. > > As a result, I would propose to remove the authentication condition > from xcap-auth. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > 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-admin@ietf.org Mon Dec 1 16:23:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00786; Mon, 1 Dec 2003 16:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWV-0001jK-00; Mon, 01 Dec 2003 16:24:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvWU-0001jH-00; Mon, 01 Dec 2003 16:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWT-0003JE-D8; Mon, 01 Dec 2003 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWL-0003It-LW for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00783 for ; Mon, 1 Dec 2003 16:23:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWJ-0001j1-00 for simple@ietf.org; Mon, 01 Dec 2003 16:23:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWJ-0001iy-00 for simple@ietf.org; Mon, 01 Dec 2003 16:23:51 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1LNnL28190 for ; Mon, 1 Dec 2003 23:23:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Dec 2003 23:23:46 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 23:23:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4UPGkME+vXPDOSI2k6E47B1uj9gAAA72A To: , Cc: , X-OriginalArrivalTime: 01 Dec 2003 21:23:46.0772 (UTC) FILETIME=[67AC6940:01C3B851] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 23:23:46 +0200 Content-Transfer-Encoding: quoted-printable Hi Alex, I think this should be the policy of the presence server (even better, = unauthenticated users should not be passed to one's domain), not set by = each individual user via XCAP. Users don't know anything about "digest" = or "basic", so this would be just another cryptic checkbox in the UI at = best. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Alex Audu > Sent: 01 December, 2003 23:19 > To: Vesa Torvinen (JO/LMF) > Cc: 'Jonathan Rosenberg'; 'Simple WG' > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > I think being able to decide whether to accept or reject a=20 > subscription based on > the type of authentication used in the SUBSCRIBE request is=20 > useful. That would > allow me, for example, to reject clients using a less secure=20 > authentication scheme > or force them to use a more secure one (e.g. Basic Access=20 > Authentication vs > Digest Access Authentication). >=20 > Regards, > Alex. >=20 > "Vesa Torvinen (JO/LMF)" wrote: >=20 > > Hi, > > > > [Tried to send something on this before but haven't seen my=20 > mail on the list... this is the second try.] > > > > I think this was originally related to a use case where a=20 > policy would define that "anyone that knows the password is=20 > allowed to subscribe". The presentity wouldn't exactly be=20 > interested in authentication in terms of identities (the=20 > watcher could be "anonymous") - just to be sure that all=20 > authorized watchers know the password. This use case is=20 > similar to the policies currently used in phone conferencing=20 > systems, i.e. the participant just needs to know the=20 > conference id, and related password - and not really to=20 > authenticate himself in terms of real identity. One problem=20 > is, of course, that the password should be specific to the=20 > presentity, e.g. "realm=3Dalice@domain.com", not to the=20 > "realm=3Ddomain.com" as a whole. > > > > There has also been some discussion in 3GPP/SA3 on having=20 > an option for using a password based authentication in=20 > addition to the P-Asserted-Identity header based=20 > "authentication". Not all people like this idea, however, it=20 > could provide some additional security for 3GPP IP multimedia=20 > subsystem. For example, HTTP Digest AKA (that is used to=20 > create the P-Asserted-Identity) does not really authenticate=20 > the end-user - it authenticates the subscription/device. > > > > I agree that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity is not really meaningful. However, having=20 > policies that mandate the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful. > > > > Vesa > > > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: 24. marraskuuta 2003 8:13 > > To: Simple WG > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > > > Folks, > > > > Currently, xcap-auth defines an authentication condition.=20 > This allows > > you to decide whether to accept or reject a subscription=20 > based on the > > type of authentication used in the SUBSCRIBE request. > > > > The geopriv policy specification currently has no such mechanism. > > > > This was discussed during the geopriv meeting in Minneapolis. If you > > think about it for a bit, its not clear how this would actually get > > used. Remember, it is end users that will set these policies. What > > kind of meaningful information can be provided to a user about the > > differences between p-asserted-id and sip-identity and digest > > authentication? What would make a user give permission for=20 > one type or > > authentication, and not another? Practically speaking, it=20 > doesnt seem > > like its easy to use at all. > > > > As a result, I would propose to remove the authentication condition > > from xcap-auth. > > > > Comments? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 1 16:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00810 for ; Mon, 1 Dec 2003 16:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWX-0003K4-MQ for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 16:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LO5x6012766 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWX-0003Jp-Iq for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:24:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00786; Mon, 1 Dec 2003 16:23:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWV-0001jK-00; Mon, 01 Dec 2003 16:24:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvWU-0001jH-00; Mon, 01 Dec 2003 16:24:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWT-0003JE-D8; Mon, 01 Dec 2003 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvWL-0003It-LW for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00783 for ; Mon, 1 Dec 2003 16:23:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWJ-0001j1-00 for simple@ietf.org; Mon, 01 Dec 2003 16:23:51 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQvWJ-0001iy-00 for simple@ietf.org; Mon, 01 Dec 2003 16:23:51 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1LNnL28190 for ; Mon, 1 Dec 2003 23:23:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Dec 2003 23:23:46 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 23:23:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4UPGkME+vXPDOSI2k6E47B1uj9gAAA72A To: , Cc: , X-OriginalArrivalTime: 01 Dec 2003 21:23:46.0772 (UTC) FILETIME=[67AC6940:01C3B851] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 23:23:46 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Alex, I think this should be the policy of the presence server (even better, = unauthenticated users should not be passed to one's domain), not set by = each individual user via XCAP. Users don't know anything about "digest" = or "basic", so this would be just another cryptic checkbox in the UI at = best. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Alex Audu > Sent: 01 December, 2003 23:19 > To: Vesa Torvinen (JO/LMF) > Cc: 'Jonathan Rosenberg'; 'Simple WG' > Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > I think being able to decide whether to accept or reject a=20 > subscription based on > the type of authentication used in the SUBSCRIBE request is=20 > useful. That would > allow me, for example, to reject clients using a less secure=20 > authentication scheme > or force them to use a more secure one (e.g. Basic Access=20 > Authentication vs > Digest Access Authentication). >=20 > Regards, > Alex. >=20 > "Vesa Torvinen (JO/LMF)" wrote: >=20 > > Hi, > > > > [Tried to send something on this before but haven't seen my=20 > mail on the list... this is the second try.] > > > > I think this was originally related to a use case where a=20 > policy would define that "anyone that knows the password is=20 > allowed to subscribe". The presentity wouldn't exactly be=20 > interested in authentication in terms of identities (the=20 > watcher could be "anonymous") - just to be sure that all=20 > authorized watchers know the password. This use case is=20 > similar to the policies currently used in phone conferencing=20 > systems, i.e. the participant just needs to know the=20 > conference id, and related password - and not really to=20 > authenticate himself in terms of real identity. One problem=20 > is, of course, that the password should be specific to the=20 > presentity, e.g. "realm=3Dalice@domain.com", not to the=20 > "realm=3Ddomain.com" as a whole. > > > > There has also been some discussion in 3GPP/SA3 on having=20 > an option for using a password based authentication in=20 > addition to the P-Asserted-Identity header based=20 > "authentication". Not all people like this idea, however, it=20 > could provide some additional security for 3GPP IP multimedia=20 > subsystem. For example, HTTP Digest AKA (that is used to=20 > create the P-Asserted-Identity) does not really authenticate=20 > the end-user - it authenticates the subscription/device. > > > > I agree that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity is not really meaningful. However, having=20 > policies that mandate the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful. > > > > Vesa > > > > -----Original Message----- > > From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > > Jonathan Rosenberg > > Sent: 24. marraskuuta 2003 8:13 > > To: Simple WG > > Subject: [Simple] xcap/geopriv alignment issue 4: authentication > > > > Folks, > > > > Currently, xcap-auth defines an authentication condition.=20 > This allows > > you to decide whether to accept or reject a subscription=20 > based on the > > type of authentication used in the SUBSCRIBE request. > > > > The geopriv policy specification currently has no such mechanism. > > > > This was discussed during the geopriv meeting in Minneapolis. If you > > think about it for a bit, its not clear how this would actually get > > used. Remember, it is end users that will set these policies. What > > kind of meaningful information can be provided to a user about the > > differences between p-asserted-id and sip-identity and digest > > authentication? What would make a user give permission for=20 > one type or > > authentication, and not another? Practically speaking, it=20 > doesnt seem > > like its easy to use at all. > > > > As a result, I would propose to remove the authentication condition > > from xcap-auth. > > > > Comments? > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ=20 > 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > 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 >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Mon Dec 1 16:28:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01032; Mon, 1 Dec 2003 16:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvbM-0001ov-00; Mon, 01 Dec 2003 16:29:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvbM-0001os-00; Mon, 01 Dec 2003 16:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbJ-0003ZO-WF; Mon, 01 Dec 2003 16:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbC-0003Yj-Bo for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:28:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01017 for ; Mon, 1 Dec 2003 16:28:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvbA-0001oR-00 for simple@ietf.org; Mon, 01 Dec 2003 16:28:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQvb9-0001oO-00 for simple@ietf.org; Mon, 01 Dec 2003 16:28:52 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1LSpg03368 for ; Mon, 1 Dec 2003 23:28:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Dec 2003 23:28:51 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 23:28:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4JaV3ZAjFM2kvSPa3fc+r/MPjLAAK8W5w To: , , X-OriginalArrivalTime: 01 Dec 2003 21:28:51.0245 (UTC) FILETIME=[1D274DD0:01C3B852] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 23:28:50 +0200 Content-Transfer-Encoding: quoted-printable Vesa, I think having a single password for the presentity makes sense as a = feature that someone might actually use. It is definitely more useful in = conferences, which last only for a short period of time, but probably in = some cases for presence too. So I wouldn't be against having this kind = of simple mechanism, as long as we find a nice way to incorporate it = into the XML schema. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Vesa Torvinen (JO/LMF) > Sent: 26 November, 2003 10:48 > To: 'Jonathan Rosenberg'; Simple WG > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi,=20 >=20 > I think this mechanism goes back to a use case where a policy=20 > would define that "anyone that knows this password is allowed=20 > to subscribe". The user wouldn't exactly be interested in=20 > identities - just to be sure that the watcher knows the=20 > password. This use case is similar to the policies currently=20 > used in phone conferencing systems where the caller just=20 > needs to know the conference id, and related password - and=20 > not really to authenticate itself.=20 >=20 > I agree with you that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity may not be meaningful. However, having=20 > policies that mandates the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful.=20 >=20 > Vesa >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition. This allows=20 > you to decide whether to accept or reject a subscription based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 1 16:29:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01086 for ; Mon, 1 Dec 2003 16:29:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbQ-0003c4-3o for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 16:29:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB1LT8k1013885 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 16:29:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbP-0003bs-Bg for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 16:29:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01032; Mon, 1 Dec 2003 16:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvbM-0001ov-00; Mon, 01 Dec 2003 16:29:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQvbM-0001os-00; Mon, 01 Dec 2003 16:29:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbJ-0003ZO-WF; Mon, 01 Dec 2003 16:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQvbC-0003Yj-Bo for simple@optimus.ietf.org; Mon, 01 Dec 2003 16:28:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01017 for ; Mon, 1 Dec 2003 16:28:39 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQvbA-0001oR-00 for simple@ietf.org; Mon, 01 Dec 2003 16:28:52 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AQvb9-0001oO-00 for simple@ietf.org; Mon, 01 Dec 2003 16:28:52 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB1LSpg03368 for ; Mon, 1 Dec 2003 23:28:51 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 1 Dec 2003 23:28:51 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Dec 2003 23:28:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4JaV3ZAjFM2kvSPa3fc+r/MPjLAAK8W5w To: , , X-OriginalArrivalTime: 01 Dec 2003 21:28:51.0245 (UTC) FILETIME=[1D274DD0:01C3B852] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Dec 2003 23:28:50 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Vesa, I think having a single password for the presentity makes sense as a = feature that someone might actually use. It is definitely more useful in = conferences, which last only for a short period of time, but probably in = some cases for presence too. So I wouldn't be against having this kind = of simple mechanism, as long as we find a nice way to incorporate it = into the XML schema. Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Vesa Torvinen (JO/LMF) > Sent: 26 November, 2003 10:48 > To: 'Jonathan Rosenberg'; Simple WG > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi,=20 >=20 > I think this mechanism goes back to a use case where a policy=20 > would define that "anyone that knows this password is allowed=20 > to subscribe". The user wouldn't exactly be interested in=20 > identities - just to be sure that the watcher knows the=20 > password. This use case is similar to the policies currently=20 > used in phone conferencing systems where the caller just=20 > needs to know the conference id, and related password - and=20 > not really to authenticate itself.=20 >=20 > I agree with you that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity may not be meaningful. However, having=20 > policies that mandates the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful.=20 >=20 > Vesa >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition. This allows=20 > you to decide whether to accept or reject a subscription based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 1 19:33:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14174; Mon, 1 Dec 2003 19:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQyUU-0006Wz-00; Mon, 01 Dec 2003 19:34:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQyUU-0006Ww-00; Mon, 01 Dec 2003 19:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyUL-0007ii-Mp; Mon, 01 Dec 2003 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyTu-0007gc-7D for simple@optimus.ietf.org; Mon, 01 Dec 2003 19:33:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14142 for ; Mon, 1 Dec 2003 19:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQyTs-0006WB-00 for simple@ietf.org; Mon, 01 Dec 2003 19:33:32 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQyTs-0006VR-00 for simple@ietf.org; Mon, 01 Dec 2003 19:33:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 16:35:49 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB20Wxjq005797; Mon, 1 Dec 2003 16:33:00 -0800 (PST) Received: from [142.131.37.145] (sjc-vpn4-418.cisco.com [10.21.81.162]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKJ18576; Mon, 1 Dec 2003 16:32:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MS(r)P: Reconnect issue From: Cullen Jennings To: Ben Campbell , Simple WG Message-ID: In-Reply-To: <3FCB929A.4060703@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 16:32:56 -0800 Content-Transfer-Encoding: 7bit Requiring S/MIME is definitely not the right path. I lean towards using a reinvite. Cullen PS. I think temporary loss of 802.1x while walking down the hallway will occur more often than the saber tooth tigers eating my fiber :-) On 12/1/03 11:12 AM, "Ben Campbell" wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > > Thoughts? Have I missed an option? > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 1 19:34:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14197 for ; Mon, 1 Dec 2003 19:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyUW-0007jZ-Nm for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 19:34:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB20YCDH029728 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 19:34:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyUW-0007jP-Iw for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 19:34:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14174; Mon, 1 Dec 2003 19:33:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQyUU-0006Wz-00; Mon, 01 Dec 2003 19:34:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQyUU-0006Ww-00; Mon, 01 Dec 2003 19:34:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyUL-0007ii-Mp; Mon, 01 Dec 2003 19:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQyTu-0007gc-7D for simple@optimus.ietf.org; Mon, 01 Dec 2003 19:33:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14142 for ; Mon, 1 Dec 2003 19:33:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQyTs-0006WB-00 for simple@ietf.org; Mon, 01 Dec 2003 19:33:32 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQyTs-0006VR-00 for simple@ietf.org; Mon, 01 Dec 2003 19:33:32 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 16:35:49 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hB20Wxjq005797; Mon, 1 Dec 2003 16:33:00 -0800 (PST) Received: from [142.131.37.145] (sjc-vpn4-418.cisco.com [10.21.81.162]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKJ18576; Mon, 1 Dec 2003 16:32:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Subject: Re: [Simple] MS(r)P: Reconnect issue From: Cullen Jennings To: Ben Campbell , Simple WG Message-ID: In-Reply-To: <3FCB929A.4060703@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 16:32:56 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Requiring S/MIME is definitely not the right path. I lean towards using a reinvite. Cullen PS. I think temporary loss of 802.1x while walking down the hallway will occur more often than the saber tooth tigers eating my fiber :-) On 12/1/03 11:12 AM, "Ben Campbell" wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > > Thoughts? Have I missed an option? > > > _______________________________________________ > 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-admin@ietf.org Mon Dec 1 22:41:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18586; Mon, 1 Dec 2003 22:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR1PU-0000WS-00; Mon, 01 Dec 2003 22:41:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR1PU-0000WP-00; Mon, 01 Dec 2003 22:41:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1PK-0007rj-8P; Mon, 01 Dec 2003 22:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1P7-0007rE-C9 for simple@optimus.ietf.org; Mon, 01 Dec 2003 22:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18580 for ; Mon, 1 Dec 2003 22:40:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR1P3-0000WD-00 for simple@ietf.org; Mon, 01 Dec 2003 22:40:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AR1P2-0000W7-00 for simple@ietf.org; Mon, 01 Dec 2003 22:40:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB23eQnG021360; Mon, 1 Dec 2003 21:40:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCC0996.1020909@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen CC: Simple WG Subject: Re: [Simple] Re: MS(r)P: Reconnect issue References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 21:40:06 -0600 Content-Transfer-Encoding: 7bit Andrew Allen wrote: > Ben > > Ben, > > If Option 2 requires end-to-end encryption of the SDP to protect the URL > then it is not going to be suitable for use by 3GPP for message sessions > at the present time. The 3GPP network currently needs to examine the SDP > to perform authorization and allocation of radio resources for the > session. A possible alternative is the use of the SIPS scheme, where the device that must inspect the SDP is a participant in one of the TLS handshakes--and therefore can see the contents. But I must admit that approach feels a little spooky. > > In the wireless case the chances of dropped connections are probably a > lot higher with the mobile potentially moving in and out of coverage > (especially if going through tunnels on a train) so this is likely to be > a more common scenario in wireless. > > What were the main objections to re-invitation as a solution? > The objection was that such TCP drops happen alot, and people wanted the lightest weight recovery possible. If a simple TCP reconnect would work, it would be nice--but I don't think it will work. > Why not use UPDATE to attempt to re-establish connections in the case > when the dialog still exists? UPDATE is less expensive in terms of SIP > messages to re-establish (no ACK required). In the 3GPP case the sending > of a SIP request is likely to trigger a network initiated termination of > the session (a BYE) if the mobile is still out of coverage, which I > expect is what is desired in the wireless case to release the network > resources. If we establish that we must use a new SDP exchange, then I expect UPDATE and reinvites to both be applicable, depending on the particular circumstance. > > Andrew > > > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, December 01, 2003 2:54 PM >>To: Ben Campbell >>Cc: Simple WG >>Subject: [Simple] Re: MS(r)P: Reconnect issue >> >>Oops, got my options mixed up. See clarification below. >> >>Ben Campbell wrote: >> >> >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>>rename) should allow reconnection of dropped TCP connections without >>>requiring a new offer/answer. In that meeting, I mentioned that > > there > >>>was a reason we had originally chose not to allow that, but I could > > not > >>>remember the details at the time. Having slept since then, I now >> >>remember: >> >>>Consider a visitor V has a TCP connection to a host H, with an > > active > >>>session. That TCP connection is then dropped due to something in the >>>network. I don't know why, maybe a stateful firewall dropped state, > > or a > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > any > >>>case, the connection is dropped without a proper FIN handshake at > > the > >>>endpoints. >>> >>>It may take each endpoint sometime to actually notice that this has >>>occurred. Using common TCP state machine defaults, it will typically >>>take just under 10 minutes. It is also likely that the participants > > will > >>>not figure it out at the same time. >>> >>>If H figures it out first, then things are reasonable ok. It just > > waits > >>>some period of time for V to notice, reconnect, and send a VISIT > > with > >>>the session URI. >>> >>>But if V figures it out first, we have a problem. V will reconnect, > > and > >>>attempt a VISIT with the session URI. The problem is, H thinks it >>>already has a perfectly good connection for that session. It has two >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > still > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > request > >>>on the new connection. >>> >>>Option 1 is the currently defined behavior. It seems pretty obvious > > that > >>>this pretty much prevents reconnections. Option 2 would allow >>>reconnections, but it allows a really nasty session hijacking attack > > if > >>>an attacker happens to learn the session URI. >>> >>>I discussed this with several people a while back, and the consensus >>>seemed to be that option 2 was not feasible, so we had to require a > > new > >>>sdp exchange with a new session URI in order to reconnect. >> >> > >> >>>Option 1 _might_ be acceptable if we could guarantee the > > confidentiality > >>>of the session URI. If we were to accept option 1, we would then > > have a > >>>strong reason to _require_ the sdp exchange be protected by using > > either > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > also > >>>requires the host to listen for new connections pretty much forever, >>>which is not particularly pleasant. >>> >> >>For the above paragraph, I meant option 2. My apologies if anyone hurt >>their brain trying to figure out how that paragraph applied to option > > 1. > >> >>>Thoughts? Have I missed an option? >>> >> >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Mon Dec 1 22:41:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18631 for ; Mon, 1 Dec 2003 22:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1PY-0007su-K6 for simple-archive@odin.ietf.org; Mon, 01 Dec 2003 22:41:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB23fGpl030302 for simple-archive@odin.ietf.org; Mon, 1 Dec 2003 22:41:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1PY-0007sf-FB for simple-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 22:41:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18586; Mon, 1 Dec 2003 22:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR1PU-0000WS-00; Mon, 01 Dec 2003 22:41:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR1PU-0000WP-00; Mon, 01 Dec 2003 22:41:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1PK-0007rj-8P; Mon, 01 Dec 2003 22:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR1P7-0007rE-C9 for simple@optimus.ietf.org; Mon, 01 Dec 2003 22:40:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18580 for ; Mon, 1 Dec 2003 22:40:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR1P3-0000WD-00 for simple@ietf.org; Mon, 01 Dec 2003 22:40:45 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AR1P2-0000W7-00 for simple@ietf.org; Mon, 01 Dec 2003 22:40:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB23eQnG021360; Mon, 1 Dec 2003 21:40:37 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCC0996.1020909@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen CC: Simple WG Subject: Re: [Simple] Re: MS(r)P: Reconnect issue References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 01 Dec 2003 21:40:06 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andrew Allen wrote: > Ben > > Ben, > > If Option 2 requires end-to-end encryption of the SDP to protect the URL > then it is not going to be suitable for use by 3GPP for message sessions > at the present time. The 3GPP network currently needs to examine the SDP > to perform authorization and allocation of radio resources for the > session. A possible alternative is the use of the SIPS scheme, where the device that must inspect the SDP is a participant in one of the TLS handshakes--and therefore can see the contents. But I must admit that approach feels a little spooky. > > In the wireless case the chances of dropped connections are probably a > lot higher with the mobile potentially moving in and out of coverage > (especially if going through tunnels on a train) so this is likely to be > a more common scenario in wireless. > > What were the main objections to re-invitation as a solution? > The objection was that such TCP drops happen alot, and people wanted the lightest weight recovery possible. If a simple TCP reconnect would work, it would be nice--but I don't think it will work. > Why not use UPDATE to attempt to re-establish connections in the case > when the dialog still exists? UPDATE is less expensive in terms of SIP > messages to re-establish (no ACK required). In the 3GPP case the sending > of a SIP request is likely to trigger a network initiated termination of > the session (a BYE) if the mobile is still out of coverage, which I > expect is what is desired in the wireless case to release the network > resources. If we establish that we must use a new SDP exchange, then I expect UPDATE and reinvites to both be applicable, depending on the particular circumstance. > > Andrew > > > > >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, December 01, 2003 2:54 PM >>To: Ben Campbell >>Cc: Simple WG >>Subject: [Simple] Re: MS(r)P: Reconnect issue >> >>Oops, got my options mixed up. See clarification below. >> >>Ben Campbell wrote: >> >> >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>>rename) should allow reconnection of dropped TCP connections without >>>requiring a new offer/answer. In that meeting, I mentioned that > > there > >>>was a reason we had originally chose not to allow that, but I could > > not > >>>remember the details at the time. Having slept since then, I now >> >>remember: >> >>>Consider a visitor V has a TCP connection to a host H, with an > > active > >>>session. That TCP connection is then dropped due to something in the >>>network. I don't know why, maybe a stateful firewall dropped state, > > or a > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > any > >>>case, the connection is dropped without a proper FIN handshake at > > the > >>>endpoints. >>> >>>It may take each endpoint sometime to actually notice that this has >>>occurred. Using common TCP state machine defaults, it will typically >>>take just under 10 minutes. It is also likely that the participants > > will > >>>not figure it out at the same time. >>> >>>If H figures it out first, then things are reasonable ok. It just > > waits > >>>some period of time for V to notice, reconnect, and send a VISIT > > with > >>>the session URI. >>> >>>But if V figures it out first, we have a problem. V will reconnect, > > and > >>>attempt a VISIT with the session URI. The problem is, H thinks it >>>already has a perfectly good connection for that session. It has two >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > still > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > request > >>>on the new connection. >>> >>>Option 1 is the currently defined behavior. It seems pretty obvious > > that > >>>this pretty much prevents reconnections. Option 2 would allow >>>reconnections, but it allows a really nasty session hijacking attack > > if > >>>an attacker happens to learn the session URI. >>> >>>I discussed this with several people a while back, and the consensus >>>seemed to be that option 2 was not feasible, so we had to require a > > new > >>>sdp exchange with a new session URI in order to reconnect. >> >> > >> >>>Option 1 _might_ be acceptable if we could guarantee the > > confidentiality > >>>of the session URI. If we were to accept option 1, we would then > > have a > >>>strong reason to _require_ the sdp exchange be protected by using > > either > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > also > >>>requires the host to listen for new connections pretty much forever, >>>which is not particularly pleasant. >>> >> >>For the above paragraph, I meant option 2. My apologies if anyone hurt >>their brain trying to figure out how that paragraph applied to option > > 1. > >> >>>Thoughts? Have I missed an option? >>> >> >> >> >>_______________________________________________ >>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-admin@ietf.org Tue Dec 2 02:28:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06292; Tue, 2 Dec 2003 02:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4xG-0002dp-00; Tue, 02 Dec 2003 02:28:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR4xF-0002dm-00; Tue, 02 Dec 2003 02:28:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4wz-00078q-No; Tue, 02 Dec 2003 02:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4we-00077p-8x for simple@optimus.ietf.org; Tue, 02 Dec 2003 02:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06282 for ; Tue, 2 Dec 2003 02:27:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4wa-0002da-00 for simple@ietf.org; Tue, 02 Dec 2003 02:27:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AR4wa-0002dJ-00 for simple@ietf.org; Tue, 02 Dec 2003 02:27:36 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB27RAca025437; Tue, 2 Dec 2003 02:27:11 -0500 (EST) Message-ID: <3FCC3EC3.8070903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment, issue References: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 02:26:59 -0500 Content-Transfer-Encoding: 7bit Indeed, this is exactly the goal I am working towards. In the slides I made for the simple meeting, I had a slide on how the document structure would work. I didn't get to it because we ran out of time, but it was as you describe. I wanted to get to this point, however, by considering the pros/cons of each change on their own merit. -Jonathan R. hisham.khartabil@nokia.com wrote: > Since we are mirroring a lot of geopriv's schema; I have a > suggestion: > > Why don't we define a common schema for both using one xml > namespace. It can have all the needed elements like , > , etc. > > xcap-auth specific elements can then be specified as extensions > defined. Geopriv can do the same with their specific elements. > > Regards, Hisham > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 02:28:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06308 for ; Tue, 2 Dec 2003 02:28:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4xL-00079u-9U for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 02:28:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB27SN0v027512 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 02:28:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4xL-00079f-1v for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 02:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06292; Tue, 2 Dec 2003 02:28:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4xG-0002dp-00; Tue, 02 Dec 2003 02:28:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR4xF-0002dm-00; Tue, 02 Dec 2003 02:28:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4wz-00078q-No; Tue, 02 Dec 2003 02:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR4we-00077p-8x for simple@optimus.ietf.org; Tue, 02 Dec 2003 02:27:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06282 for ; Tue, 2 Dec 2003 02:27:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR4wa-0002da-00 for simple@ietf.org; Tue, 02 Dec 2003 02:27:36 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AR4wa-0002dJ-00 for simple@ietf.org; Tue, 02 Dec 2003 02:27:36 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB27RAca025437; Tue, 2 Dec 2003 02:27:11 -0500 (EST) Message-ID: <3FCC3EC3.8070903@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment, issue References: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B104@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 02:26:59 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Indeed, this is exactly the goal I am working towards. In the slides I made for the simple meeting, I had a slide on how the document structure would work. I didn't get to it because we ran out of time, but it was as you describe. I wanted to get to this point, however, by considering the pros/cons of each change on their own merit. -Jonathan R. hisham.khartabil@nokia.com wrote: > Since we are mirroring a lot of geopriv's schema; I have a > suggestion: > > Why don't we define a common schema for both using one xml > namespace. It can have all the needed elements like , > , etc. > > xcap-auth specific elements can then be specified as extensions > defined. Geopriv can do the same with their specific elements. > > Regards, Hisham > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 03:03:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07550; Tue, 2 Dec 2003 03:03:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5VI-0003CR-00; Tue, 02 Dec 2003 03:03:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR5Ux-0003B2-00; Tue, 02 Dec 2003 03:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5Us-0000yF-VY; Tue, 02 Dec 2003 03:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5U4-0000uv-WB for simple@optimus.ietf.org; Tue, 02 Dec 2003 03:02:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07404; Tue, 2 Dec 2003 03:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5U0-00037w-00; Tue, 02 Dec 2003 03:02:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AR5Tz-00036J-00; Tue, 02 Dec 2003 03:02:07 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB281hca025460; Tue, 2 Dec 2003 03:01:43 -0500 (EST) Message-ID: <3FCC46DB.3050005@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Simple WG , "'geopriv@ietf.org'" References: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Supported Permissions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 03:01:31 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > Hi Jonathan, Hi all, > > in section 5 of the xcap-authz draft so-called "supported > permissions" are described. if i understood them correctly then > their purpose is to allow the entity which creates the rules to > dynamically determine the current version of the xcap-authz > policies (i.e., which xml attributes are understood by the server). Right. The main reason is for a single client to be able to be used against multiple service providers. > > > it is certainly important to think about extensibility of the > authorization policies. in geopriv we have also thought a little > about these issues. have you thought about other mechanisms for > determining the version? maybe there are simpler mechanisms. There has not been much discussion on alternate mechanisms. > > looking at the example in section 5.6 i had the impression that you > also combine the authorization policies with the actual data. i > think that some information is missing in the xml schema (and in > the example) to be complete. in any case i think that they should > be separated. please correct me if i misunderstood your intention. The way I designed the schema for this is that the supported permissions are declared by including a valid statement that includes all of the supported permissions. In order to be valid, the statement has to include values for some of the attributes (for example, show-element). However, the value is irrelevant. Thinking about this some more, perhaps a better way to do it is like this: namespace1 namespace2 100 1 In other words, elements are defined for each of the data types supported (integer, boolean, enumerated token list). The actual permission is included as the value of an attribute. We could also include constraints, such as the set of supported values for a token list, or a range for an integer. What do folks think of this? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 03:03:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07624 for ; Tue, 2 Dec 2003 03:03:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5VO-000163-Lk for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 03:03:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB283YMT004211 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 03:03:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5VO-00015p-32 for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 03:03:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07550; Tue, 2 Dec 2003 03:03:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5VI-0003CR-00; Tue, 02 Dec 2003 03:03:28 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR5Ux-0003B2-00; Tue, 02 Dec 2003 03:03:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5Us-0000yF-VY; Tue, 02 Dec 2003 03:03:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR5U4-0000uv-WB for simple@optimus.ietf.org; Tue, 02 Dec 2003 03:02:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07404; Tue, 2 Dec 2003 03:01:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR5U0-00037w-00; Tue, 02 Dec 2003 03:02:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AR5Tz-00036J-00; Tue, 02 Dec 2003 03:02:07 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB281hca025460; Tue, 2 Dec 2003 03:01:43 -0500 (EST) Message-ID: <3FCC46DB.3050005@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Simple WG , "'geopriv@ietf.org'" References: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0489@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Supported Permissions Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 03:01:31 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > Hi Jonathan, Hi all, > > in section 5 of the xcap-authz draft so-called "supported > permissions" are described. if i understood them correctly then > their purpose is to allow the entity which creates the rules to > dynamically determine the current version of the xcap-authz > policies (i.e., which xml attributes are understood by the server). Right. The main reason is for a single client to be able to be used against multiple service providers. > > > it is certainly important to think about extensibility of the > authorization policies. in geopriv we have also thought a little > about these issues. have you thought about other mechanisms for > determining the version? maybe there are simpler mechanisms. There has not been much discussion on alternate mechanisms. > > looking at the example in section 5.6 i had the impression that you > also combine the authorization policies with the actual data. i > think that some information is missing in the xml schema (and in > the example) to be complete. in any case i think that they should > be separated. please correct me if i misunderstood your intention. The way I designed the schema for this is that the supported permissions are declared by including a valid statement that includes all of the supported permissions. In order to be valid, the statement has to include values for some of the attributes (for example, show-element). However, the value is irrelevant. Thinking about this some more, perhaps a better way to do it is like this: namespace1 namespace2 100 1 In other words, elements are defined for each of the data types supported (integer, boolean, enumerated token list). The actual permission is included as the value of an attribute. We could also include constraints, such as the set of supported values for a token list, or a range for an integer. What do folks think of this? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 03:51:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08624; Tue, 2 Dec 2003 03:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6GL-0003fh-00; Tue, 02 Dec 2003 03:52:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6GK-0003fe-00; Tue, 02 Dec 2003 03:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GH-0003Vx-Hi; Tue, 02 Dec 2003 03:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6FW-0003V5-Ud for simple@optimus.ietf.org; Tue, 02 Dec 2003 03:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08611 for ; Tue, 2 Dec 2003 03:51:01 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6FU-0003fF-00 for simple@ietf.org; Tue, 02 Dec 2003 03:51:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR6FT-0003fC-00 for simple@ietf.org; Tue, 02 Dec 2003 03:51:11 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB28pBQ14221 for ; Tue, 2 Dec 2003 10:51:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 10:51:11 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 10:51:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4JaV4H/8j6yQeQu2IE8d9QEHnSQAijZow To: , , X-OriginalArrivalTime: 02 Dec 2003 08:51:11.0165 (UTC) FILETIME=[6F3F56D0:01C3B8B1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 10:51:10 +0200 Content-Transfer-Encoding: quoted-printable Hi Vesa, First of all, I don't like the single password scheme because of two = things. Distributing the key is a pain, and the more people you deliver = it to, the weaker it gets. When you stop being friends with one of those = people, re-keying is an even bigger pain. Secondly, on the client side, = I'd say this is even worse. If I have 500 buddies in my presence = application, I most certainly don't want to (manually) manage 500 = passwords, perhaps randomly delivered to me via email/IM/SMS. When I = switch on my handset, I don't want to spend time typing in digest = passwords, etc. So I just don't think this scales enough to make it a = useful functionality in a presence system. But more importantly, I think this introduces authentication mechanisms = into XCAP policies the same way enumerating the used authentication = mechanism (as in S/MIME, TLS, P-A-ID, etc.) does. This time, you need to = specify, that a specific policy pertains to a digest username, not an = identity delivered in a From field of a SUBSCRIBE. Users don't = understand much about digest usernames, or at least don't know how to = differentiate between this and the person's SIP ID, and this coupled = with the problematics related to managing passwords, I think this just = gets too complicated. Cheers, Aki > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext Vesa Torvinen (JO/LMF) > Sent: 26 November, 2003 10:48 > To: 'Jonathan Rosenberg'; Simple WG > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi,=20 >=20 > I think this mechanism goes back to a use case where a=20 > policy would define that "anyone that knows this password is=20 > allowed to subscribe". The user wouldn't exactly be=20 > interested in identities - just to be sure that the watcher=20 > knows the password. This use case is similar to the policies=20 > currently used in phone conferencing systems where the=20 > caller just needs to know the conference id, and related=20 > password - and not really to authenticate itself.=20 >=20 > I agree with you that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity may not be meaningful. However, having=20 > policies that mandates the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful.=20 >=20 > Vesa >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition.=20 > This allows=20 > you to decide whether to accept or reject a subscription=20 > based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it=20 > doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 03:52:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08658 for ; Tue, 2 Dec 2003 03:52:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GO-0003Xo-GZ for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 03:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28q86U013616 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 03:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GO-0003XX-AU for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 03:52:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08624; Tue, 2 Dec 2003 03:51:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6GL-0003fh-00; Tue, 02 Dec 2003 03:52:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6GK-0003fe-00; Tue, 02 Dec 2003 03:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GH-0003Vx-Hi; Tue, 02 Dec 2003 03:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6FW-0003V5-Ud for simple@optimus.ietf.org; Tue, 02 Dec 2003 03:51:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08611 for ; Tue, 2 Dec 2003 03:51:01 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6FU-0003fF-00 for simple@ietf.org; Tue, 02 Dec 2003 03:51:12 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR6FT-0003fC-00 for simple@ietf.org; Tue, 02 Dec 2003 03:51:11 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB28pBQ14221 for ; Tue, 2 Dec 2003 10:51:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 10:51:11 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 10:51:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 4: authentication Thread-Index: AcO4JaV4H/8j6yQeQu2IE8d9QEHnSQAijZow To: , , X-OriginalArrivalTime: 02 Dec 2003 08:51:11.0165 (UTC) FILETIME=[6F3F56D0:01C3B8B1] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 10:51:10 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vesa, First of all, I don't like the single password scheme because of two = things. Distributing the key is a pain, and the more people you deliver = it to, the weaker it gets. When you stop being friends with one of those = people, re-keying is an even bigger pain. Secondly, on the client side, = I'd say this is even worse. If I have 500 buddies in my presence = application, I most certainly don't want to (manually) manage 500 = passwords, perhaps randomly delivered to me via email/IM/SMS. When I = switch on my handset, I don't want to spend time typing in digest = passwords, etc. So I just don't think this scales enough to make it a = useful functionality in a presence system. But more importantly, I think this introduces authentication mechanisms = into XCAP policies the same way enumerating the used authentication = mechanism (as in S/MIME, TLS, P-A-ID, etc.) does. This time, you need to = specify, that a specific policy pertains to a digest username, not an = identity delivered in a From field of a SUBSCRIBE. Users don't = understand much about digest usernames, or at least don't know how to = differentiate between this and the person's SIP ID, and this coupled = with the problematics related to managing passwords, I think this just = gets too complicated. Cheers, Aki > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext Vesa Torvinen (JO/LMF) > Sent: 26 November, 2003 10:48 > To: 'Jonathan Rosenberg'; Simple WG > Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Hi,=20 >=20 > I think this mechanism goes back to a use case where a=20 > policy would define that "anyone that knows this password is=20 > allowed to subscribe". The user wouldn't exactly be=20 > interested in identities - just to be sure that the watcher=20 > knows the password. This use case is similar to the policies=20 > currently used in phone conferencing systems where the=20 > caller just needs to know the conference id, and related=20 > password - and not really to authenticate itself.=20 >=20 > I agree with you that forcing the use of S/MIME, TLS or=20 > P-Asserted-Identity may not be meaningful. However, having=20 > policies that mandates the use of HTTP Digest (or some other=20 > password based mechanism) may still be useful.=20 >=20 > Vesa >=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > Jonathan Rosenberg > Sent: 24. marraskuuta 2003 8:13 > To: Simple WG > Subject: [Simple] xcap/geopriv alignment issue 4: authentication >=20 >=20 > Folks, >=20 > Currently, xcap-auth defines an authentication condition.=20 > This allows=20 > you to decide whether to accept or reject a subscription=20 > based on the=20 > type of authentication used in the SUBSCRIBE request. >=20 > The geopriv policy specification currently has no such mechanism. >=20 > This was discussed during the geopriv meeting in Minneapolis. If you=20 > think about it for a bit, its not clear how this would actually get=20 > used. Remember, it is end users that will set these policies. What=20 > kind of meaningful information can be provided to a user about the=20 > differences between p-asserted-id and sip-identity and digest=20 > authentication? What would make a user give permission for=20 > one type or=20 > authentication, and not another? Practically speaking, it=20 > doesnt seem=20 > like its easy to use at all. >=20 > As a result, I would propose to remove the authentication condition=20 > from xcap-auth. >=20 > Comments? >=20 > -Jonathan R. > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com >=20 >=20 >=20 > _______________________________________________ > 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 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 04:13:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09266; Tue, 2 Dec 2003 04:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ba-0003vY-00; Tue, 02 Dec 2003 04:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6ba-0003vV-00; Tue, 02 Dec 2003 04:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6bZ-0004pY-J3; Tue, 02 Dec 2003 04:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6af-0004oW-Ul for simple@optimus.ietf.org; Tue, 02 Dec 2003 04:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09245 for ; Tue, 2 Dec 2003 04:12:52 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ac-0003uu-00 for simple@ietf.org; Tue, 02 Dec 2003 04:13:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ac-0003ur-00 for simple@ietf.org; Tue, 02 Dec 2003 04:13:02 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB29D3s19136 for ; Tue, 2 Dec 2003 11:13:03 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 11:13:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:13:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MS(r)P: Reconnect issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MS(r)P: Reconnect issue Thread-Index: AcO4P1PeM5A0AurgRK2jD7/zl27qwwAdNFFA To: , X-OriginalArrivalTime: 02 Dec 2003 09:13:02.0865 (UTC) FILETIME=[7D14E010:01C3B8B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 11:13:02 +0200 Content-Transfer-Encoding: quoted-printable Here is another reason I gave in an earlier discussion: One endpoint might crash and reboot. Ports might change so you need to = re-signal. BTW, I don't believe we had consensus in Minneapolis. In any case, I = think re-signalling is needed. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 01.December.2003 21:12 > To: Simple WG > Subject: [Simple] MS(r)P: Reconnect issue >=20 >=20 > In Minneapolis, the wg expressed a consensus that MS(r)P (pending=20 > rename) should allow reconnection of dropped TCP connections without=20 > requiring a new offer/answer. In that meeting, I mentioned that there=20 > was a reason we had originally chose not to allow that, but I=20 > could not=20 > remember the details at the time. Having slept since then, I=20 > now remember: >=20 > Consider a visitor V has a TCP connection to a host H, with an active=20 > session. That TCP connection is then dropped due to something in the=20 > network. I don't know why, maybe a stateful firewall dropped=20 > state, or a=20 > length of fiber was accidentally eaten by a sabre-tooth tiger. In any=20 > case, the connection is dropped without a proper FIN handshake at the=20 > endpoints. >=20 > It may take each endpoint sometime to actually notice that this has=20 > occurred. Using common TCP state machine defaults, it will typically=20 > take just under 10 minutes. It is also likely that the=20 > participants will=20 > not figure it out at the same time. >=20 > If H figures it out first, then things are reasonable ok. It=20 > just waits=20 > some period of time for V to notice, reconnect, and send a VISIT with=20 > the session URI. >=20 > But if V figures it out first, we have a problem. V will=20 > reconnect, and=20 > attempt a VISIT with the session URI. The problem is, H thinks it=20 > already has a perfectly good connection for that session. It has two=20 > possible choices: 1) Fail the new VISIT, and assume the old=20 > one is still=20 > good, or 2) Disconnect the old connection, and accept the=20 > VISIT request=20 > on the new connection. >=20 > Option 1 is the currently defined behavior. It seems pretty=20 > obvious that=20 > this pretty much prevents reconnections. Option 2 would allow=20 > reconnections, but it allows a really nasty session hijacking=20 > attack if=20 > an attacker happens to learn the session URI. >=20 > I discussed this with several people a while back, and the consensus=20 > seemed to be that option 2 was not feasible, so we had to=20 > require a new=20 > sdp exchange with a new session URI in order to reconnect. >=20 > Option 1 _might_ be acceptable if we could guarantee the=20 > confidentiality=20 > of the session URI. If we were to accept option 1, we would=20 > then have a=20 > strong reason to _require_ the sdp exchange be protected by=20 > using either=20 > SIPS or e2e crypto, and that the VISIT be sent over TLS.=20 > Option 1 also=20 > requires the host to listen for new connections pretty much forever,=20 > which is not particularly pleasant. >=20 > Thoughts? Have I missed an option? >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Tue Dec 2 04:14:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09286 for ; Tue, 2 Dec 2003 04:14:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6be-0004qS-CE for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 04:14:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB29E6k0018618 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 04:14:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6be-0004qD-4Q for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 04:14:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09266; Tue, 2 Dec 2003 04:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ba-0003vY-00; Tue, 02 Dec 2003 04:14:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6ba-0003vV-00; Tue, 02 Dec 2003 04:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6bZ-0004pY-J3; Tue, 02 Dec 2003 04:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6af-0004oW-Ul for simple@optimus.ietf.org; Tue, 02 Dec 2003 04:13:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09245 for ; Tue, 2 Dec 2003 04:12:52 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ac-0003uu-00 for simple@ietf.org; Tue, 02 Dec 2003 04:13:03 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AR6ac-0003ur-00 for simple@ietf.org; Tue, 02 Dec 2003 04:13:02 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB29D3s19136 for ; Tue, 2 Dec 2003 11:13:03 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Dec 2003 11:13:03 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Dec 2003 11:13:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MS(r)P: Reconnect issue Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MS(r)P: Reconnect issue Thread-Index: AcO4P1PeM5A0AurgRK2jD7/zl27qwwAdNFFA To: , X-OriginalArrivalTime: 02 Dec 2003 09:13:02.0865 (UTC) FILETIME=[7D14E010:01C3B8B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 11:13:02 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Here is another reason I gave in an earlier discussion: One endpoint might crash and reboot. Ports might change so you need to = re-signal. BTW, I don't believe we had consensus in Minneapolis. In any case, I = think re-signalling is needed. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 01.December.2003 21:12 > To: Simple WG > Subject: [Simple] MS(r)P: Reconnect issue >=20 >=20 > In Minneapolis, the wg expressed a consensus that MS(r)P (pending=20 > rename) should allow reconnection of dropped TCP connections without=20 > requiring a new offer/answer. In that meeting, I mentioned that there=20 > was a reason we had originally chose not to allow that, but I=20 > could not=20 > remember the details at the time. Having slept since then, I=20 > now remember: >=20 > Consider a visitor V has a TCP connection to a host H, with an active=20 > session. That TCP connection is then dropped due to something in the=20 > network. I don't know why, maybe a stateful firewall dropped=20 > state, or a=20 > length of fiber was accidentally eaten by a sabre-tooth tiger. In any=20 > case, the connection is dropped without a proper FIN handshake at the=20 > endpoints. >=20 > It may take each endpoint sometime to actually notice that this has=20 > occurred. Using common TCP state machine defaults, it will typically=20 > take just under 10 minutes. It is also likely that the=20 > participants will=20 > not figure it out at the same time. >=20 > If H figures it out first, then things are reasonable ok. It=20 > just waits=20 > some period of time for V to notice, reconnect, and send a VISIT with=20 > the session URI. >=20 > But if V figures it out first, we have a problem. V will=20 > reconnect, and=20 > attempt a VISIT with the session URI. The problem is, H thinks it=20 > already has a perfectly good connection for that session. It has two=20 > possible choices: 1) Fail the new VISIT, and assume the old=20 > one is still=20 > good, or 2) Disconnect the old connection, and accept the=20 > VISIT request=20 > on the new connection. >=20 > Option 1 is the currently defined behavior. It seems pretty=20 > obvious that=20 > this pretty much prevents reconnections. Option 2 would allow=20 > reconnections, but it allows a really nasty session hijacking=20 > attack if=20 > an attacker happens to learn the session URI. >=20 > I discussed this with several people a while back, and the consensus=20 > seemed to be that option 2 was not feasible, so we had to=20 > require a new=20 > sdp exchange with a new session URI in order to reconnect. >=20 > Option 1 _might_ be acceptable if we could guarantee the=20 > confidentiality=20 > of the session URI. If we were to accept option 1, we would=20 > then have a=20 > strong reason to _require_ the sdp exchange be protected by=20 > using either=20 > SIPS or e2e crypto, and that the VISIT be sent over TLS.=20 > Option 1 also=20 > requires the host to listen for new connections pretty much forever,=20 > which is not particularly pleasant. >=20 > Thoughts? Have I missed an option? >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Tue Dec 2 05:13:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10540; Tue, 2 Dec 2003 05:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Xl-0004Sg-00; Tue, 02 Dec 2003 05:14:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Xl-0004Sd-00; Tue, 02 Dec 2003 05:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Xf-0007JE-FJ; Tue, 02 Dec 2003 05:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Wk-0007IG-Iv for simple@optimus.ietf.org; Tue, 02 Dec 2003 05:13:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10527 for ; Tue, 2 Dec 2003 05:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Wh-0004S3-00 for simple@ietf.org; Tue, 02 Dec 2003 05:13:03 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1AR7Wg-0004Ro-00 for simple@ietf.org; Tue, 02 Dec 2003 05:13:02 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-5.tower-49.messagelabs.com!1070359947!528448 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 23526 invoked from network); 2 Dec 2003 10:12:27 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-5.tower-49.messagelabs.com with SMTP; 2 Dec 2003 10:12:27 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Tue, 2 Dec 2003 10:15:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] MS(r)P: Reconnect issue Message-ID: <45730E094814E44488F789C1CDED27AE0219B132@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MS(r)P: Reconnect issue Thread-Index: AcO4P1PeM5A0AurgRK2jD7/zl27qwwAdNFFAAAHv2bA= From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 10:11:41 -0000 Content-Transfer-Encoding: quoted-printable I'm=20also=20in=20the=20re-signaling=20camp.=20=20It=20seems=20a=20far=20m= ore=20elegant=20solution compared=20to=20TCP=20socket=20negotiation=20BUT=20with=20the=20obvious=20= SIP=20traffic trade=20off=20(which=20is=20probably=20why=20UPDATE=20should=20be=20encour= aged).=20=20The=20text will=20need=20to=20explicitly=20force=20the=20Hosting=20endpoint=20to=20di= spose=20of=20the current=20session=20(which=20it=20might=20still=20think=20is=20OK)=20and=20= then=20prepare=20for the=20new=20VISIT.=20=20 Chris. >-----Original=20Message----- >From:=20hisham.khartabil@nokia.com=20[mailto:hisham.khartabil@nokia.com] >Sent:=2002=20December=202003=2009:13 >To:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >Subject:=20RE:=20[Simple]=20MS(r)P:=20Reconnect=20issue > >Here=20is=20another=20reason=20I=20gave=20in=20an=20earlier=20discussion:= > >One=20endpoint=20might=20crash=20and=20reboot.=20Ports=20might=20change=20= so=20you=20need=20to re- >signal. > >BTW,=20I=20don't=20believe=20we=20had=20consensus=20in=20Minneapolis.=20I= n=20any=20case,=20I think >re-signalling=20is=20needed. > >/Hisham > >>=20-----Original=20Message----- >>=20From:=20simple-admin@ietf.org=20[mailto:simple-admin@ietf.org]On=20Be= half Of >>=20ext=20Ben=20Campbell >>=20Sent:=2001.December.2003=2021:12 >>=20To:=20Simple=20WG >>=20Subject:=20[Simple]=20MS(r)P:=20Reconnect=20issue >> >> >>=20In=20Minneapolis,=20the=20wg=20expressed=20a=20consensus=20that=20MS(= r)P=20(pending >>=20rename)=20should=20allow=20reconnection=20of=20dropped=20TCP=20connec= tions=20without >>=20requiring=20a=20new=20offer/answer.=20In=20that=20meeting,=20I=20ment= ioned=20that=20there >>=20was=20a=20reason=20we=20had=20originally=20chose=20not=20to=20allow=20= that,=20but=20I >>=20could=20not >>=20remember=20the=20details=20at=20the=20time.=20Having=20slept=20since=20= then,=20I >>=20now=20remember: >> >>=20Consider=20a=20visitor=20V=20has=20a=20TCP=20connection=20to=20a=20ho= st=20H,=20with=20an=20active >>=20session.=20That=20TCP=20connection=20is=20then=20dropped=20due=20to=20= something=20in=20the >>=20network.=20I=20don't=20know=20why,=20maybe=20a=20stateful=20firewall=20= dropped >>=20state,=20or=20a >>=20length=20of=20fiber=20was=20accidentally=20eaten=20by=20a=20sabre-too= th=20tiger.=20In=20any >>=20case,=20the=20connection=20is=20dropped=20without=20a=20proper=20FIN=20= handshake=20at=20the >>=20endpoints. >> >>=20It=20may=20take=20each=20endpoint=20sometime=20to=20actually=20notice= =20that=20this=20has >>=20occurred.=20Using=20common=20TCP=20state=20machine=20defaults,=20it=20= will=20typically >>=20take=20just=20under=2010=20minutes.=20It=20is=20also=20likely=20that=20= the >>=20participants=20will >>=20not=20figure=20it=20out=20at=20the=20same=20time. >> >>=20If=20H=20figures=20it=20out=20first,=20then=20things=20are=20reasonab= le=20ok.=20It >>=20just=20waits >>=20some=20period=20of=20time=20for=20V=20to=20notice,=20reconnect,=20and= =20send=20a=20VISIT=20with >>=20the=20session=20URI. >> >>=20But=20if=20V=20figures=20it=20out=20first,=20we=20have=20a=20problem.= =20V=20will >>=20reconnect,=20and >>=20attempt=20a=20VISIT=20with=20the=20session=20URI.=20The=20problem=20i= s,=20H=20thinks=20it >>=20already=20has=20a=20perfectly=20good=20connection=20for=20that=20sess= ion.=20It=20has=20two >>=20possible=20choices:=201)=20Fail=20the=20new=20VISIT,=20and=20assume=20= the=20old >>=20one=20is=20still >>=20good,=20or=202)=20Disconnect=20the=20old=20connection,=20and=20accept= =20the >>=20VISIT=20request >>=20on=20the=20new=20connection. >> >>=20Option=201=20is=20the=20currently=20defined=20behavior.=20It=20seems=20= pretty >>=20obvious=20that >>=20this=20pretty=20much=20prevents=20reconnections.=20Option=202=20would= =20allow >>=20reconnections,=20but=20it=20allows=20a=20really=20nasty=20session=20h= ijacking >>=20attack=20if >>=20an=20attacker=20happens=20to=20learn=20the=20session=20URI. >> >>=20I=20discussed=20this=20with=20several=20people=20a=20while=20back,=20= and=20the=20consensus >>=20seemed=20to=20be=20that=20option=202=20was=20not=20feasible,=20so=20w= e=20had=20to >>=20require=20a=20new >>=20sdp=20exchange=20with=20a=20new=20session=20URI=20in=20order=20to=20r= econnect. >> >>=20Option=201=20_might_=20be=20acceptable=20if=20we=20could=20guarantee=20= the >>=20confidentiality >>=20of=20the=20session=20URI.=20If=20we=20were=20to=20accept=20option=201= ,=20we=20would >>=20then=20have=20a >>=20strong=20reason=20to=20_require_=20the=20sdp=20exchange=20be=20protec= ted=20by >>=20using=20either >>=20SIPS=20or=20e2e=20crypto,=20and=20that=20the=20VISIT=20be=20sent=20ov= er=20TLS. >>=20Option=201=20also >>=20requires=20the=20host=20to=20listen=20for=20new=20connections=20prett= y=20much=20forever, >>=20which=20is=20not=20particularly=20pleasant. >> >>=20Thoughts?=20Have=20I=20missed=20an=20option? >> >> >>=20_______________________________________________ >>=20Simple=20mailing=20list >>=20Simple@ietf.org >>=20https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 05:14:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10561 for ; Tue, 2 Dec 2003 05:14:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Xs-0007K3-Dn for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 05:14:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2AEGQA028146 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 05:14:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Xp-0007Jt-PU for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 05:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10540; Tue, 2 Dec 2003 05:13:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Xl-0004Sg-00; Tue, 02 Dec 2003 05:14:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR7Xl-0004Sd-00; Tue, 02 Dec 2003 05:14:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Xf-0007JE-FJ; Tue, 02 Dec 2003 05:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR7Wk-0007IG-Iv for simple@optimus.ietf.org; Tue, 02 Dec 2003 05:13:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10527 for ; Tue, 2 Dec 2003 05:12:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR7Wh-0004S3-00 for simple@ietf.org; Tue, 02 Dec 2003 05:13:03 -0500 Received: from mail49.messagelabs.com ([193.109.255.19]) by ietf-mx with smtp (Exim 4.12) id 1AR7Wg-0004Ro-00 for simple@ietf.org; Tue, 02 Dec 2003 05:13:02 -0500 X-VirusChecked: Checked X-Env-Sender: cboulton@ubiquity.net X-Msg-Ref: server-5.tower-49.messagelabs.com!1070359947!528448 X-StarScan-Version: 5.1.13; banners=ubiquity.net,-,- Received: (qmail 23526 invoked from network); 2 Dec 2003 10:12:27 -0000 Received: from news.ubiquity.net (HELO gbnewp0186s1.eu.ubiquity.net) (194.202.146.92) by server-5.tower-49.messagelabs.com with SMTP; 2 Dec 2003 10:12:27 -0000 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for mail49.messagelabs.com [193.109.255.19]) with SMTP; Tue, 2 Dec 2003 10:15:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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] MS(r)P: Reconnect issue Message-ID: <45730E094814E44488F789C1CDED27AE0219B132@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Simple] MS(r)P: Reconnect issue Thread-Index: AcO4P1PeM5A0AurgRK2jD7/zl27qwwAdNFFAAAHv2bA= From: "Chris Boulton" To: , , Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 10:11:41 -0000 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm=20also=20in=20the=20re-signaling=20camp.=20=20It=20seems=20a=20far=20m= ore=20elegant=20solution compared=20to=20TCP=20socket=20negotiation=20BUT=20with=20the=20obvious=20= SIP=20traffic trade=20off=20(which=20is=20probably=20why=20UPDATE=20should=20be=20encour= aged).=20=20The=20text will=20need=20to=20explicitly=20force=20the=20Hosting=20endpoint=20to=20di= spose=20of=20the current=20session=20(which=20it=20might=20still=20think=20is=20OK)=20and=20= then=20prepare=20for the=20new=20VISIT.=20=20 Chris. >-----Original=20Message----- >From:=20hisham.khartabil@nokia.com=20[mailto:hisham.khartabil@nokia.com] >Sent:=2002=20December=202003=2009:13 >To:=20bcampbell@dynamicsoft.com;=20simple@ietf.org >Subject:=20RE:=20[Simple]=20MS(r)P:=20Reconnect=20issue > >Here=20is=20another=20reason=20I=20gave=20in=20an=20earlier=20discussion:= > >One=20endpoint=20might=20crash=20and=20reboot.=20Ports=20might=20change=20= so=20you=20need=20to re- >signal. > >BTW,=20I=20don't=20believe=20we=20had=20consensus=20in=20Minneapolis.=20I= n=20any=20case,=20I think >re-signalling=20is=20needed. > >/Hisham > >>=20-----Original=20Message----- >>=20From:=20simple-admin@ietf.org=20[mailto:simple-admin@ietf.org]On=20Be= half Of >>=20ext=20Ben=20Campbell >>=20Sent:=2001.December.2003=2021:12 >>=20To:=20Simple=20WG >>=20Subject:=20[Simple]=20MS(r)P:=20Reconnect=20issue >> >> >>=20In=20Minneapolis,=20the=20wg=20expressed=20a=20consensus=20that=20MS(= r)P=20(pending >>=20rename)=20should=20allow=20reconnection=20of=20dropped=20TCP=20connec= tions=20without >>=20requiring=20a=20new=20offer/answer.=20In=20that=20meeting,=20I=20ment= ioned=20that=20there >>=20was=20a=20reason=20we=20had=20originally=20chose=20not=20to=20allow=20= that,=20but=20I >>=20could=20not >>=20remember=20the=20details=20at=20the=20time.=20Having=20slept=20since=20= then,=20I >>=20now=20remember: >> >>=20Consider=20a=20visitor=20V=20has=20a=20TCP=20connection=20to=20a=20ho= st=20H,=20with=20an=20active >>=20session.=20That=20TCP=20connection=20is=20then=20dropped=20due=20to=20= something=20in=20the >>=20network.=20I=20don't=20know=20why,=20maybe=20a=20stateful=20firewall=20= dropped >>=20state,=20or=20a >>=20length=20of=20fiber=20was=20accidentally=20eaten=20by=20a=20sabre-too= th=20tiger.=20In=20any >>=20case,=20the=20connection=20is=20dropped=20without=20a=20proper=20FIN=20= handshake=20at=20the >>=20endpoints. >> >>=20It=20may=20take=20each=20endpoint=20sometime=20to=20actually=20notice= =20that=20this=20has >>=20occurred.=20Using=20common=20TCP=20state=20machine=20defaults,=20it=20= will=20typically >>=20take=20just=20under=2010=20minutes.=20It=20is=20also=20likely=20that=20= the >>=20participants=20will >>=20not=20figure=20it=20out=20at=20the=20same=20time. >> >>=20If=20H=20figures=20it=20out=20first,=20then=20things=20are=20reasonab= le=20ok.=20It >>=20just=20waits >>=20some=20period=20of=20time=20for=20V=20to=20notice,=20reconnect,=20and= =20send=20a=20VISIT=20with >>=20the=20session=20URI. >> >>=20But=20if=20V=20figures=20it=20out=20first,=20we=20have=20a=20problem.= =20V=20will >>=20reconnect,=20and >>=20attempt=20a=20VISIT=20with=20the=20session=20URI.=20The=20problem=20i= s,=20H=20thinks=20it >>=20already=20has=20a=20perfectly=20good=20connection=20for=20that=20sess= ion.=20It=20has=20two >>=20possible=20choices:=201)=20Fail=20the=20new=20VISIT,=20and=20assume=20= the=20old >>=20one=20is=20still >>=20good,=20or=202)=20Disconnect=20the=20old=20connection,=20and=20accept= =20the >>=20VISIT=20request >>=20on=20the=20new=20connection. >> >>=20Option=201=20is=20the=20currently=20defined=20behavior.=20It=20seems=20= pretty >>=20obvious=20that >>=20this=20pretty=20much=20prevents=20reconnections.=20Option=202=20would= =20allow >>=20reconnections,=20but=20it=20allows=20a=20really=20nasty=20session=20h= ijacking >>=20attack=20if >>=20an=20attacker=20happens=20to=20learn=20the=20session=20URI. >> >>=20I=20discussed=20this=20with=20several=20people=20a=20while=20back,=20= and=20the=20consensus >>=20seemed=20to=20be=20that=20option=202=20was=20not=20feasible,=20so=20w= e=20had=20to >>=20require=20a=20new >>=20sdp=20exchange=20with=20a=20new=20session=20URI=20in=20order=20to=20r= econnect. >> >>=20Option=201=20_might_=20be=20acceptable=20if=20we=20could=20guarantee=20= the >>=20confidentiality >>=20of=20the=20session=20URI.=20If=20we=20were=20to=20accept=20option=201= ,=20we=20would >>=20then=20have=20a >>=20strong=20reason=20to=20_require_=20the=20sdp=20exchange=20be=20protec= ted=20by >>=20using=20either >>=20SIPS=20or=20e2e=20crypto,=20and=20that=20the=20VISIT=20be=20sent=20ov= er=20TLS. >>=20Option=201=20also >>=20requires=20the=20host=20to=20listen=20for=20new=20connections=20prett= y=20much=20forever, >>=20which=20is=20not=20particularly=20pleasant. >> >>=20Thoughts?=20Have=20I=20missed=20an=20option? >> >> >>=20_______________________________________________ >>=20Simple=20mailing=20list >>=20Simple@ietf.org >>=20https://www1.ietf.org/mailman/listinfo/simple >> > >_______________________________________________ >Simple=20mailing=20list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > >_______________________________________________________________________ _ >This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Me= ssageLabs=20Email >Security=20System.=20For=20more=20information=20on=20a=20proactive=20emai= l=20security >service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit= >http://www.messagelabs.com >_______________________________________________________________________ _ ________________________________________________________________________ This=20email=20has=20been=20scanned=20for=20all=20viruses=20by=20the=20Mes= sageLabs=20Email Security=20System.=20For=20more=20information=20on=20a=20proactive=20email= =20security service=20working=20around=20the=20clock,=20around=20the=20globe,=20visit http://www.messagelabs.com ________________________________________________________________________ _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 08:47:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16963; Tue, 2 Dec 2003 08:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARAst-0000Um-00; Tue, 02 Dec 2003 08:48:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARAss-0000Uj-00; Tue, 02 Dec 2003 08:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAsi-00085L-Up; Tue, 02 Dec 2003 08:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARArp-00081P-4q for simple@optimus.ietf.org; Tue, 02 Dec 2003 08:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16826 for ; Tue, 2 Dec 2003 08:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARArn-0000Rq-00 for simple@ietf.org; Tue, 02 Dec 2003 08:47:03 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1ARArn-0000Rf-00 for simple@ietf.org; Tue, 02 Dec 2003 08:47:03 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id DC87AB4EF4 for ; Tue, 2 Dec 2003 08:47:00 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120208470025133 ; Tue, 02 Dec 2003 08:47:00 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 08:47:00 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO4hhvUHjzyJnRoSVexrP285YirYgAVKazs From: "Andrew Allen" To: Cc: X-OriginalArrivalTime: 02 Dec 2003 13:47:00.0711 (UTC) FILETIME=[C2CD1F70:01C3B8DA] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 08:47:00 -0500 Content-Transfer-Encoding: quoted-printable Ben Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec = instead of TLS for security between itself and the mobile UA mandating = TLS for SIP/SDP will not help in the 3GPP situation either unless a = radical change is made to the current 3GPP security architecture. If some people want to attempt reconnections without re-signaling is it = possible to use the VISIT 200 OK exchange to initially negotiate support = for reconnections and to exchange the necessary keys/certificates for = validation that the reconnect attempt came from the same endpoint as the = initial VISIT?=20 I am not a security expert but if this is feasable then it would make = reconnections possible but optional based on mutual negotiations between = endpoints. If such a scheme requires TLS on the MS(r)P connection then = TLS or TCP could also be part of the SDP negotiation in the initial = offer. For the wireless case I think we will want to use a renegotiation using = SIP as it is most likely that one of the mobiles went out of radio = coverage or that the battery died. In this case we want to detect using = signaling as soon as possible that the mobile is unreachable so that the = session can be released and the radio resources freed up. So I think you = can place me in the re-signaling camp. Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 European Mobile +358 50 467 5870 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Ben Campbell To: Andrew Allen CC: Simple WG Sent: Mon Dec 01 22:40:06 2003 Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Andrew Allen wrote: > Ben=20 >=20 > Ben, >=20 > If Option 2 requires end-to-end encryption of the SDP to protect the = URL > then it is not going to be suitable for use by 3GPP for message = sessions > at the present time. The 3GPP network currently needs to examine the = SDP > to perform authorization and allocation of radio resources for the > session. A possible alternative is the use of the SIPS scheme, where the device=20 that must inspect the SDP is a participant in one of the TLS=20 handshakes--and therefore can see the contents. But I must admit that=20 approach feels a little spooky. >=20 > In the wireless case the chances of dropped connections are probably a > lot higher with the mobile potentially moving in and out of coverage > (especially if going through tunnels on a train) so this is likely to = be > a more common scenario in wireless. >=20 > What were the main objections to re-invitation as a solution? >=20 The objection was that such TCP drops happen alot, and people wanted the = lightest weight recovery possible. If a simple TCP reconnect would work, = it would be nice--but I don't think it will work. > Why not use UPDATE to attempt to re-establish connections in the case > when the dialog still exists? UPDATE is less expensive in terms of SIP > messages to re-establish (no ACK required). In the 3GPP case the = sending > of a SIP request is likely to trigger a network initiated termination = of > the session (a BYE) if the mobile is still out of coverage, which I > expect is what is desired in the wireless case to release the network > resources. If we establish that we must use a new SDP exchange, then I expect=20 UPDATE and reinvites to both be applicable, depending on the particular=20 circumstance. >=20 > Andrew >=20 >=20 > =20 >=20 >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, December 01, 2003 2:54 PM >>To: Ben Campbell >>Cc: Simple WG >>Subject: [Simple] Re: MS(r)P: Reconnect issue >> >>Oops, got my options mixed up. See clarification below. >> >>Ben Campbell wrote: >> >> >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>>rename) should allow reconnection of dropped TCP connections without >>>requiring a new offer/answer. In that meeting, I mentioned that >=20 > there >=20 >>>was a reason we had originally chose not to allow that, but I could >=20 > not >=20 >>>remember the details at the time. Having slept since then, I now >> >>remember: >> >>>Consider a visitor V has a TCP connection to a host H, with an >=20 > active >=20 >>>session. That TCP connection is then dropped due to something in the >>>network. I don't know why, maybe a stateful firewall dropped state, >=20 > or a >=20 >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In >=20 > any >=20 >>>case, the connection is dropped without a proper FIN handshake at >=20 > the >=20 >>>endpoints. >>> >>>It may take each endpoint sometime to actually notice that this has >>>occurred. Using common TCP state machine defaults, it will typically >>>take just under 10 minutes. It is also likely that the participants >=20 > will >=20 >>>not figure it out at the same time. >>> >>>If H figures it out first, then things are reasonable ok. It just >=20 > waits >=20 >>>some period of time for V to notice, reconnect, and send a VISIT >=20 > with >=20 >>>the session URI. >>> >>>But if V figures it out first, we have a problem. V will reconnect, >=20 > and >=20 >>>attempt a VISIT with the session URI. The problem is, H thinks it >>>already has a perfectly good connection for that session. It has two >>>possible choices: 1) Fail the new VISIT, and assume the old one is >=20 > still >=20 >>>good, or 2) Disconnect the old connection, and accept the VISIT >=20 > request >=20 >>>on the new connection. >>> >>>Option 1 is the currently defined behavior. It seems pretty obvious >=20 > that >=20 >>>this pretty much prevents reconnections. Option 2 would allow >>>reconnections, but it allows a really nasty session hijacking attack >=20 > if >=20 >>>an attacker happens to learn the session URI. >>> >>>I discussed this with several people a while back, and the consensus >>>seemed to be that option 2 was not feasible, so we had to require a >=20 > new >=20 >>>sdp exchange with a new session URI in order to reconnect. >> >> > >> >>>Option 1 _might_ be acceptable if we could guarantee the >=20 > confidentiality >=20 >>>of the session URI. If we were to accept option 1, we would then >=20 > have a >=20 >>>strong reason to _require_ the sdp exchange be protected by using >=20 > either >=20 >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 >=20 > also >=20 >>>requires the host to listen for new connections pretty much forever, >>>which is not particularly pleasant. >>> >> >>For the above paragraph, I meant option 2. My apologies if anyone hurt >>their brain trying to figure out how that paragraph applied to option >=20 > 1. >=20 >> >>>Thoughts? Have I missed an option? >>> >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Tue Dec 2 08:48:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16995 for ; Tue, 2 Dec 2003 08:48:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAsu-00086F-Vi for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 08:48:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2DmC7D031130 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 08:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAsu-000860-Qy for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 08:48:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16963; Tue, 2 Dec 2003 08:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARAst-0000Um-00; Tue, 02 Dec 2003 08:48:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARAss-0000Uj-00; Tue, 02 Dec 2003 08:48:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARAsi-00085L-Up; Tue, 02 Dec 2003 08:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARArp-00081P-4q for simple@optimus.ietf.org; Tue, 02 Dec 2003 08:47:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16826 for ; Tue, 2 Dec 2003 08:46:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARArn-0000Rq-00 for simple@ietf.org; Tue, 02 Dec 2003 08:47:03 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1ARArn-0000Rf-00 for simple@ietf.org; Tue, 02 Dec 2003 08:47:03 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id DC87AB4EF4 for ; Tue, 2 Dec 2003 08:47:00 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120208470025133 ; Tue, 02 Dec 2003 08:47:00 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 08:47:00 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO4hhvUHjzyJnRoSVexrP285YirYgAVKazs From: "Andrew Allen" To: Cc: X-OriginalArrivalTime: 02 Dec 2003 13:47:00.0711 (UTC) FILETIME=[C2CD1F70:01C3B8DA] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 08:47:00 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ben Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec = instead of TLS for security between itself and the mobile UA mandating = TLS for SIP/SDP will not help in the 3GPP situation either unless a = radical change is made to the current 3GPP security architecture. If some people want to attempt reconnections without re-signaling is it = possible to use the VISIT 200 OK exchange to initially negotiate support = for reconnections and to exchange the necessary keys/certificates for = validation that the reconnect attempt came from the same endpoint as the = initial VISIT?=20 I am not a security expert but if this is feasable then it would make = reconnections possible but optional based on mutual negotiations between = endpoints. If such a scheme requires TLS on the MS(r)P connection then = TLS or TCP could also be part of the SDP negotiation in the initial = offer. For the wireless case I think we will want to use a renegotiation using = SIP as it is most likely that one of the mobiles went out of radio = coverage or that the battery died. In this case we want to detect using = signaling as soon as possible that the mobile is unreachable so that the = session can be released and the radio resources freed up. So I think you = can place me in the re-signaling camp. Andrew -------------------------- Andrew Allen Manager Standards Research In Motion Ltd BlackBerry Mobile +1 847 809 8636 European Mobile +358 50 467 5870 http://www.rim.com/ Sent from my BlackBerry Wireless Handheld -----Original Message----- From: Ben Campbell To: Andrew Allen CC: Simple WG Sent: Mon Dec 01 22:40:06 2003 Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Andrew Allen wrote: > Ben=20 >=20 > Ben, >=20 > If Option 2 requires end-to-end encryption of the SDP to protect the = URL > then it is not going to be suitable for use by 3GPP for message = sessions > at the present time. The 3GPP network currently needs to examine the = SDP > to perform authorization and allocation of radio resources for the > session. A possible alternative is the use of the SIPS scheme, where the device=20 that must inspect the SDP is a participant in one of the TLS=20 handshakes--and therefore can see the contents. But I must admit that=20 approach feels a little spooky. >=20 > In the wireless case the chances of dropped connections are probably a > lot higher with the mobile potentially moving in and out of coverage > (especially if going through tunnels on a train) so this is likely to = be > a more common scenario in wireless. >=20 > What were the main objections to re-invitation as a solution? >=20 The objection was that such TCP drops happen alot, and people wanted the = lightest weight recovery possible. If a simple TCP reconnect would work, = it would be nice--but I don't think it will work. > Why not use UPDATE to attempt to re-establish connections in the case > when the dialog still exists? UPDATE is less expensive in terms of SIP > messages to re-establish (no ACK required). In the 3GPP case the = sending > of a SIP request is likely to trigger a network initiated termination = of > the session (a BYE) if the mobile is still out of coverage, which I > expect is what is desired in the wireless case to release the network > resources. If we establish that we must use a new SDP exchange, then I expect=20 UPDATE and reinvites to both be applicable, depending on the particular=20 circumstance. >=20 > Andrew >=20 >=20 > =20 >=20 >>-----Original Message----- >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: Monday, December 01, 2003 2:54 PM >>To: Ben Campbell >>Cc: Simple WG >>Subject: [Simple] Re: MS(r)P: Reconnect issue >> >>Oops, got my options mixed up. See clarification below. >> >>Ben Campbell wrote: >> >> >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>>rename) should allow reconnection of dropped TCP connections without >>>requiring a new offer/answer. In that meeting, I mentioned that >=20 > there >=20 >>>was a reason we had originally chose not to allow that, but I could >=20 > not >=20 >>>remember the details at the time. Having slept since then, I now >> >>remember: >> >>>Consider a visitor V has a TCP connection to a host H, with an >=20 > active >=20 >>>session. That TCP connection is then dropped due to something in the >>>network. I don't know why, maybe a stateful firewall dropped state, >=20 > or a >=20 >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In >=20 > any >=20 >>>case, the connection is dropped without a proper FIN handshake at >=20 > the >=20 >>>endpoints. >>> >>>It may take each endpoint sometime to actually notice that this has >>>occurred. Using common TCP state machine defaults, it will typically >>>take just under 10 minutes. It is also likely that the participants >=20 > will >=20 >>>not figure it out at the same time. >>> >>>If H figures it out first, then things are reasonable ok. It just >=20 > waits >=20 >>>some period of time for V to notice, reconnect, and send a VISIT >=20 > with >=20 >>>the session URI. >>> >>>But if V figures it out first, we have a problem. V will reconnect, >=20 > and >=20 >>>attempt a VISIT with the session URI. The problem is, H thinks it >>>already has a perfectly good connection for that session. It has two >>>possible choices: 1) Fail the new VISIT, and assume the old one is >=20 > still >=20 >>>good, or 2) Disconnect the old connection, and accept the VISIT >=20 > request >=20 >>>on the new connection. >>> >>>Option 1 is the currently defined behavior. It seems pretty obvious >=20 > that >=20 >>>this pretty much prevents reconnections. Option 2 would allow >>>reconnections, but it allows a really nasty session hijacking attack >=20 > if >=20 >>>an attacker happens to learn the session URI. >>> >>>I discussed this with several people a while back, and the consensus >>>seemed to be that option 2 was not feasible, so we had to require a >=20 > new >=20 >>>sdp exchange with a new session URI in order to reconnect. >> >> > >> >>>Option 1 _might_ be acceptable if we could guarantee the >=20 > confidentiality >=20 >>>of the session URI. If we were to accept option 1, we would then >=20 > have a >=20 >>>strong reason to _require_ the sdp exchange be protected by using >=20 > either >=20 >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 >=20 > also >=20 >>>requires the host to listen for new connections pretty much forever, >>>which is not particularly pleasant. >>> >> >>For the above paragraph, I meant option 2. My apologies if anyone hurt >>their brain trying to figure out how that paragraph applied to option >=20 > 1. >=20 >> >>>Thoughts? Have I missed an option? >>> >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Tue Dec 2 08:58:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17309; Tue, 2 Dec 2003 08:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARB3R-0000hP-00; Tue, 02 Dec 2003 08:59:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARB3R-0000hM-00; Tue, 02 Dec 2003 08:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3M-0000De-Ru; Tue, 02 Dec 2003 08:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3F-0000DM-V5 for simple@optimus.ietf.org; Tue, 02 Dec 2003 08:58:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17295 for ; Tue, 2 Dec 2003 08:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARB3E-0000gs-00 for simple@ietf.org; Tue, 02 Dec 2003 08:58:52 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARB3D-0000gY-00 for simple@ietf.org; Tue, 02 Dec 2003 08:58:51 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB2DwinG067595; Tue, 2 Dec 2003 07:58:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCC9A83.6070706@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MS(r)P: Reconnect issue References: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 07:58:27 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Here is another reason I gave in an earlier discussion: > > One endpoint might crash and reboot. Ports might change so you need to re-signal. > > BTW, I don't believe we had consensus in Minneapolis. In any case, I think re-signalling is needed. Certainly, there are situations where an endpoint looses state an the session cannot be resumed without re-signaling. In your example, it is likely they are starting over from scratch. I think the discussion in Minneapolis was targeted towards disconnects happening in the network, rather than at the edges. > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 01.December.2003 21:12 >>To: Simple WG >>Subject: [Simple] MS(r)P: Reconnect issue >> >> >>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>rename) should allow reconnection of dropped TCP connections without >>requiring a new offer/answer. In that meeting, I mentioned that there >>was a reason we had originally chose not to allow that, but I >>could not >>remember the details at the time. Having slept since then, I >>now remember: >> >>Consider a visitor V has a TCP connection to a host H, with an active >>session. That TCP connection is then dropped due to something in the >>network. I don't know why, maybe a stateful firewall dropped >>state, or a >>length of fiber was accidentally eaten by a sabre-tooth tiger. In any >>case, the connection is dropped without a proper FIN handshake at the >>endpoints. >> >>It may take each endpoint sometime to actually notice that this has >>occurred. Using common TCP state machine defaults, it will typically >>take just under 10 minutes. It is also likely that the >>participants will >>not figure it out at the same time. >> >>If H figures it out first, then things are reasonable ok. It >>just waits >>some period of time for V to notice, reconnect, and send a VISIT with >>the session URI. >> >>But if V figures it out first, we have a problem. V will >>reconnect, and >>attempt a VISIT with the session URI. The problem is, H thinks it >>already has a perfectly good connection for that session. It has two >>possible choices: 1) Fail the new VISIT, and assume the old >>one is still >>good, or 2) Disconnect the old connection, and accept the >>VISIT request >>on the new connection. >> >>Option 1 is the currently defined behavior. It seems pretty >>obvious that >>this pretty much prevents reconnections. Option 2 would allow >>reconnections, but it allows a really nasty session hijacking >>attack if >>an attacker happens to learn the session URI. >> >>I discussed this with several people a while back, and the consensus >>seemed to be that option 2 was not feasible, so we had to >>require a new >>sdp exchange with a new session URI in order to reconnect. >> >>Option 1 _might_ be acceptable if we could guarantee the >>confidentiality >>of the session URI. If we were to accept option 1, we would >>then have a >>strong reason to _require_ the sdp exchange be protected by >>using either >>SIPS or e2e crypto, and that the VISIT be sent over TLS. >>Option 1 also >>requires the host to listen for new connections pretty much forever, >>which is not particularly pleasant. >> >>Thoughts? Have I missed an option? >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Tue Dec 2 08:59:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17338 for ; Tue, 2 Dec 2003 08:59:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3U-0000Fw-2d for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 08:59:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Dx8HP000901 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 08:59:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3T-0000ES-Mw for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 08:59:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17309; Tue, 2 Dec 2003 08:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARB3R-0000hP-00; Tue, 02 Dec 2003 08:59:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARB3R-0000hM-00; Tue, 02 Dec 2003 08:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3M-0000De-Ru; Tue, 02 Dec 2003 08:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARB3F-0000DM-V5 for simple@optimus.ietf.org; Tue, 02 Dec 2003 08:58:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17295 for ; Tue, 2 Dec 2003 08:58:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARB3E-0000gs-00 for simple@ietf.org; Tue, 02 Dec 2003 08:58:52 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARB3D-0000gY-00 for simple@ietf.org; Tue, 02 Dec 2003 08:58:51 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB2DwinG067595; Tue, 2 Dec 2003 07:58:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCC9A83.6070706@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MS(r)P: Reconnect issue References: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797465@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 07:58:27 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Here is another reason I gave in an earlier discussion: > > One endpoint might crash and reboot. Ports might change so you need to re-signal. > > BTW, I don't believe we had consensus in Minneapolis. In any case, I think re-signalling is needed. Certainly, there are situations where an endpoint looses state an the session cannot be resumed without re-signaling. In your example, it is likely they are starting over from scratch. I think the discussion in Minneapolis was targeted towards disconnects happening in the network, rather than at the edges. > > /Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 01.December.2003 21:12 >>To: Simple WG >>Subject: [Simple] MS(r)P: Reconnect issue >> >> >>In Minneapolis, the wg expressed a consensus that MS(r)P (pending >>rename) should allow reconnection of dropped TCP connections without >>requiring a new offer/answer. In that meeting, I mentioned that there >>was a reason we had originally chose not to allow that, but I >>could not >>remember the details at the time. Having slept since then, I >>now remember: >> >>Consider a visitor V has a TCP connection to a host H, with an active >>session. That TCP connection is then dropped due to something in the >>network. I don't know why, maybe a stateful firewall dropped >>state, or a >>length of fiber was accidentally eaten by a sabre-tooth tiger. In any >>case, the connection is dropped without a proper FIN handshake at the >>endpoints. >> >>It may take each endpoint sometime to actually notice that this has >>occurred. Using common TCP state machine defaults, it will typically >>take just under 10 minutes. It is also likely that the >>participants will >>not figure it out at the same time. >> >>If H figures it out first, then things are reasonable ok. It >>just waits >>some period of time for V to notice, reconnect, and send a VISIT with >>the session URI. >> >>But if V figures it out first, we have a problem. V will >>reconnect, and >>attempt a VISIT with the session URI. The problem is, H thinks it >>already has a perfectly good connection for that session. It has two >>possible choices: 1) Fail the new VISIT, and assume the old >>one is still >>good, or 2) Disconnect the old connection, and accept the >>VISIT request >>on the new connection. >> >>Option 1 is the currently defined behavior. It seems pretty >>obvious that >>this pretty much prevents reconnections. Option 2 would allow >>reconnections, but it allows a really nasty session hijacking >>attack if >>an attacker happens to learn the session URI. >> >>I discussed this with several people a while back, and the consensus >>seemed to be that option 2 was not feasible, so we had to >>require a new >>sdp exchange with a new session URI in order to reconnect. >> >>Option 1 _might_ be acceptable if we could guarantee the >>confidentiality >>of the session URI. If we were to accept option 1, we would >>then have a >>strong reason to _require_ the sdp exchange be protected by >>using either >>SIPS or e2e crypto, and that the VISIT be sent over TLS. >>Option 1 also >>requires the host to listen for new connections pretty much forever, >>which is not particularly pleasant. >> >>Thoughts? Have I missed an option? >> >> >>_______________________________________________ >>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-admin@ietf.org Tue Dec 2 11:43:20 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25962; Tue, 2 Dec 2003 11:43:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDcb-0003sx-00; Tue, 02 Dec 2003 11:43:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDca-0003su-00; Tue, 02 Dec 2003 11:43:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDcQ-0000Kp-MB; Tue, 02 Dec 2003 11:43:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDb9-0000F8-LM for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25891 for ; Tue, 2 Dec 2003 11:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDay-0003qj-00 for simple@ietf.org; Tue, 02 Dec 2003 11:41:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARDax-0003q0-00 for simple@ietf.org; Tue, 02 Dec 2003 11:41:51 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2GfBxg010960; Tue, 2 Dec 2003 11:41:14 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVI65980; Tue, 2 Dec 2003 08:41:11 -0800 (PST) Message-Id: <4.3.2.7.2.20031202113311.00b4eb78@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Andrew Allen" From: Michael Hammer Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 11:41:10 -0500 Andrew, Is it not true that for hand-offs in mobile networks that existing "calls" being handed-off into new cells get precedence over new calls? It seems that if you use the INVITE versus UPDATE methods, that you lose this advantage and the dropped call rate will increase. However, if you do not feel that there is a resource contention issue, then this may not be a problem. Mike At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: >Ben > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec >instead of TLS for security between itself and the mobile UA mandating TLS >for SIP/SDP will not help in the 3GPP situation either unless a radical >change is made to the current 3GPP security architecture. > >If some people want to attempt reconnections without re-signaling is it >possible to use the VISIT 200 OK exchange to initially negotiate support >for reconnections and to exchange the necessary keys/certificates for >validation that the reconnect attempt came from the same endpoint as the >initial VISIT? > >I am not a security expert but if this is feasable then it would make >reconnections possible but optional based on mutual negotiations between >endpoints. If such a scheme requires TLS on the MS(r)P connection then TLS >or TCP could also be part of the SDP negotiation in the initial offer. > >For the wireless case I think we will want to use a renegotiation using >SIP as it is most likely that one of the mobiles went out of radio >coverage or that the battery died. In this case we want to detect using >signaling as soon as possible that the mobile is unreachable so that the >session can be released and the radio resources freed up. So I think you >can place me in the re-signaling camp. > >Andrew >-------------------------- >Andrew Allen >Manager Standards >Research In Motion Ltd >BlackBerry Mobile +1 847 809 8636 >European Mobile +358 50 467 5870 >http://www.rim.com/ > >Sent from my BlackBerry Wireless Handheld > > >-----Original Message----- >From: Ben Campbell >To: Andrew Allen >CC: Simple WG >Sent: Mon Dec 01 22:40:06 2003 >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > >Andrew Allen wrote: > > > Ben > > > > Ben, > > > > If Option 2 requires end-to-end encryption of the SDP to protect the URL > > then it is not going to be suitable for use by 3GPP for message sessions > > at the present time. The 3GPP network currently needs to examine the SDP > > to perform authorization and allocation of radio resources for the > > session. > >A possible alternative is the use of the SIPS scheme, where the device >that must inspect the SDP is a participant in one of the TLS >handshakes--and therefore can see the contents. But I must admit that >approach feels a little spooky. > > > > > In the wireless case the chances of dropped connections are probably a > > lot higher with the mobile potentially moving in and out of coverage > > (especially if going through tunnels on a train) so this is likely to be > > a more common scenario in wireless. > > > > What were the main objections to re-invitation as a solution? > > > >The objection was that such TCP drops happen alot, and people wanted the >lightest weight recovery possible. If a simple TCP reconnect would work, >it would be nice--but I don't think it will work. > > > Why not use UPDATE to attempt to re-establish connections in the case > > when the dialog still exists? UPDATE is less expensive in terms of SIP > > messages to re-establish (no ACK required). In the 3GPP case the sending > > of a SIP request is likely to trigger a network initiated termination of > > the session (a BYE) if the mobile is still out of coverage, which I > > expect is what is desired in the wireless case to release the network > > resources. > >If we establish that we must use a new SDP exchange, then I expect >UPDATE and reinvites to both be applicable, depending on the particular >circumstance. > > > > > Andrew > > > > > > > > > >>-----Original Message----- > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: Monday, December 01, 2003 2:54 PM > >>To: Ben Campbell > >>Cc: Simple WG > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > >> > >>Oops, got my options mixed up. See clarification below. > >> > >>Ben Campbell wrote: > >> > >> > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > >>>rename) should allow reconnection of dropped TCP connections without > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > there > > > >>>was a reason we had originally chose not to allow that, but I could > > > > not > > > >>>remember the details at the time. Having slept since then, I now > >> > >>remember: > >> > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > active > > > >>>session. That TCP connection is then dropped due to something in the > >>>network. I don't know why, maybe a stateful firewall dropped state, > > > > or a > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > any > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > the > > > >>>endpoints. > >>> > >>>It may take each endpoint sometime to actually notice that this has > >>>occurred. Using common TCP state machine defaults, it will typically > >>>take just under 10 minutes. It is also likely that the participants > > > > will > > > >>>not figure it out at the same time. > >>> > >>>If H figures it out first, then things are reasonable ok. It just > > > > waits > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > with > > > >>>the session URI. > >>> > >>>But if V figures it out first, we have a problem. V will reconnect, > > > > and > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > >>>already has a perfectly good connection for that session. It has two > >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > > > still > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > request > > > >>>on the new connection. > >>> > >>>Option 1 is the currently defined behavior. It seems pretty obvious > > > > that > > > >>>this pretty much prevents reconnections. Option 2 would allow > >>>reconnections, but it allows a really nasty session hijacking attack > > > > if > > > >>>an attacker happens to learn the session URI. > >>> > >>>I discussed this with several people a while back, and the consensus > >>>seemed to be that option 2 was not feasible, so we had to require a > > > > new > > > >>>sdp exchange with a new session URI in order to reconnect. > >> > >> > > >> > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > confidentiality > > > >>>of the session URI. If we were to accept option 1, we would then > > > > have a > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > either > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > also > > > >>>requires the host to listen for new connections pretty much forever, > >>>which is not particularly pleasant. > >>> > >> > >>For the above paragraph, I meant option 2. My apologies if anyone hurt > >>their brain trying to figure out how that paragraph applied to option > > > > 1. > > > >> > >>>Thoughts? Have I missed an option? > >>> > >> > >> > >> > >>_______________________________________________ > >>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 exim@www1.ietf.org Tue Dec 2 11:43:51 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26015 for ; Tue, 2 Dec 2003 11:43:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDcc-0000OV-Ud for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 11:43:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2GhY5T001511 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 11:43:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDcc-0000OI-LH for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:43:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25962; Tue, 2 Dec 2003 11:43:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDcb-0003sx-00; Tue, 02 Dec 2003 11:43:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDca-0003su-00; Tue, 02 Dec 2003 11:43:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDcQ-0000Kp-MB; Tue, 02 Dec 2003 11:43:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDb9-0000F8-LM for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:42:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25891 for ; Tue, 2 Dec 2003 11:41:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDay-0003qj-00 for simple@ietf.org; Tue, 02 Dec 2003 11:41:52 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARDax-0003q0-00 for simple@ietf.org; Tue, 02 Dec 2003 11:41:51 -0500 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2GfBxg010960; Tue, 2 Dec 2003 11:41:14 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVI65980; Tue, 2 Dec 2003 08:41:11 -0800 (PST) Message-Id: <4.3.2.7.2.20031202113311.00b4eb78@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Andrew Allen" From: Michael Hammer Subject: Re: [Simple] Re: MS(r)P: Reconnect issue Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 11:41:10 -0500 Andrew, Is it not true that for hand-offs in mobile networks that existing "calls" being handed-off into new cells get precedence over new calls? It seems that if you use the INVITE versus UPDATE methods, that you lose this advantage and the dropped call rate will increase. However, if you do not feel that there is a resource contention issue, then this may not be a problem. Mike At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: >Ben > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec >instead of TLS for security between itself and the mobile UA mandating TLS >for SIP/SDP will not help in the 3GPP situation either unless a radical >change is made to the current 3GPP security architecture. > >If some people want to attempt reconnections without re-signaling is it >possible to use the VISIT 200 OK exchange to initially negotiate support >for reconnections and to exchange the necessary keys/certificates for >validation that the reconnect attempt came from the same endpoint as the >initial VISIT? > >I am not a security expert but if this is feasable then it would make >reconnections possible but optional based on mutual negotiations between >endpoints. If such a scheme requires TLS on the MS(r)P connection then TLS >or TCP could also be part of the SDP negotiation in the initial offer. > >For the wireless case I think we will want to use a renegotiation using >SIP as it is most likely that one of the mobiles went out of radio >coverage or that the battery died. In this case we want to detect using >signaling as soon as possible that the mobile is unreachable so that the >session can be released and the radio resources freed up. So I think you >can place me in the re-signaling camp. > >Andrew >-------------------------- >Andrew Allen >Manager Standards >Research In Motion Ltd >BlackBerry Mobile +1 847 809 8636 >European Mobile +358 50 467 5870 >http://www.rim.com/ > >Sent from my BlackBerry Wireless Handheld > > >-----Original Message----- >From: Ben Campbell >To: Andrew Allen >CC: Simple WG >Sent: Mon Dec 01 22:40:06 2003 >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > >Andrew Allen wrote: > > > Ben > > > > Ben, > > > > If Option 2 requires end-to-end encryption of the SDP to protect the URL > > then it is not going to be suitable for use by 3GPP for message sessions > > at the present time. The 3GPP network currently needs to examine the SDP > > to perform authorization and allocation of radio resources for the > > session. > >A possible alternative is the use of the SIPS scheme, where the device >that must inspect the SDP is a participant in one of the TLS >handshakes--and therefore can see the contents. But I must admit that >approach feels a little spooky. > > > > > In the wireless case the chances of dropped connections are probably a > > lot higher with the mobile potentially moving in and out of coverage > > (especially if going through tunnels on a train) so this is likely to be > > a more common scenario in wireless. > > > > What were the main objections to re-invitation as a solution? > > > >The objection was that such TCP drops happen alot, and people wanted the >lightest weight recovery possible. If a simple TCP reconnect would work, >it would be nice--but I don't think it will work. > > > Why not use UPDATE to attempt to re-establish connections in the case > > when the dialog still exists? UPDATE is less expensive in terms of SIP > > messages to re-establish (no ACK required). In the 3GPP case the sending > > of a SIP request is likely to trigger a network initiated termination of > > the session (a BYE) if the mobile is still out of coverage, which I > > expect is what is desired in the wireless case to release the network > > resources. > >If we establish that we must use a new SDP exchange, then I expect >UPDATE and reinvites to both be applicable, depending on the particular >circumstance. > > > > > Andrew > > > > > > > > > >>-----Original Message----- > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>Sent: Monday, December 01, 2003 2:54 PM > >>To: Ben Campbell > >>Cc: Simple WG > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > >> > >>Oops, got my options mixed up. See clarification below. > >> > >>Ben Campbell wrote: > >> > >> > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > >>>rename) should allow reconnection of dropped TCP connections without > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > there > > > >>>was a reason we had originally chose not to allow that, but I could > > > > not > > > >>>remember the details at the time. Having slept since then, I now > >> > >>remember: > >> > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > active > > > >>>session. That TCP connection is then dropped due to something in the > >>>network. I don't know why, maybe a stateful firewall dropped state, > > > > or a > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > any > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > the > > > >>>endpoints. > >>> > >>>It may take each endpoint sometime to actually notice that this has > >>>occurred. Using common TCP state machine defaults, it will typically > >>>take just under 10 minutes. It is also likely that the participants > > > > will > > > >>>not figure it out at the same time. > >>> > >>>If H figures it out first, then things are reasonable ok. It just > > > > waits > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > with > > > >>>the session URI. > >>> > >>>But if V figures it out first, we have a problem. V will reconnect, > > > > and > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > >>>already has a perfectly good connection for that session. It has two > >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > > > still > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > request > > > >>>on the new connection. > >>> > >>>Option 1 is the currently defined behavior. It seems pretty obvious > > > > that > > > >>>this pretty much prevents reconnections. Option 2 would allow > >>>reconnections, but it allows a really nasty session hijacking attack > > > > if > > > >>>an attacker happens to learn the session URI. > >>> > >>>I discussed this with several people a while back, and the consensus > >>>seemed to be that option 2 was not feasible, so we had to require a > > > > new > > > >>>sdp exchange with a new session URI in order to reconnect. > >> > >> > > >> > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > confidentiality > > > >>>of the session URI. If we were to accept option 1, we would then > > > > have a > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > either > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > also > > > >>>requires the host to listen for new connections pretty much forever, > >>>which is not particularly pleasant. > >>> > >> > >>For the above paragraph, I meant option 2. My apologies if anyone hurt > >>their brain trying to figure out how that paragraph applied to option > > > > 1. > > > >> > >>>Thoughts? Have I missed an option? > >>> > >> > >> > >> > >>_______________________________________________ > >>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-admin@ietf.org Tue Dec 2 11:49:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26528; Tue, 2 Dec 2003 11:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDiw-00045K-00; Tue, 02 Dec 2003 11:50:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDiw-00045F-00; Tue, 02 Dec 2003 11:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDiu-0001JQ-Dw; Tue, 02 Dec 2003 11:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDic-0001HP-Ih for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:49:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26478 for ; Tue, 2 Dec 2003 11:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDib-00043q-00 for simple@ietf.org; Tue, 02 Dec 2003 11:49:45 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ARDia-00043n-00 for simple@ietf.org; Tue, 02 Dec 2003 11:49:44 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB2GnhSs012048 for ; Tue, 2 Dec 2003 17:49:43 +0100 (MET) Received: from lm9014.lmera.ericsson.se ([150.132.89.14]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7RR25D; Tue, 2 Dec 2003 17:49:43 +0100 From: "David Partain (LI/EAB)" Reply-To: David.Partain@ericsson.com Organization: Ericsson AB To: Simple WG User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312021749.42661.david.partain@ericsson.com> Content-Transfer-Encoding: 7bit Subject: [Simple] The "both" timer Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 17:49:42 +0100 Content-Transfer-Encoding: 7bit Greetings, I don't understand the timer associated with the both direction attribute (page 11 in the -02 version). I'd be really grateful if someone could explain to me how it works. The text says that this timer specifies how long the "answerer" should wait before giving up on the connection and trying to take over has host for the session. If I send an INVITE with "both" and set the timer to 45 seconds, I've also supplied an MSRP URL that the answerer can use to VISIT me. Does the timer start when the answerer sends the VISIT to the offerer at the MSRP URL? It doesn't make much sense to me that the offerer should tell the answerer to wait after sending the VISIT, but I'm probably missing something. And if the answerer doesn't get an OK for the VISIT within the alloted 45 seconds, what then? How is it expected to take over as host? Is "answerer" above really supposed to be "offerer"? I don't see how that works either, though, since the offerer has no URL to VISIT. I'm just generally confused and don't understand the timer. Would some kind soul please enlighten me? Thanks much. David _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 11:50:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26575 for ; Tue, 2 Dec 2003 11:50:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDiy-0001L8-KC for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 11:50:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Go8UP005144 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 11:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDiy-0001Kt-GV for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:50:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26528; Tue, 2 Dec 2003 11:49:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDiw-00045K-00; Tue, 02 Dec 2003 11:50:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDiw-00045F-00; Tue, 02 Dec 2003 11:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDiu-0001JQ-Dw; Tue, 02 Dec 2003 11:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDic-0001HP-Ih for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:49:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26478 for ; Tue, 2 Dec 2003 11:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDib-00043q-00 for simple@ietf.org; Tue, 02 Dec 2003 11:49:45 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ARDia-00043n-00 for simple@ietf.org; Tue, 02 Dec 2003 11:49:44 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB2GnhSs012048 for ; Tue, 2 Dec 2003 17:49:43 +0100 (MET) Received: from lm9014.lmera.ericsson.se ([150.132.89.14]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7RR25D; Tue, 2 Dec 2003 17:49:43 +0100 From: "David Partain (LI/EAB)" Reply-To: David.Partain@ericsson.com Organization: Ericsson AB To: Simple WG User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200312021749.42661.david.partain@ericsson.com> Content-Transfer-Encoding: 7bit Subject: [Simple] The "both" timer Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Dec 2003 17:49:42 +0100 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greetings, I don't understand the timer associated with the both direction attribute (page 11 in the -02 version). I'd be really grateful if someone could explain to me how it works. The text says that this timer specifies how long the "answerer" should wait before giving up on the connection and trying to take over has host for the session. If I send an INVITE with "both" and set the timer to 45 seconds, I've also supplied an MSRP URL that the answerer can use to VISIT me. Does the timer start when the answerer sends the VISIT to the offerer at the MSRP URL? It doesn't make much sense to me that the offerer should tell the answerer to wait after sending the VISIT, but I'm probably missing something. And if the answerer doesn't get an OK for the VISIT within the alloted 45 seconds, what then? How is it expected to take over as host? Is "answerer" above really supposed to be "offerer"? I don't see how that works either, though, since the offerer has no URL to VISIT. I'm just generally confused and don't understand the timer. Would some kind soul please enlighten me? Thanks much. David _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 11:50:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26616; Tue, 2 Dec 2003 11:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjr-00047a-00; Tue, 02 Dec 2003 11:51:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDjr-00047U-00; Tue, 02 Dec 2003 11:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjq-0001RD-Tc; Tue, 02 Dec 2003 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjS-0001PI-44 for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:50:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26573 for ; Tue, 2 Dec 2003 11:50:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjQ-00046Q-00 for simple@ietf.org; Tue, 02 Dec 2003 11:50:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjQ-00044s-00 for simple@ietf.org; Tue, 02 Dec 2003 11:50:36 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2003 08:49:27 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2Go1xg013301; Tue, 2 Dec 2003 11:50:02 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI96228; Tue, 2 Dec 2003 11:50:00 -0500 (EST) Message-ID: <3FCCC2B8.4020009@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MS(r)P: Reconnect issue References: <3FCB929A.4060703@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 11:50:00 -0500 Content-Transfer-Encoding: 7bit I am also in the resignal (reinvite/update) camp. The problems of reconnecting without seem hard and not worth the effort of trying to solve. Paul Ben Campbell wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > > Thoughts? Have I missed an option? > > > _______________________________________________ > 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 exim@www1.ietf.org Tue Dec 2 11:51:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26667 for ; Tue, 2 Dec 2003 11:51:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjt-0001U2-I1 for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 11:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Gp5uC005689 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 11:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjt-0001Tc-AY for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 11:51:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26616; Tue, 2 Dec 2003 11:50:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjr-00047a-00; Tue, 02 Dec 2003 11:51:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARDjr-00047U-00; Tue, 02 Dec 2003 11:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjq-0001RD-Tc; Tue, 02 Dec 2003 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARDjS-0001PI-44 for simple@optimus.ietf.org; Tue, 02 Dec 2003 11:50:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26573 for ; Tue, 2 Dec 2003 11:50:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjQ-00046Q-00 for simple@ietf.org; Tue, 02 Dec 2003 11:50:37 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ARDjQ-00044s-00 for simple@ietf.org; Tue, 02 Dec 2003 11:50:36 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 02 Dec 2003 08:49:27 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2Go1xg013301; Tue, 2 Dec 2003 11:50:02 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEI96228; Tue, 2 Dec 2003 11:50:00 -0500 (EST) Message-ID: <3FCCC2B8.4020009@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MS(r)P: Reconnect issue References: <3FCB929A.4060703@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 11:50:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am also in the resignal (reinvite/update) camp. The problems of reconnecting without seem hard and not worth the effort of trying to solve. Paul Ben Campbell wrote: > In Minneapolis, the wg expressed a consensus that MS(r)P (pending > rename) should allow reconnection of dropped TCP connections without > requiring a new offer/answer. In that meeting, I mentioned that there > was a reason we had originally chose not to allow that, but I could not > remember the details at the time. Having slept since then, I now remember: > > Consider a visitor V has a TCP connection to a host H, with an active > session. That TCP connection is then dropped due to something in the > network. I don't know why, maybe a stateful firewall dropped state, or a > length of fiber was accidentally eaten by a sabre-tooth tiger. In any > case, the connection is dropped without a proper FIN handshake at the > endpoints. > > It may take each endpoint sometime to actually notice that this has > occurred. Using common TCP state machine defaults, it will typically > take just under 10 minutes. It is also likely that the participants will > not figure it out at the same time. > > If H figures it out first, then things are reasonable ok. It just waits > some period of time for V to notice, reconnect, and send a VISIT with > the session URI. > > But if V figures it out first, we have a problem. V will reconnect, and > attempt a VISIT with the session URI. The problem is, H thinks it > already has a perfectly good connection for that session. It has two > possible choices: 1) Fail the new VISIT, and assume the old one is still > good, or 2) Disconnect the old connection, and accept the VISIT request > on the new connection. > > Option 1 is the currently defined behavior. It seems pretty obvious that > this pretty much prevents reconnections. Option 2 would allow > reconnections, but it allows a really nasty session hijacking attack if > an attacker happens to learn the session URI. > > I discussed this with several people a while back, and the consensus > seemed to be that option 2 was not feasible, so we had to require a new > sdp exchange with a new session URI in order to reconnect. > > Option 1 _might_ be acceptable if we could guarantee the confidentiality > of the session URI. If we were to accept option 1, we would then have a > strong reason to _require_ the sdp exchange be protected by using either > SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 also > requires the host to listen for new connections pretty much forever, > which is not particularly pleasant. > > Thoughts? Have I missed an option? > > > _______________________________________________ > 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-admin@ietf.org Tue Dec 2 14:53:57 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04826; Tue, 2 Dec 2003 14:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGb2-0007Ai-00; Tue, 02 Dec 2003 14:54:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGb2-0007AT-00; Tue, 02 Dec 2003 14:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGav-0004fO-TK; Tue, 02 Dec 2003 14:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGaN-0004e6-0b for simple@optimus.ietf.org; Tue, 02 Dec 2003 14:53:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04721 for ; Tue, 2 Dec 2003 14:53:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGaJ-00076r-00 for simple@ietf.org; Tue, 02 Dec 2003 14:53:24 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGaJ-00075n-00 for simple@ietf.org; Tue, 02 Dec 2003 14:53:23 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2Jqvca025755; Tue, 2 Dec 2003 14:52:57 -0500 (EST) Message-ID: <3FCCED94.5090704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 3: spheres References: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 14:52:52 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > Hi Jonathan, > > I would like to provide some history for including the sphere in > our current geopriv authz draft. We had a very long discussion on > how to enforce repeatable time windows to implement a functionality > of the following style: > > I don't want my collegues to see my location information if I am > not at work. > > For some jobs you are able to translate this fact by listing your > regular working hours 9am to 5pm. Obviously, this does not work for > all jobs and has some further technical problems. Recognizing these > limitations Henning proposed an alternative which I personally > found very useful. > > Are you suggesting to drop it or should it be replaced by something > else? I think its useful; its merely a scope thing. I think its less important than other features (such as extensions) which are also out of scope. It also requires the presence of sphere within rpid, which we dont have at the moment. > > How do you express policies similar to the one listed above? Without sphere, a process would need to go and change the validity of a rule every day, so that it applies from 9am to 5pm each day. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 14:54:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04935 for ; Tue, 2 Dec 2003 14:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGb6-0004hp-E2 for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 14:54:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2JsC9B018085 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 14:54:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGb6-0004hc-AD for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04826; Tue, 2 Dec 2003 14:53:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGb2-0007Ai-00; Tue, 02 Dec 2003 14:54:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGb2-0007AT-00; Tue, 02 Dec 2003 14:54:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGav-0004fO-TK; Tue, 02 Dec 2003 14:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGaN-0004e6-0b for simple@optimus.ietf.org; Tue, 02 Dec 2003 14:53:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04721 for ; Tue, 2 Dec 2003 14:53:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGaJ-00076r-00 for simple@ietf.org; Tue, 02 Dec 2003 14:53:24 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGaJ-00075n-00 for simple@ietf.org; Tue, 02 Dec 2003 14:53:23 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2Jqvca025755; Tue, 2 Dec 2003 14:52:57 -0500 (EST) Message-ID: <3FCCED94.5090704@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 3: spheres References: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0485@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 14:52:52 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > Hi Jonathan, > > I would like to provide some history for including the sphere in > our current geopriv authz draft. We had a very long discussion on > how to enforce repeatable time windows to implement a functionality > of the following style: > > I don't want my collegues to see my location information if I am > not at work. > > For some jobs you are able to translate this fact by listing your > regular working hours 9am to 5pm. Obviously, this does not work for > all jobs and has some further technical problems. Recognizing these > limitations Henning proposed an alternative which I personally > found very useful. > > Are you suggesting to drop it or should it be replaced by something > else? I think its useful; its merely a scope thing. I think its less important than other features (such as extensions) which are also out of scope. It also requires the presence of sphere within rpid, which we dont have at the moment. > > How do you express policies similar to the one listed above? Without sphere, a process would need to go and change the validity of a rule every day, so that it applies from 9am to 5pm each day. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 14:54:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04997; Tue, 2 Dec 2003 14:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGbw-0007EH-00; Tue, 02 Dec 2003 14:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGbv-0007ED-00; Tue, 02 Dec 2003 14:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbs-0004ki-V4; Tue, 02 Dec 2003 14:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbi-0004kP-12 for simple@optimus.ietf.org; Tue, 02 Dec 2003 14:54:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04977 for ; Tue, 2 Dec 2003 14:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGbf-0007Dl-00 for simple@ietf.org; Tue, 02 Dec 2003 14:54:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGbe-0007BO-00 for simple@ietf.org; Tue, 02 Dec 2003 14:54:46 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2JsJca025758; Tue, 2 Dec 2003 14:54:19 -0500 (EST) Message-ID: <3FCCEDE6.5070007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 2: validity References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 14:54:14 -0500 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > >>> As such, I would propose to adopt the validity condition >> element. I >>> think its valuable, independent of any desire to align >> with geopriv. >>> >>> Comments? >> >> I agree. > > I also agree. Also, this would seem to fulfill one of the things > discussed in the on-demand authorization draft in SIPPING. Yes - I had also pointed this out during sipping. I will consider this issue closed, and will add the validity element to the next rev of the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 14:55:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05078 for ; Tue, 2 Dec 2003 14:55:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbz-0004oy-HJ for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 14:55:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Jt7nx018526 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 14:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbz-0004oj-CU for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 14:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04997; Tue, 2 Dec 2003 14:54:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGbw-0007EH-00; Tue, 02 Dec 2003 14:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGbv-0007ED-00; Tue, 02 Dec 2003 14:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbs-0004ki-V4; Tue, 02 Dec 2003 14:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGbi-0004kP-12 for simple@optimus.ietf.org; Tue, 02 Dec 2003 14:54:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04977 for ; Tue, 2 Dec 2003 14:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGbf-0007Dl-00 for simple@ietf.org; Tue, 02 Dec 2003 14:54:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGbe-0007BO-00 for simple@ietf.org; Tue, 02 Dec 2003 14:54:46 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2JsJca025758; Tue, 2 Dec 2003 14:54:19 -0500 (EST) Message-ID: <3FCCEDE6.5070007@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 2: validity References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592CB@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 14:54:14 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > >>> As such, I would propose to adopt the validity condition >> element. I >>> think its valuable, independent of any desire to align >> with geopriv. >>> >>> Comments? >> >> I agree. > > I also agree. Also, this would seem to fulfill one of the things > discussed in the on-demand authorization draft in SIPPING. Yes - I had also pointed this out during sipping. I will consider this issue closed, and will add the validity element to the next rev of the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:04:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05691; Tue, 2 Dec 2003 15:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGld-0007Qe-00; Tue, 02 Dec 2003 15:05:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGlc-0007Qa-00; Tue, 02 Dec 2003 15:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGlb-00059Y-Nr; Tue, 02 Dec 2003 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGkg-00057r-3N for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:04:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05521 for ; Tue, 2 Dec 2003 15:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGkd-0007O6-00 for simple@ietf.org; Tue, 02 Dec 2003 15:04:03 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGkb-0007Nx-00 for simple@ietf.org; Tue, 02 Dec 2003 15:04:02 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K3Vca025762; Tue, 2 Dec 2003 15:03:32 -0500 (EST) Message-ID: <3FCCF00C.60305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data types References: <3FC1A615.1010506@dynamicsoft.com> <3FC26FB5.4090105@dynamicsoft.com> In-Reply-To: <3FC26FB5.4090105@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:03:24 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth spec, there is a big assumption that each >> permission (show-element, show-namespace, accept, accept-if, etc.) is >> basically a token datatype. If multiple statements apply, the overall >> permissions are the union across these tokens. >> >> However, in the geopriv spec, they define some additional data types. >> Namely, they define boolean and integer. Combining operations are then >> also defined for these types (logical OR for booleans, MAX operator >> for integers). >> >> As an example, lets say you have a permission called "accuracy": >> >> >> sip:fluffy@cisco.com >> >> >> 10 >> >> >> >> >> cisco.com >> >> >> 5 >> >> >> This would have the effect of granting an accuracy of 5 to everyone in >> Cisco, excepting fluffy who would get 10. >> >> The question, then, is whether or not to define/allow these data types >> and also define their combining rules. NOTE WELL - you would need to >> properly define your permissions such that, for an integer, a larger >> value is always more permissive. For booleans, TRUE would need to >> always be more permissive. > > > I am having trouble understanding how this is any different than > previously proposed, at least in the case of your example. Previously, > this simply meant 2 rules matched fluffy--so if 10 is more permissive > than 5, he effectively has 10. Well, previously, the spec didnt say anything about how to combine integers. > Would this proposal allow a combination > rule that would give fluffy 15? No. It would say that, for types that are integers, the combining operation is MAX(). > > >> >> A related issue is whether or not to convert some of our current >> permissions from tokens to booleans. In particular, the accept, >> all-content and show-note permissions would become booleans. The >> benefit of that is that you can explicitly say no by setting a value >> to false: >> >> >> sip:schulzrinne@columbia.edu >> >> >> false >> >> >> would explicitly reject any subscriptions from Henning. > > > Hmm. I assume that if another matching rule sayd true > then true would win, right? Otherwise, we no longer have additive > permissions. Yes. The combining operator is OR(). Hannes writes: > You raised an interesting issue addressing rule permission combining. You > might want to take a look at our geopriv authz draft. > > The draft describes how permissions are combined for some cases. However, as > noted in the geopriv wg meeting there are still some technical issues to > achieve the expected behavior. We pointed to a subset of issues (i.e., > default behavior) in our presentation at > http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt (slide > 22/23). > > In a more sophisticated example you might even have to define a lattice. You > can find an example in Section 7.4 of our draft. > > My conclusion is that we have to look carefully at examples to verify the > result. In Jonathan's example below you need to make sure that you carefully > define what 'true' and 'false' means. The same is true for values like > accuracy. I'm confused about what the problem is. Once you define the data types and then define a combining operator, you just need to be careful about how you use them. As long as, for any integer type, a larger value is more permissive than a smaller one, you should be OK. In the case of the "provide civil location" transformation, it seems to me that this is basically an integer, whose values are mapped to a pnemonic that describes the level. So: #define NULL 0 #define COUNTRY 1 #define REGION 2 #define CITY 3 #define BUILDING 4 #define FULL 5 thus, if one statement grants you country, and another grants you building, you get building (MAX(1,4) = 4). Am I missing something? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:05:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05814 for ; Tue, 2 Dec 2003 15:05:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGlh-0005BY-Lm for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:05:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2K59Eb019926 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:05:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGlh-0005Ad-GV for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:05:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05691; Tue, 2 Dec 2003 15:04:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGld-0007Qe-00; Tue, 02 Dec 2003 15:05:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGlc-0007Qa-00; Tue, 02 Dec 2003 15:05:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGlb-00059Y-Nr; Tue, 02 Dec 2003 15:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGkg-00057r-3N for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:04:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05521 for ; Tue, 2 Dec 2003 15:03:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGkd-0007O6-00 for simple@ietf.org; Tue, 02 Dec 2003 15:04:03 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGkb-0007Nx-00 for simple@ietf.org; Tue, 02 Dec 2003 15:04:02 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K3Vca025762; Tue, 2 Dec 2003 15:03:32 -0500 (EST) Message-ID: <3FCCF00C.60305@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data types References: <3FC1A615.1010506@dynamicsoft.com> <3FC26FB5.4090105@dynamicsoft.com> In-Reply-To: <3FC26FB5.4090105@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:03:24 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth spec, there is a big assumption that each >> permission (show-element, show-namespace, accept, accept-if, etc.) is >> basically a token datatype. If multiple statements apply, the overall >> permissions are the union across these tokens. >> >> However, in the geopriv spec, they define some additional data types. >> Namely, they define boolean and integer. Combining operations are then >> also defined for these types (logical OR for booleans, MAX operator >> for integers). >> >> As an example, lets say you have a permission called "accuracy": >> >> >> sip:fluffy@cisco.com >> >> >> 10 >> >> >> >> >> cisco.com >> >> >> 5 >> >> >> This would have the effect of granting an accuracy of 5 to everyone in >> Cisco, excepting fluffy who would get 10. >> >> The question, then, is whether or not to define/allow these data types >> and also define their combining rules. NOTE WELL - you would need to >> properly define your permissions such that, for an integer, a larger >> value is always more permissive. For booleans, TRUE would need to >> always be more permissive. > > > I am having trouble understanding how this is any different than > previously proposed, at least in the case of your example. Previously, > this simply meant 2 rules matched fluffy--so if 10 is more permissive > than 5, he effectively has 10. Well, previously, the spec didnt say anything about how to combine integers. > Would this proposal allow a combination > rule that would give fluffy 15? No. It would say that, for types that are integers, the combining operation is MAX(). > > >> >> A related issue is whether or not to convert some of our current >> permissions from tokens to booleans. In particular, the accept, >> all-content and show-note permissions would become booleans. The >> benefit of that is that you can explicitly say no by setting a value >> to false: >> >> >> sip:schulzrinne@columbia.edu >> >> >> false >> >> >> would explicitly reject any subscriptions from Henning. > > > Hmm. I assume that if another matching rule sayd true > then true would win, right? Otherwise, we no longer have additive > permissions. Yes. The combining operator is OR(). Hannes writes: > You raised an interesting issue addressing rule permission combining. You > might want to take a look at our geopriv authz draft. > > The draft describes how permissions are combined for some cases. However, as > noted in the geopriv wg meeting there are still some technical issues to > achieve the expected behavior. We pointed to a subset of issues (i.e., > default behavior) in our presentation at > http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt (slide > 22/23). > > In a more sophisticated example you might even have to define a lattice. You > can find an example in Section 7.4 of our draft. > > My conclusion is that we have to look carefully at examples to verify the > result. In Jonathan's example below you need to make sure that you carefully > define what 'true' and 'false' means. The same is true for values like > accuracy. I'm confused about what the problem is. Once you define the data types and then define a combining operator, you just need to be careful about how you use them. As long as, for any integer type, a larger value is more permissive than a smaller one, you should be OK. In the case of the "provide civil location" transformation, it seems to me that this is basically an integer, whose values are mapped to a pnemonic that describes the level. So: #define NULL 0 #define COUNTRY 1 #define REGION 2 #define CITY 3 #define BUILDING 4 #define FULL 5 thus, if one statement grants you country, and another grants you building, you get building (MAX(1,4) = 4). Am I missing something? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:06:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06063; Tue, 2 Dec 2003 15:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGnV-0007Ub-00; Tue, 02 Dec 2003 15:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGnV-0007UY-00; Tue, 02 Dec 2003 15:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGnV-0005LB-Tz; Tue, 02 Dec 2003 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGmq-0005Kj-Qk for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05936 for ; Tue, 2 Dec 2003 15:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGmn-0007TS-00 for simple@ietf.org; Tue, 02 Dec 2003 15:06:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGmn-0007SG-00 for simple@ietf.org; Tue, 02 Dec 2003 15:06:17 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K5oca025765; Tue, 2 Dec 2003 15:05:50 -0500 (EST) Message-ID: <3FCCF099.9020003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> <3FC26E6F.9030908@dynamicsoft.com> In-Reply-To: <3FC26E6F.9030908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:05:45 -0500 Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth model, there is an important assumption that >> if there are no statements that apply to a watcher, the implication is >> that their subscription is pending, and that the presentity should get >> a winfo notification about the fact that its pending, so that they can >> make a policy decision. This assumption is based on another assumption >> I made, which is that the ONLY reason that a watcher would go into the >> pending state, is if you have not specified a policy for them yet. >> >> However, geopriv doesnt make this assumption. They have an element >> called "confirm-subscription". If present, it means that the >> presentity should be alerted about the subscription, and asked for >> confirmation. As a result, there is a way to EXPLICITLY say "let me >> know if this person subscribes". >> >> I think there are legitimate use cases for this, which came up during >> the geopriv meeting in Minneapolis. In particular, I may grant my boss >> permission to subscribe during the day, but during the evening, I want >> to be prompted each time, to see if I will grant it or not. >> >> To do this, we could follow their lead and add a >> "confirm-subscription" boolean, which would explicitly place the >> watcher into the pending state. >> >> I think this makes sense, and I would suggest adding this capability >> to xcap-auth. > > > I think I like this. So if we were to do this, would that mean the > default for when no rules apply would become "deny"? Yes. Generally, for any boolean type, the default is FALSE. > > This does, however, bring up a concern that I tried to express in > Minneapolis, but am not sure I ever managed to make my point. Most > existing presence systems have a concept of blocking an identity. The > additive permissions approach seems to make this difficult to implement. > If I, for example, want to block alice@example.com, I must make sure > that no other rule can possibly include alice. This is further > complicated if some of my rules apply to external lists. Even if Alice > is not on such a list today, someone might put her on one tomorrow, and > invalidate my block. The easiest way to make sure this never happens > would be to add an except clause for Alice to _every_ rule I have. That > seems pretty cumbersome and error prone. > > And yes, I understand the arguments in geopriv about black-lists being > useless. I just don't think I could sell those arguments to a customer. I think this is a separate discussion, which we are having in the thread associated with issue 8, exceptions. Do you see a specific interaction with subscription confirmation? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:07:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06139 for ; Tue, 2 Dec 2003 15:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGna-0005OB-LF for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:07:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2K76e1020697 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGnZ-0005Nk-EI for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:07:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06063; Tue, 2 Dec 2003 15:06:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGnV-0007Ub-00; Tue, 02 Dec 2003 15:07:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGnV-0007UY-00; Tue, 02 Dec 2003 15:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGnV-0005LB-Tz; Tue, 02 Dec 2003 15:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGmq-0005Kj-Qk for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:06:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05936 for ; Tue, 2 Dec 2003 15:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGmn-0007TS-00 for simple@ietf.org; Tue, 02 Dec 2003 15:06:17 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGmn-0007SG-00 for simple@ietf.org; Tue, 02 Dec 2003 15:06:17 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K5oca025765; Tue, 2 Dec 2003 15:05:50 -0500 (EST) Message-ID: <3FCCF099.9020003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> <3FC26E6F.9030908@dynamicsoft.com> In-Reply-To: <3FC26E6F.9030908@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:05:45 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth model, there is an important assumption that >> if there are no statements that apply to a watcher, the implication is >> that their subscription is pending, and that the presentity should get >> a winfo notification about the fact that its pending, so that they can >> make a policy decision. This assumption is based on another assumption >> I made, which is that the ONLY reason that a watcher would go into the >> pending state, is if you have not specified a policy for them yet. >> >> However, geopriv doesnt make this assumption. They have an element >> called "confirm-subscription". If present, it means that the >> presentity should be alerted about the subscription, and asked for >> confirmation. As a result, there is a way to EXPLICITLY say "let me >> know if this person subscribes". >> >> I think there are legitimate use cases for this, which came up during >> the geopriv meeting in Minneapolis. In particular, I may grant my boss >> permission to subscribe during the day, but during the evening, I want >> to be prompted each time, to see if I will grant it or not. >> >> To do this, we could follow their lead and add a >> "confirm-subscription" boolean, which would explicitly place the >> watcher into the pending state. >> >> I think this makes sense, and I would suggest adding this capability >> to xcap-auth. > > > I think I like this. So if we were to do this, would that mean the > default for when no rules apply would become "deny"? Yes. Generally, for any boolean type, the default is FALSE. > > This does, however, bring up a concern that I tried to express in > Minneapolis, but am not sure I ever managed to make my point. Most > existing presence systems have a concept of blocking an identity. The > additive permissions approach seems to make this difficult to implement. > If I, for example, want to block alice@example.com, I must make sure > that no other rule can possibly include alice. This is further > complicated if some of my rules apply to external lists. Even if Alice > is not on such a list today, someone might put her on one tomorrow, and > invalidate my block. The easiest way to make sure this never happens > would be to add an except clause for Alice to _every_ rule I have. That > seems pretty cumbersome and error prone. > > And yes, I understand the arguments in geopriv about black-lists being > useless. I just don't think I could sell those arguments to a customer. I think this is a separate discussion, which we are having in the thread associated with issue 8, exceptions. Do you see a specific interaction with subscription confirmation? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:08:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06280; Tue, 2 Dec 2003 15:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGov-0007WT-00; Tue, 02 Dec 2003 15:08:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGov-0007VG-00; Tue, 02 Dec 2003 15:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGoT-0005c4-3K; Tue, 02 Dec 2003 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGng-0005Qm-51 for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06090 for ; Tue, 2 Dec 2003 15:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGnc-0007Ui-00 for simple@ietf.org; Tue, 02 Dec 2003 15:07:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGnc-0007UQ-00 for simple@ietf.org; Tue, 02 Dec 2003 15:07:08 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K6fca025768; Tue, 2 Dec 2003 15:06:41 -0500 (EST) Message-ID: <3FCCF0CC.9080700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 7: actions and transformations References: <3FC1A9D7.2010105@dynamicsoft.com> <3FC26C7C.5030007@dynamicsoft.com> In-Reply-To: <3FC26C7C.5030007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:06:36 -0500 Content-Transfer-Encoding: 7bit I will go ahead and add this to the next rev of the spec. Thanks, Jonathan R. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth document, the spec describes two different >> types of permissions. These are "acceptance" permissions and "content" >> permissions. The former are permissions about who can or cannot >> subscribe in the first place. The latter are permissions about what >> they will see when they do subscribe. >> >> In geopriv, they instead have "actions" and "transformations". The >> actions are things to do - accept a subscription, confirm a >> subscription. Other possible actions in the future might be to log the >> event, send an IM, etc. Then "transformations" specify operations on >> the data that the watcher will receive. This is equivalent to what we >> call content permissions. >> >> The geopriv document separates these types of elements within the >> document through an enclosing "actions" and "transformations" tag. In >> xcap-auth, its flat, and no syntactic distinction is made between the >> two types. >> >> I would propose we adopt the geopriv terminology and xml syntax. Using >> the syntax has the benefit that, with the xcap protocol, you could >> change all of the actions or all of the transformations in one >> operation. The terminology is apparently more consistent with other >> policy languages that exist. >> >> As an example of what this change would mean, here is a document in >> the current xcap-auth format: >> >> >> sip:joe@example.com >> >> >> >> rpid >> >> >> and with this change, would look like: >> >> >> sip:joe@example.com >> >> >> >> >> >> >> >> rpid >> > > > This sounds reasonable to me. It seems to future-proof things a little > better than the original xcap-auth syntax. > >> >> >> Thanks, >> Jonathan R. >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:08:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06394 for ; Tue, 2 Dec 2003 15:08:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGoz-0005ld-Sk for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:08:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2K8XuN022163 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:08:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGoz-0005lG-B6 for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:08:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06280; Tue, 2 Dec 2003 15:08:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGov-0007WT-00; Tue, 02 Dec 2003 15:08:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGov-0007VG-00; Tue, 02 Dec 2003 15:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGoT-0005c4-3K; Tue, 02 Dec 2003 15:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGng-0005Qm-51 for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06090 for ; Tue, 2 Dec 2003 15:06:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGnc-0007Ui-00 for simple@ietf.org; Tue, 02 Dec 2003 15:07:08 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGnc-0007UQ-00 for simple@ietf.org; Tue, 02 Dec 2003 15:07:08 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2K6fca025768; Tue, 2 Dec 2003 15:06:41 -0500 (EST) Message-ID: <3FCCF0CC.9080700@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 7: actions and transformations References: <3FC1A9D7.2010105@dynamicsoft.com> <3FC26C7C.5030007@dynamicsoft.com> In-Reply-To: <3FC26C7C.5030007@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:06:36 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I will go ahead and add this to the next rev of the spec. Thanks, Jonathan R. Ben Campbell wrote: > Jonathan Rosenberg wrote: > >> Folks, >> >> In the current xcap-auth document, the spec describes two different >> types of permissions. These are "acceptance" permissions and "content" >> permissions. The former are permissions about who can or cannot >> subscribe in the first place. The latter are permissions about what >> they will see when they do subscribe. >> >> In geopriv, they instead have "actions" and "transformations". The >> actions are things to do - accept a subscription, confirm a >> subscription. Other possible actions in the future might be to log the >> event, send an IM, etc. Then "transformations" specify operations on >> the data that the watcher will receive. This is equivalent to what we >> call content permissions. >> >> The geopriv document separates these types of elements within the >> document through an enclosing "actions" and "transformations" tag. In >> xcap-auth, its flat, and no syntactic distinction is made between the >> two types. >> >> I would propose we adopt the geopriv terminology and xml syntax. Using >> the syntax has the benefit that, with the xcap protocol, you could >> change all of the actions or all of the transformations in one >> operation. The terminology is apparently more consistent with other >> policy languages that exist. >> >> As an example of what this change would mean, here is a document in >> the current xcap-auth format: >> >> >> sip:joe@example.com >> >> >> >> rpid >> >> >> and with this change, would look like: >> >> >> sip:joe@example.com >> >> >> >> >> >> >> >> rpid >> > > > This sounds reasonable to me. It seems to future-proof things a little > better than the original xcap-auth syntax. > >> >> >> Thanks, >> Jonathan R. >> >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:18:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07517; Tue, 2 Dec 2003 15:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGyb-0007jU-00; Tue, 02 Dec 2003 15:18:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGyb-0007jF-00; Tue, 02 Dec 2003 15:18:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGy9-0005xe-PR; Tue, 02 Dec 2003 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGxj-0005xQ-Ry for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07446 for ; Tue, 2 Dec 2003 15:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGxi-0007j4-00 for simple@ietf.org; Tue, 02 Dec 2003 15:17:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGxi-0007ii-00 for simple@ietf.org; Tue, 02 Dec 2003 15:17:34 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KH6ca025772; Tue, 2 Dec 2003 15:17:06 -0500 (EST) Message-ID: <3FCCF33C.9040201@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: vesa.torvinen@ericsson.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:17:00 -0500 Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > Hi Vesa, > > First of all, I don't like the single password scheme because of > two things. Distributing the key is a pain, and the more people you > deliver it to, the weaker it gets. When you stop being friends with > one of those people, re-keying is an even bigger pain. Secondly, on > the client side, I'd say this is even worse. If I have 500 buddies > in my presence application, I most certainly don't want to > (manually) manage 500 passwords, perhaps randomly delivered to me > via email/IM/SMS. When I switch on my handset, I don't want to > spend time typing in digest passwords, etc. So I just don't think > this scales enough to make it a useful functionality in a presence > system. Furthermore, I just dont think that solving this problem is in the scope of our activity. Assuming that someone, somewhere, did manage to do build a system that did this, it can easily be integrated with xcap. When you hand out passwords, you also hand out usernames (i.e., identities that can be authenticated by the system). Then, the normal applies-to field would be able to specify policies associated with that authenticated identity. So, I may be jdrosen@dynamicsoft.com, but I may have also received a username user223@dynamicsoft.com and password, which were given to me and associated with a specific context (i.e., the conference call). This point aside, I think that we do have consensus to remove the list of authentication types (basic, digest, tls, etc.) from xcap. What is not clear from the thread is whether we need a way to say "this applies to users who have not authenticated at all". I don't think this is the same as anonymous, though its similar. I'm also not sure that this would get used in practice; I'm not sure a user can understand what it means. As such, I would prefer to forgo this feature as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:18:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07574 for ; Tue, 2 Dec 2003 15:18:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGyd-000622-Tm for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:18:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KIVdx023180 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:18:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGyd-00061n-PP for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07517; Tue, 2 Dec 2003 15:18:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGyb-0007jU-00; Tue, 02 Dec 2003 15:18:29 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARGyb-0007jF-00; Tue, 02 Dec 2003 15:18:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGy9-0005xe-PR; Tue, 02 Dec 2003 15:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGxj-0005xQ-Ry for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:17:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07446 for ; Tue, 2 Dec 2003 15:17:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGxi-0007j4-00 for simple@ietf.org; Tue, 02 Dec 2003 15:17:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGxi-0007ii-00 for simple@ietf.org; Tue, 02 Dec 2003 15:17:34 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KH6ca025772; Tue, 2 Dec 2003 15:17:06 -0500 (EST) Message-ID: <3FCCF33C.9040201@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: vesa.torvinen@ericsson.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592DC@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:17:00 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. aki.niemi@nokia.com wrote: > Hi Vesa, > > First of all, I don't like the single password scheme because of > two things. Distributing the key is a pain, and the more people you > deliver it to, the weaker it gets. When you stop being friends with > one of those people, re-keying is an even bigger pain. Secondly, on > the client side, I'd say this is even worse. If I have 500 buddies > in my presence application, I most certainly don't want to > (manually) manage 500 passwords, perhaps randomly delivered to me > via email/IM/SMS. When I switch on my handset, I don't want to > spend time typing in digest passwords, etc. So I just don't think > this scales enough to make it a useful functionality in a presence > system. Furthermore, I just dont think that solving this problem is in the scope of our activity. Assuming that someone, somewhere, did manage to do build a system that did this, it can easily be integrated with xcap. When you hand out passwords, you also hand out usernames (i.e., identities that can be authenticated by the system). Then, the normal applies-to field would be able to specify policies associated with that authenticated identity. So, I may be jdrosen@dynamicsoft.com, but I may have also received a username user223@dynamicsoft.com and password, which were given to me and associated with a specific context (i.e., the conference call). This point aside, I think that we do have consensus to remove the list of authentication types (basic, digest, tls, etc.) from xcap. What is not clear from the thread is whether we need a way to say "this applies to users who have not authenticated at all". I don't think this is the same as anonymous, though its similar. I'm also not sure that this would get used in practice; I'm not sure a user can understand what it means. As such, I would prefer to forgo this feature as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:20:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07707; Tue, 2 Dec 2003 15:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARH0k-0007mK-00; Tue, 02 Dec 2003 15:20:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARH0j-0007lq-00; Tue, 02 Dec 2003 15:20:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARH09-0006Bh-H8; Tue, 02 Dec 2003 15:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGzt-0006A7-Ls for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07644 for ; Tue, 2 Dec 2003 15:19:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGzs-0007lD-00 for simple@ietf.org; Tue, 02 Dec 2003 15:19:48 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGzr-0007kY-00 for simple@ietf.org; Tue, 02 Dec 2003 15:19:47 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KJLca025775; Tue, 2 Dec 2003 15:19:21 -0500 (EST) Message-ID: <3FCCF3C4.2040003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions References: <3FC19D75.3040800@dynamicsoft.com> <1069790716.955.24.camel@RjS.localdomain> In-Reply-To: <1069790716.955.24.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:19:16 -0500 Content-Transfer-Encoding: 7bit inline. Robert Sparks wrote: > I agree that moving the conditional from an accept-if into > the applies-to tag is the right thing to do. > > There is at least one ramification that needs to be carefully documented > if we do this. > > There needs to be a way to say things like "I'll accept (whatever) > if it is authenticated using either Digest or an S/MIME signature." > > In xcap-auth-01, I think this was acheivable with multiple accept-if's > inside a permission (but am not sure where I got this idea - accept-if > is missing from the schema). Yes, that was the idea, although this was far from clear from the spec. > > With this proposed change, we will have to either have to > have multiple permissions (one that accepts if digest and another > that accepts if s/mime) or add an OR function to the list of things > in applies-to. Right. I think we would eventually define boolean operators, and that this would be the right way to do it. In the interim, use multiple statements. I can document that. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:21:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07738 for ; Tue, 2 Dec 2003 15:21:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARH0o-0006Go-4j for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:20:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KKjl2024103 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:20:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARH0m-0006GX-MT for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07707; Tue, 2 Dec 2003 15:20:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARH0k-0007mK-00; Tue, 02 Dec 2003 15:20:42 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARH0j-0007lq-00; Tue, 02 Dec 2003 15:20:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARH09-0006Bh-H8; Tue, 02 Dec 2003 15:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARGzt-0006A7-Ls for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:19:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07644 for ; Tue, 2 Dec 2003 15:19:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARGzs-0007lD-00 for simple@ietf.org; Tue, 02 Dec 2003 15:19:48 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARGzr-0007kY-00 for simple@ietf.org; Tue, 02 Dec 2003 15:19:47 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KJLca025775; Tue, 2 Dec 2003 15:19:21 -0500 (EST) Message-ID: <3FCCF3C4.2040003@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment, issue 1: conditions References: <3FC19D75.3040800@dynamicsoft.com> <1069790716.955.24.camel@RjS.localdomain> In-Reply-To: <1069790716.955.24.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:19:16 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Robert Sparks wrote: > I agree that moving the conditional from an accept-if into > the applies-to tag is the right thing to do. > > There is at least one ramification that needs to be carefully documented > if we do this. > > There needs to be a way to say things like "I'll accept (whatever) > if it is authenticated using either Digest or an S/MIME signature." > > In xcap-auth-01, I think this was acheivable with multiple accept-if's > inside a permission (but am not sure where I got this idea - accept-if > is missing from the schema). Yes, that was the idea, although this was far from clear from the spec. > > With this proposed change, we will have to either have to > have multiple permissions (one that accepts if digest and another > that accepts if s/mime) or add an OR function to the list of things > in applies-to. Right. I think we would eventually define boolean operators, and that this would be the right way to do it. In the interim, use multiple statements. I can document that. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:45:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09606; Tue, 2 Dec 2003 15:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHPI-0000PU-00; Tue, 02 Dec 2003 15:46:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHPI-0000PR-00; Tue, 02 Dec 2003 15:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHPG-0007tD-6Q; Tue, 02 Dec 2003 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHP8-0007sX-2f for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:45:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09586 for ; Tue, 2 Dec 2003 15:45:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHP6-0000Ox-00 for simple@ietf.org; Tue, 02 Dec 2003 15:45:52 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARHP5-0000OA-00 for simple@ietf.org; Tue, 02 Dec 2003 15:45:51 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KjQca025798; Tue, 2 Dec 2003 15:45:26 -0500 (EST) Message-ID: <3FCCF9E1.9020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Couple of issues about partial notification draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:45:21 -0500 Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > Hi, > > I am currently writing an update to draft-ietf-simple-partial-notify-00 > and there seems to be couple of issues which probably need some discussion. > > -Security Considerations section: > 01 version currently has following security considerations section > > "Presence information may contain highly sensitive information about > the presentities. The protocol used to distribute it SHOULD ensure > privacy, message integrity and authentication. Furthermore, the > protocol should provide access controls which restrict who can see > who else's presence information. Presence related security > considerations are extensively discussed in > [draft-ietf-simple-presence-10] and all those > identified security consideration apply to this document as well. > Partial notification mechanism does not add any new considerations > and relies on the mechanisms specified in > [draft-ietf-simple-presence-10] and [RFC3261]" > > Do people on the list think this is sufficient or is there a need to > have more text about security in this draft? I think you should spend a few sentences on why partial notifications doesnt add any security considerations beyond regular presence. Once you do that, you should reference draft-ietf-simple-presence, but also restate what those requirements are. > > - IMPP interoperability > Partial notification mechanism is not compatible with IMPP work. I think > it might be good to have own chapter about this in the draft. Basically > I think it should say that mechanism does not by default work with other > IMPP compliant systems but this should not be an issue as partial > notifications will not be used if requesting end does not understand it. You might also mention that another impp compliant system could add support for partial notifications as well, and so long as that protocol had a way to indicate support for it, a gateway could be built that preserves e2e integrity with usage of partial notifications. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:46:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09671 for ; Tue, 2 Dec 2003 15:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHPK-0007u3-GU for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:46:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2Kk6Im030373 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHPK-0007to-Cl for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:46:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09606; Tue, 2 Dec 2003 15:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHPI-0000PU-00; Tue, 02 Dec 2003 15:46:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHPI-0000PR-00; Tue, 02 Dec 2003 15:46:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHPG-0007tD-6Q; Tue, 02 Dec 2003 15:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHP8-0007sX-2f for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:45:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09586 for ; Tue, 2 Dec 2003 15:45:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHP6-0000Ox-00 for simple@ietf.org; Tue, 02 Dec 2003 15:45:52 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARHP5-0000OA-00 for simple@ietf.org; Tue, 02 Dec 2003 15:45:51 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2KjQca025798; Tue, 2 Dec 2003 15:45:26 -0500 (EST) Message-ID: <3FCCF9E1.9020409@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Couple of issues about partial notification draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D17264@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:45:21 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit mikko.lonnfors@nokia.com wrote: > Hi, > > I am currently writing an update to draft-ietf-simple-partial-notify-00 > and there seems to be couple of issues which probably need some discussion. > > -Security Considerations section: > 01 version currently has following security considerations section > > "Presence information may contain highly sensitive information about > the presentities. The protocol used to distribute it SHOULD ensure > privacy, message integrity and authentication. Furthermore, the > protocol should provide access controls which restrict who can see > who else's presence information. Presence related security > considerations are extensively discussed in > [draft-ietf-simple-presence-10] and all those > identified security consideration apply to this document as well. > Partial notification mechanism does not add any new considerations > and relies on the mechanisms specified in > [draft-ietf-simple-presence-10] and [RFC3261]" > > Do people on the list think this is sufficient or is there a need to > have more text about security in this draft? I think you should spend a few sentences on why partial notifications doesnt add any security considerations beyond regular presence. Once you do that, you should reference draft-ietf-simple-presence, but also restate what those requirements are. > > - IMPP interoperability > Partial notification mechanism is not compatible with IMPP work. I think > it might be good to have own chapter about this in the draft. Basically > I think it should say that mechanism does not by default work with other > IMPP compliant systems but this should not be an issue as partial > notifications will not be used if requesting end does not understand it. You might also mention that another impp compliant system could add support for partial notifications as well, and so long as that protocol had a way to indicate support for it, a gateway could be built that preserves e2e integrity with usage of partial notifications. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 2 15:59:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10313; Tue, 2 Dec 2003 15:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHcA-0000gV-00; Tue, 02 Dec 2003 15:59:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHcA-0000g5-00; Tue, 02 Dec 2003 15:59:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHbo-0008Lu-UY; Tue, 02 Dec 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHbP-0008LO-Ob for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10272 for ; Tue, 2 Dec 2003 15:58:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHbN-0000f3-00 for simple@ietf.org; Tue, 02 Dec 2003 15:58:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARHbN-0000eA-00 for simple@ietf.org; Tue, 02 Dec 2003 15:58:33 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2Kw1ca025802; Tue, 2 Dec 2003 15:58:01 -0500 (EST) Message-ID: <3FCCFCD4.4050109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Dirk.Trossen@nokia.com, Ben Campbell , Hisham Khartabil , simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <1070039253.935.37.camel@RjS.localdomain> In-Reply-To: <1070039253.935.37.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:57:56 -0500 Content-Transfer-Encoding: 7bit I wanted to float a proposal that Ben made to me privately. Not sure if it will help here. The suggestion is to move the domain and on-list elements into this separate specification as well. The logic here is that, if you do support policies based on domains or lists, you need exception processing for them to work. Since the two go hand in hand, but them in a separate spec. Thus, the main spec would just deal with permissions granted to specific users, and the extension spec deals with group and domain permissions. Would people be comfortable with that? Thanks, Jonathan R. Robert Sparks wrote: > On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Robert Sparks >>>Sent: Wednesday, November 26, 2003 1:36 AM >>>To: Ben Campbell >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>simple@ietf.org >>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>> >>> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >>> >> >>Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? > > > You should conclude from this that there are environments in which > being able to state exceptions is not a requirement. > > >>I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. > > > I also believe exceptions would be useful. Very useful. I'm not arguing > against supporting them. I am suggesting that it would be acceptable to > have a base system that _didn't_ have them and an extension that does. > > > >>Dirk > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 2 15:59:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10405 for ; Tue, 2 Dec 2003 15:59:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHcD-0008O3-5g for simple-archive@odin.ietf.org; Tue, 02 Dec 2003 15:59:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2KxPkS032238 for simple-archive@odin.ietf.org; Tue, 2 Dec 2003 15:59:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHcD-0008Nt-2G for simple-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 15:59:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10313; Tue, 2 Dec 2003 15:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHcA-0000gV-00; Tue, 02 Dec 2003 15:59:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARHcA-0000g5-00; Tue, 02 Dec 2003 15:59:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHbo-0008Lu-UY; Tue, 02 Dec 2003 15:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARHbP-0008LO-Ob for simple@optimus.ietf.org; Tue, 02 Dec 2003 15:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10272 for ; Tue, 2 Dec 2003 15:58:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARHbN-0000f3-00 for simple@ietf.org; Tue, 02 Dec 2003 15:58:34 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARHbN-0000eA-00 for simple@ietf.org; Tue, 02 Dec 2003 15:58:33 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB2Kw1ca025802; Tue, 2 Dec 2003 15:58:01 -0500 (EST) Message-ID: <3FCCFCD4.4050109@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sparks CC: Dirk.Trossen@nokia.com, Ben Campbell , Hisham Khartabil , simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: <1070039253.935.37.camel@RjS.localdomain> In-Reply-To: <1070039253.935.37.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:57:56 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I wanted to float a proposal that Ben made to me privately. Not sure if it will help here. The suggestion is to move the domain and on-list elements into this separate specification as well. The logic here is that, if you do support policies based on domains or lists, you need exception processing for them to work. Since the two go hand in hand, but them in a separate spec. Thus, the main spec would just deal with permissions granted to specific users, and the extension spec deals with group and domain permissions. Would people be comfortable with that? Thanks, Jonathan R. Robert Sparks wrote: > On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >>>-----Original Message----- >>>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Robert Sparks >>>Sent: Wednesday, November 26, 2003 1:36 AM >>>To: Ben Campbell >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>simple@ietf.org >>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>> >>> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >>> >> >>Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? > > > You should conclude from this that there are environments in which > being able to state exceptions is not a requirement. > > >>I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. > > > I also believe exceptions would be useful. Very useful. I'm not arguing > against supporting them. I am suggesting that it would be acceptable to > have a base system that _didn't_ have them and an extension that does. > > > >>Dirk > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 3 08:45:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14677; Wed, 3 Dec 2003 08:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXKT-00014y-00; Wed, 03 Dec 2003 08:46:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARXKT-00014v-00; Wed, 03 Dec 2003 08:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXKL-0005ex-E2; Wed, 03 Dec 2003 08:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXJN-0005bW-Eb for simple@optimus.ietf.org; Wed, 03 Dec 2003 08:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14624 for ; Wed, 3 Dec 2003 08:44:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJM-00013g-00 for simple@ietf.org; Wed, 03 Dec 2003 08:45:00 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJL-00013d-00 for simple@ietf.org; Wed, 03 Dec 2003 08:44:59 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB3Div219937; Wed, 3 Dec 2003 14:44:57 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB3DiuP10107; Wed, 3 Dec 2003 14:44:56 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 14:44:36 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Ben Campbell Cc: Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data type s MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 14:43:35 +0100 # hi jonathan, # please see my comment inline: # ~~snip~~ > Hannes writes: > > You raised an interesting issue addressing rule permission > combining. You > > might want to take a look at our geopriv authz draft. > > > > The draft describes how permissions are combined for some > cases. However, as > > noted in the geopriv wg meeting there are still some > technical issues to > > achieve the expected behavior. We pointed to a subset of > issues (i.e., > > default behavior) in our presentation at > > http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt (slide > 22/23). > > In a more sophisticated example you might even have to define a lattice. You > can find an example in Section 7.4 of our draft. > > My conclusion is that we have to look carefully at examples to verify the > result. In Jonathan's example below you need to make sure that you carefully > define what 'true' and 'false' means. The same is true for values like > accuracy. I'm confused about what the problem is. Once you define the data types and then define a combining operator, you just need to be careful about how you use them. As long as, for any integer type, a larger value is more permissive than a smaller one, you should be OK. In the case of the "provide civil location" transformation, it seems to me that this is basically an integer, whose values are mapped to a pnemonic that describes the level. So: #define NULL 0 #define COUNTRY 1 #define REGION 2 #define CITY 3 #define BUILDING 4 #define FULL 5 thus, if one statement grants you country, and another grants you building, you get building (MAX(1,4) = 4). Am I missing something? # you miss nothing here. i think that the description in the draft is easy to follow. for future extensions it might be possible that the lattice is more complex and you need to follow the same procedure. # have you looked at the slides (as indicated above). there you see an example where you have the combination with a default rule where the result is counter-intuitive. we still need to address these issues in a future version of the draft. # ciao # hannes -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Wed Dec 3 08:46:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14698 for ; Wed, 3 Dec 2003 08:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXKV-0005fm-HW for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 08:46:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3DkBGG021800 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 08:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXKV-0005fX-CP for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 08:46:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14677; Wed, 3 Dec 2003 08:45:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXKT-00014y-00; Wed, 03 Dec 2003 08:46:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARXKT-00014v-00; Wed, 03 Dec 2003 08:46:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXKL-0005ex-E2; Wed, 03 Dec 2003 08:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXJN-0005bW-Eb for simple@optimus.ietf.org; Wed, 03 Dec 2003 08:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14624 for ; Wed, 3 Dec 2003 08:44:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJM-00013g-00 for simple@ietf.org; Wed, 03 Dec 2003 08:45:00 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx with esmtp (Exim 4.12) id 1ARXJL-00013d-00 for simple@ietf.org; Wed, 03 Dec 2003 08:44:59 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.11.7/8.11.7) with ESMTP id hB3Div219937; Wed, 3 Dec 2003 14:44:57 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB3DiuP10107; Wed, 3 Dec 2003 14:44:56 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 14:44:36 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" , Ben Campbell Cc: Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data type s MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 14:43:35 +0100 # hi jonathan, # please see my comment inline: # ~~snip~~ > Hannes writes: > > You raised an interesting issue addressing rule permission > combining. You > > might want to take a look at our geopriv authz draft. > > > > The draft describes how permissions are combined for some > cases. However, as > > noted in the geopriv wg meeting there are still some > technical issues to > > achieve the expected behavior. We pointed to a subset of > issues (i.e., > > default behavior) in our presentation at > > http://www.tschofenig.com/geopriv/IETF58/Geopriv_policies_ietf58.ppt (slide > 22/23). > > In a more sophisticated example you might even have to define a lattice. You > can find an example in Section 7.4 of our draft. > > My conclusion is that we have to look carefully at examples to verify the > result. In Jonathan's example below you need to make sure that you carefully > define what 'true' and 'false' means. The same is true for values like > accuracy. I'm confused about what the problem is. Once you define the data types and then define a combining operator, you just need to be careful about how you use them. As long as, for any integer type, a larger value is more permissive than a smaller one, you should be OK. In the case of the "provide civil location" transformation, it seems to me that this is basically an integer, whose values are mapped to a pnemonic that describes the level. So: #define NULL 0 #define COUNTRY 1 #define REGION 2 #define CITY 3 #define BUILDING 4 #define FULL 5 thus, if one statement grants you country, and another grants you building, you get building (MAX(1,4) = 4). Am I missing something? # you miss nothing here. i think that the description in the draft is easy to follow. for future extensions it might be possible that the lattice is more complex and you need to follow the same procedure. # have you looked at the slides (as indicated above). there you see an example where you have the combination with a default rule where the result is counter-intuitive. we still need to address these issues in a future version of the draft. # ciao # hannes -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Wed Dec 3 08:55:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15091; Wed, 3 Dec 2003 08:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXU5-0001LQ-00; Wed, 03 Dec 2003 08:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARXU5-0001LN-00; Wed, 03 Dec 2003 08:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXU2-000626-D4; Wed, 03 Dec 2003 08:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXTe-00061Q-PR for simple@optimus.ietf.org; Wed, 03 Dec 2003 08:55:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15081 for ; Wed, 3 Dec 2003 08:55:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXTd-0001Kq-00 for simple@ietf.org; Wed, 03 Dec 2003 08:55:37 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARXTc-0001Km-00 for simple@ietf.org; Wed, 03 Dec 2003 08:55:36 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3DtZw08261 for ; Wed, 3 Dec 2003 15:55:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 15:55:35 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 15:55:35 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 15:55:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQ To: , Cc: , , , X-OriginalArrivalTime: 03 Dec 2003 13:55:34.0671 (UTC) FILETIME=[1F8EF1F0:01C3B9A5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 15:55:33 +0200 Content-Transfer-Encoding: quoted-printable Hi, I agree with the logic that domain and exception are closely linked, and = maybe also the external list. It would be OK to do these as a separate specification. However, I think = they are extremely important, and this separate specification should be = done ASAP, preferably at the same time as the baseline specification. At = least we have no use for XCAP-based authorization in our products if = domains, external lists and exceptions are not supported. I think they = are also requirements for 3GPP's presence work. So, to put it simply: I have a strong opinion that domain, external list = and exception are needed in the initial phase. Regards, Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 02 December, 2003 22:58 > To: Robert Sparks > Cc: Trossen Dirk (NRC/Boston); Ben Campbell; Khartabil Hisham > (NMP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > I wanted to float a proposal that Ben made to me privately. Not sure=20 > if it will help here. >=20 > The suggestion is to move the domain and on-list elements into this=20 > separate specification as well. The logic here is that, if you do=20 > support policies based on domains or lists, you need exception=20 > processing for them to work. Since the two go hand in hand, but them=20 > in a separate spec. Thus, the main spec would just deal with=20 > permissions granted to specific users, and the extension spec deals=20 > with group and domain permissions. >=20 > Would people be comfortable with that? >=20 > Thanks, > Jonathan R. >=20 > Robert Sparks wrote: >=20 > > On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >=20 > >>>-----Original Message----- > >>>From: simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Robert Sparks >>>Sent: Wednesday, November 26, 2003 1:36 AM >>>To: Ben Campbell >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>simple@ietf.org >>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>> >>> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >>> >> >>Shall we conclude from this that current restrictions of systems is a = useful measure to build future systems? >=20 >=20 > You should conclude from this that there are environments in which > being able to state exceptions is not a requirement.=20 >=20 >=20 >>I do believe that exceptions would be useful, in particular in = inter-domain and interoperable systems. Since I believe that's what is = tried to be built, exceptions should be considered.=20 >=20 >=20 > I also believe exceptions would be useful. Very useful. I'm not = arguing > against supporting them. I am suggesting that it would be acceptable = to > have a base system that _didn't_ have them and an extension that does. >=20 >=20 >=20 >>Dirk >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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 exim@www1.ietf.org Wed Dec 3 08:56:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15110 for ; Wed, 3 Dec 2003 08:56:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXU7-000639-Iw for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 08:56:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Du7av023249 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 08:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXU7-00062u-Eh for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 08:56:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15091; Wed, 3 Dec 2003 08:55:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXU5-0001LQ-00; Wed, 03 Dec 2003 08:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARXU5-0001LN-00; Wed, 03 Dec 2003 08:56:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXU2-000626-D4; Wed, 03 Dec 2003 08:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARXTe-00061Q-PR for simple@optimus.ietf.org; Wed, 03 Dec 2003 08:55:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15081 for ; Wed, 3 Dec 2003 08:55:23 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARXTd-0001Kq-00 for simple@ietf.org; Wed, 03 Dec 2003 08:55:37 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARXTc-0001Km-00 for simple@ietf.org; Wed, 03 Dec 2003 08:55:36 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3DtZw08261 for ; Wed, 3 Dec 2003 15:55:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Dec 2003 15:55:35 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 15:55:35 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 3 Dec 2003 15:55:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] xcap/geopriv alignment issue 8: exceptions Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQ To: , Cc: , , , X-OriginalArrivalTime: 03 Dec 2003 13:55:34.0671 (UTC) FILETIME=[1F8EF1F0:01C3B9A5] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 15:55:33 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I agree with the logic that domain and exception are closely linked, and = maybe also the external list. It would be OK to do these as a separate specification. However, I think = they are extremely important, and this separate specification should be = done ASAP, preferably at the same time as the baseline specification. At = least we have no use for XCAP-based authorization in our products if = domains, external lists and exceptions are not supported. I think they = are also requirements for 3GPP's presence work. So, to put it simply: I have a strong opinion that domain, external list = and exception are needed in the initial phase. Regards, Markus > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Jonathan Rosenberg > Sent: 02 December, 2003 22:58 > To: Robert Sparks > Cc: Trossen Dirk (NRC/Boston); Ben Campbell; Khartabil Hisham > (NMP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >=20 >=20 > I wanted to float a proposal that Ben made to me privately. Not sure=20 > if it will help here. >=20 > The suggestion is to move the domain and on-list elements into this=20 > separate specification as well. The logic here is that, if you do=20 > support policies based on domains or lists, you need exception=20 > processing for them to work. Since the two go hand in hand, but them=20 > in a separate spec. Thus, the main spec would just deal with=20 > permissions granted to specific users, and the extension spec deals=20 > with group and domain permissions. >=20 > Would people be comfortable with that? >=20 > Thanks, > Jonathan R. >=20 > Robert Sparks wrote: >=20 > > On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: > >=20 > >>>-----Original Message----- > >>>From: simple-admin@ietf.org=20 [mailto:simple-admin@ietf.org]On Behalf Of >>>ext Robert Sparks >>>Sent: Wednesday, November 26, 2003 1:36 AM >>>To: Ben Campbell >>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>simple@ietf.org >>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>> >>> >>>(speaking from the floor) >>> >>>In the presence/IM systems I've been using on a daily basis for >>>some time now, I do not have a way to say "Allow everybody in >>>foo.com except bar" and I still find these systems useful. >>> >> >>Shall we conclude from this that current restrictions of systems is a = useful measure to build future systems? >=20 >=20 > You should conclude from this that there are environments in which > being able to state exceptions is not a requirement.=20 >=20 >=20 >>I do believe that exceptions would be useful, in particular in = inter-domain and interoperable systems. Since I believe that's what is = tried to be built, exceptions should be considered.=20 >=20 >=20 > I also believe exceptions would be useful. Very useful. I'm not = arguing > against supporting them. I am suggesting that it would be acceptable = to > have a base system that _didn't_ have them and an extension that does. >=20 >=20 >=20 >>Dirk >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ 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-admin@ietf.org Wed Dec 3 09:52:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17161; Wed, 3 Dec 2003 09:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYNJ-0002R9-00; Wed, 03 Dec 2003 09:53:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYNJ-0002R3-00; Wed, 03 Dec 2003 09:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYNC-0000Py-2z; Wed, 03 Dec 2003 09:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYMs-0000Ot-7X for simple@optimus.ietf.org; Wed, 03 Dec 2003 09:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17140 for ; Wed, 3 Dec 2003 09:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYMq-0002QW-00 for simple@ietf.org; Wed, 03 Dec 2003 09:52:40 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARYMp-0002QT-00 for simple@ietf.org; Wed, 03 Dec 2003 09:52:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB3EqOnG085917; Wed, 3 Dec 2003 08:52:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCDF893.7010608@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, Dirk.Trossen@nokia.com, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 08:52:03 -0600 Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I agree with the logic that domain and exception are closely linked, and maybe also the external list. > > It would be OK to do these as a separate specification. However, I think they are extremely important, and this separate specification should be done ASAP, preferably at the same time as the baseline specification. At least we have no use for XCAP-based authorization in our products if domains, external lists and exceptions are not supported. I think they are also requirements for 3GPP's presence work. > > So, to put it simply: I have a strong opinion that domain, external list and exception are needed in the initial phase. Agreed. When Jonathan and I talked off-line about this, we also discussed that the core spec and the extension draft should come out at roughly the same time. > > Regards, > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 02 December, 2003 22:58 >>To: Robert Sparks >>Cc: Trossen Dirk (NRC/Boston); Ben Campbell; Khartabil Hisham >>(NMP-MSW/Helsinki); simple@ietf.org >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>I wanted to float a proposal that Ben made to me privately. Not sure >>if it will help here. >> >>The suggestion is to move the domain and on-list elements into this >>separate specification as well. The logic here is that, if you do >>support policies based on domains or lists, you need exception >>processing for them to work. Since the two go hand in hand, but them >>in a separate spec. Thus, the main spec would just deal with >>permissions granted to specific users, and the extension spec deals >>with group and domain permissions. >> >>Would people be comfortable with that? >> >>Thanks, >>Jonathan R. >> >>Robert Sparks wrote: >> >> >>>On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: >>> >>> >>>>>-----Original Message----- >>>>>From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > >>>>ext Robert Sparks >>>>Sent: Wednesday, November 26, 2003 1:36 AM >>>>To: Ben Campbell >>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>>simple@ietf.org >>>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>>> >>>> >>>>(speaking from the floor) >>>> >>>>In the presence/IM systems I've been using on a daily basis for >>>>some time now, I do not have a way to say "Allow everybody in >>>>foo.com except bar" and I still find these systems useful. >>>> >>> >>>Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? >> >> >>You should conclude from this that there are environments in which >>being able to state exceptions is not a requirement. >> >> >> >>>I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. >> >> >>I also believe exceptions would be useful. Very useful. I'm not arguing >>against supporting them. I am suggesting that it would be acceptable to >>have a base system that _didn't_ have them and an extension that does. >> >> >> >> >>>Dirk >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 3 09:53:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAB17225 for ; Wed, 3 Dec 2003 09:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYNM-0000Ra-L1 for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 09:53:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3ErCpB001706 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 09:53:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYNM-0000RR-HT for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 09:53:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17161; Wed, 3 Dec 2003 09:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYNJ-0002R9-00; Wed, 03 Dec 2003 09:53:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARYNJ-0002R3-00; Wed, 03 Dec 2003 09:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYNC-0000Py-2z; Wed, 03 Dec 2003 09:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARYMs-0000Ot-7X for simple@optimus.ietf.org; Wed, 03 Dec 2003 09:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17140 for ; Wed, 3 Dec 2003 09:52:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARYMq-0002QW-00 for simple@ietf.org; Wed, 03 Dec 2003 09:52:40 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARYMp-0002QT-00 for simple@ietf.org; Wed, 03 Dec 2003 09:52:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB3EqOnG085917; Wed, 3 Dec 2003 08:52:35 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCDF893.7010608@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: jdrosen@dynamicsoft.com, rsparks@dynamicsoft.com, Dirk.Trossen@nokia.com, hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 08:52:03 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus.Isomaki@nokia.com wrote: > Hi, > > I agree with the logic that domain and exception are closely linked, and maybe also the external list. > > It would be OK to do these as a separate specification. However, I think they are extremely important, and this separate specification should be done ASAP, preferably at the same time as the baseline specification. At least we have no use for XCAP-based authorization in our products if domains, external lists and exceptions are not supported. I think they are also requirements for 3GPP's presence work. > > So, to put it simply: I have a strong opinion that domain, external list and exception are needed in the initial phase. Agreed. When Jonathan and I talked off-line about this, we also discussed that the core spec and the extension draft should come out at roughly the same time. > > Regards, > Markus > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Jonathan Rosenberg >>Sent: 02 December, 2003 22:58 >>To: Robert Sparks >>Cc: Trossen Dirk (NRC/Boston); Ben Campbell; Khartabil Hisham >>(NMP-MSW/Helsinki); simple@ietf.org >>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >> >> >>I wanted to float a proposal that Ben made to me privately. Not sure >>if it will help here. >> >>The suggestion is to move the domain and on-list elements into this >>separate specification as well. The logic here is that, if you do >>support policies based on domains or lists, you need exception >>processing for them to work. Since the two go hand in hand, but them >>in a separate spec. Thus, the main spec would just deal with >>permissions granted to specific users, and the extension spec deals >>with group and domain permissions. >> >>Would people be comfortable with that? >> >>Thanks, >>Jonathan R. >> >>Robert Sparks wrote: >> >> >>>On Wed, 2003-11-26 at 08:41, Dirk.Trossen@nokia.com wrote: >>> >>> >>>>>-----Original Message----- >>>>>From: simple-admin@ietf.org > > [mailto:simple-admin@ietf.org]On Behalf Of > >>>>ext Robert Sparks >>>>Sent: Wednesday, November 26, 2003 1:36 AM >>>>To: Ben Campbell >>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); jdrosen@dynamicsoft.com; >>>>simple@ietf.org >>>>Subject: Re: [Simple] xcap/geopriv alignment issue 8: exceptions >>>> >>>> >>>>(speaking from the floor) >>>> >>>>In the presence/IM systems I've been using on a daily basis for >>>>some time now, I do not have a way to say "Allow everybody in >>>>foo.com except bar" and I still find these systems useful. >>>> >>> >>>Shall we conclude from this that current restrictions of systems is a useful measure to build future systems? >> >> >>You should conclude from this that there are environments in which >>being able to state exceptions is not a requirement. >> >> >> >>>I do believe that exceptions would be useful, in particular in inter-domain and interoperable systems. Since I believe that's what is tried to be built, exceptions should be considered. >> >> >>I also believe exceptions would be useful. Very useful. I'm not arguing >>against supporting them. I am suggesting that it would be acceptable to >>have a base system that _didn't_ have them and an extension that does. >> >> >> >> >>>Dirk >> >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 3 11:06:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21281; Wed, 3 Dec 2003 11:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZWv-0003YD-00; Wed, 03 Dec 2003 11:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZWv-0003YA-00; Wed, 03 Dec 2003 11:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWn-0004oc-KF; Wed, 03 Dec 2003 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWD-0004oD-Hl for simple@optimus.ietf.org; Wed, 03 Dec 2003 11:06:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21260 for ; Wed, 3 Dec 2003 11:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZW9-0003Xh-00 for simple@ietf.org; Wed, 03 Dec 2003 11:06:21 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARZW8-0003X3-00 for simple@ietf.org; Wed, 03 Dec 2003 11:06:20 -0500 Received: from dynamicsoft.com ([63.113.46.43]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB3G5rca026187; Wed, 3 Dec 2003 11:05:53 -0500 (EST) Message-ID: <3FCE09D5.4020703@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Ben Campbell , Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data type s References: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 11:05:41 -0500 Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > > I'm confused about what the problem is. Once you define the data types > and then define a combining operator, you just need to be careful > about how you use them. As long as, for any integer type, a larger > value is more permissive than a smaller one, you should be OK. > > In the case of the "provide civil location" transformation, it seems > to me that this is basically an integer, whose values are mapped to a > pnemonic that describes the level. So: > > #define NULL 0 > #define COUNTRY 1 > #define REGION 2 > #define CITY 3 > #define BUILDING 4 > #define FULL 5 > > thus, if one statement grants you country, and another grants you > building, you get building (MAX(1,4) = 4). > > Am I missing something? > > # you miss nothing here. i think that the description in the draft is easy > to follow. for future extensions it might be possible that the lattice is > more complex and you need to follow the same procedure. > > # have you looked at the slides (as indicated above). there you see an > example where you have the combination with a default rule where the result > is counter-intuitive. we still need to address these issues in a future > version of the draft. I did look at the slides, but I dont see or understand the problem. WHy is the result counter-intuitive? It says that the civil location that gets distributed is at the city level, and the D flag is TRUE. Seems OK to me... maybe I am missing something... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 3 11:07:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21322 for ; Wed, 3 Dec 2003 11:07:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWz-0004rK-3p for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 11:07:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3G7Ce8018658 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 11:07:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWy-0004qp-G2 for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:07:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21281; Wed, 3 Dec 2003 11:06:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZWv-0003YD-00; Wed, 03 Dec 2003 11:07:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZWv-0003YA-00; Wed, 03 Dec 2003 11:07:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWn-0004oc-KF; Wed, 03 Dec 2003 11:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZWD-0004oD-Hl for simple@optimus.ietf.org; Wed, 03 Dec 2003 11:06:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21260 for ; Wed, 3 Dec 2003 11:06:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZW9-0003Xh-00 for simple@ietf.org; Wed, 03 Dec 2003 11:06:21 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARZW8-0003X3-00 for simple@ietf.org; Wed, 03 Dec 2003 11:06:20 -0500 Received: from dynamicsoft.com ([63.113.46.43]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB3G5rca026187; Wed, 3 Dec 2003 11:05:53 -0500 (EST) Message-ID: <3FCE09D5.4020703@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Ben Campbell , Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data type s References: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC0493@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 11:05:41 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tschofenig Hannes wrote: > > I'm confused about what the problem is. Once you define the data types > and then define a combining operator, you just need to be careful > about how you use them. As long as, for any integer type, a larger > value is more permissive than a smaller one, you should be OK. > > In the case of the "provide civil location" transformation, it seems > to me that this is basically an integer, whose values are mapped to a > pnemonic that describes the level. So: > > #define NULL 0 > #define COUNTRY 1 > #define REGION 2 > #define CITY 3 > #define BUILDING 4 > #define FULL 5 > > thus, if one statement grants you country, and another grants you > building, you get building (MAX(1,4) = 4). > > Am I missing something? > > # you miss nothing here. i think that the description in the draft is easy > to follow. for future extensions it might be possible that the lattice is > more complex and you need to follow the same procedure. > > # have you looked at the slides (as indicated above). there you see an > example where you have the combination with a default rule where the result > is counter-intuitive. we still need to address these issues in a future > version of the draft. I did look at the slides, but I dont see or understand the problem. WHy is the result counter-intuitive? It says that the civil location that gets distributed is at the city level, and the D flag is TRUE. Seems OK to me... maybe I am missing something... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 3 11:26:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22066; Wed, 3 Dec 2003 11:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZqE-0003qR-00; Wed, 03 Dec 2003 11:27:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZqD-0003qO-00; Wed, 03 Dec 2003 11:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZq9-0006Tc-Fo; Wed, 03 Dec 2003 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZpJ-0006Sy-2X for simple@optimus.ietf.org; Wed, 03 Dec 2003 11:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21958 for ; Wed, 3 Dec 2003 11:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZpI-0003qD-00 for simple@ietf.org; Wed, 03 Dec 2003 11:26:08 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1ARZpH-0003q8-00 for simple@ietf.org; Wed, 03 Dec 2003 11:26:07 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hB3GQ6S03354; Wed, 3 Dec 2003 17:26:06 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB3GQ5P21692; Wed, 3 Dec 2003 17:26:05 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 17:25:46 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: Ben Campbell , Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data type s MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 17:24:16 +0100 hi jonathan, ~~ snip~~ > > I did look at the slides, but I dont see or understand the problem. > WHy is the result counter-intuitive? It says that the civil location > that gets distributed is at the city level, and the D flag is TRUE. > Seems OK to me... maybe I am missing something... the result is perfectly fine from the perspective of the permission combining algorithm. let me consider the example again: i want to disclose location information at a coarse granularity (in this case country) for everyone (and additionally allow them to further distribute this location information). additionally i specify a second rule which says that one particular person is allowed to see my detailed location (city in this case) but i do not want to allow the distribution of this information (= D-flag set to false). usually someone would assume that the outcome is that allison requesting location information would not be allowed to further distribute information. however, based on the rule combining algorithm this is not the case. you can easily extend this example to other attributes (e.g., encryption). don't you think that this is counter-intuitive? ciao hannes > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 3 11:27:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22085 for ; Wed, 3 Dec 2003 11:27:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZqF-0006US-Jx for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 11:27:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3GR7tE024942 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 11:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZqF-0006UD-GM for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 11:27:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22066; Wed, 3 Dec 2003 11:26:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZqE-0003qR-00; Wed, 03 Dec 2003 11:27:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARZqD-0003qO-00; Wed, 03 Dec 2003 11:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZq9-0006Tc-Fo; Wed, 03 Dec 2003 11:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARZpJ-0006Sy-2X for simple@optimus.ietf.org; Wed, 03 Dec 2003 11:26:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21958 for ; Wed, 3 Dec 2003 11:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZpI-0003qD-00 for simple@ietf.org; Wed, 03 Dec 2003 11:26:08 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx with esmtp (Exim 4.12) id 1ARZpH-0003q8-00 for simple@ietf.org; Wed, 03 Dec 2003 11:26:07 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id hB3GQ6S03354; Wed, 3 Dec 2003 17:26:06 +0100 (MET) Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id hB3GQ5P21692; Wed, 3 Dec 2003 17:26:05 +0100 (MET) Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 17:25:46 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Jonathan Rosenberg'" Cc: Ben Campbell , Simple WG Subject: RE: [Simple] xcap/geopriv alignment issue 5: permission data type s MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Dec 2003 17:24:16 +0100 hi jonathan, ~~ snip~~ > > I did look at the slides, but I dont see or understand the problem. > WHy is the result counter-intuitive? It says that the civil location > that gets distributed is at the city level, and the D flag is TRUE. > Seems OK to me... maybe I am missing something... the result is perfectly fine from the perspective of the permission combining algorithm. let me consider the example again: i want to disclose location information at a coarse granularity (in this case country) for everyone (and additionally allow them to further distribute this location information). additionally i specify a second rule which says that one particular person is allowed to see my detailed location (city in this case) but i do not want to allow the distribution of this information (= D-flag set to false). usually someone would assume that the outcome is that allison requesting location information would not be allowed to further distribute information. however, based on the rule combining algorithm this is not the case. you can easily extend this example to other attributes (e.g., encryption). don't you think that this is counter-intuitive? ciao hannes > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 3 17:17:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12484; Wed, 3 Dec 2003 17:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARfJC-0003Fl-00; Wed, 03 Dec 2003 17:17:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARfJC-0003FM-00; Wed, 03 Dec 2003 17:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfIr-0007P3-TD; Wed, 03 Dec 2003 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfIc-0007Op-JP for simple@optimus.ietf.org; Wed, 03 Dec 2003 17:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12425 for ; Wed, 3 Dec 2003 17:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARfIX-0003EI-00 for simple@ietf.org; Wed, 03 Dec 2003 17:16:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARfIW-0003Cr-00 for simple@ietf.org; Wed, 03 Dec 2003 17:16:40 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB3MGNnG025051; Wed, 3 Dec 2003 16:16:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCE609E.9050000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> <3FC26E6F.9030908@dynamicsoft.com> <3FCCF099.9020003@dynamicsoft.com> In-Reply-To: <3FCCF099.9020003@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 16:15:58 -0600 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Ben Campbell wrote: > >> Jonathan Rosenberg wrote: >> >>> Folks, >>> >>> In the current xcap-auth model, there is an important assumption that >>> if there are no statements that apply to a watcher, the implication >>> is that their subscription is pending, and that the presentity should >>> get a winfo notification about the fact that its pending, so that >>> they can make a policy decision. This assumption is based on another >>> assumption I made, which is that the ONLY reason that a watcher would >>> go into the pending state, is if you have not specified a policy for >>> them yet. >>> >>> However, geopriv doesnt make this assumption. They have an element >>> called "confirm-subscription". If present, it means that the >>> presentity should be alerted about the subscription, and asked for >>> confirmation. As a result, there is a way to EXPLICITLY say "let me >>> know if this person subscribes". >>> >>> I think there are legitimate use cases for this, which came up during >>> the geopriv meeting in Minneapolis. In particular, I may grant my >>> boss permission to subscribe during the day, but during the evening, >>> I want to be prompted each time, to see if I will grant it or not. >>> >>> To do this, we could follow their lead and add a >>> "confirm-subscription" boolean, which would explicitly place the >>> watcher into the pending state. >>> >>> I think this makes sense, and I would suggest adding this capability >>> to xcap-auth. >> >> >> >> I think I like this. So if we were to do this, would that mean the >> default for when no rules apply would become "deny"? > > > Yes. Generally, for any boolean type, the default is FALSE. > >> >> This does, however, bring up a concern that I tried to express in >> Minneapolis, but am not sure I ever managed to make my point. Most >> existing presence systems have a concept of blocking an identity. The >> additive permissions approach seems to make this difficult to >> implement. If I, for example, want to block alice@example.com, I must >> make sure that no other rule can possibly include alice. This is >> further complicated if some of my rules apply to external lists. Even >> if Alice is not on such a list today, someone might put her on one >> tomorrow, and invalidate my block. The easiest way to make sure this >> never happens would be to add an except clause for Alice to _every_ >> rule I have. That seems pretty cumbersome and error prone. >> >> And yes, I understand the arguments in geopriv about black-lists being >> useless. I just don't think I could sell those arguments to a customer. > > > I think this is a separate discussion, which we are having in the thread > associated with issue 8, exceptions. Do you see a specific interaction > with subscription confirmation? No. It simply triggered the thought in my head--but I agree it is being covered enough in other threads. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 3 17:17:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12565 for ; Wed, 3 Dec 2003 17:17:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfJF-0007Q0-Rb for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 17:17:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3MHPQl028512 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 17:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfJF-0007Pn-Oc for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 17:17:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12484; Wed, 3 Dec 2003 17:17:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARfJC-0003Fl-00; Wed, 03 Dec 2003 17:17:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARfJC-0003FM-00; Wed, 03 Dec 2003 17:17:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfIr-0007P3-TD; Wed, 03 Dec 2003 17:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARfIc-0007Op-JP for simple@optimus.ietf.org; Wed, 03 Dec 2003 17:16:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12425 for ; Wed, 3 Dec 2003 17:16:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARfIX-0003EI-00 for simple@ietf.org; Wed, 03 Dec 2003 17:16:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ARfIW-0003Cr-00 for simple@ietf.org; Wed, 03 Dec 2003 17:16:40 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB3MGNnG025051; Wed, 3 Dec 2003 16:16:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FCE609E.9050000@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Simple WG Subject: Re: [Simple] xcap/geopriv alignment issue 6: subscription confirmation References: <3FC1A843.9020109@dynamicsoft.com> <3FC26E6F.9030908@dynamicsoft.com> <3FCCF099.9020003@dynamicsoft.com> In-Reply-To: <3FCCF099.9020003@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Dec 2003 16:15:58 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. > > Ben Campbell wrote: > >> Jonathan Rosenberg wrote: >> >>> Folks, >>> >>> In the current xcap-auth model, there is an important assumption that >>> if there are no statements that apply to a watcher, the implication >>> is that their subscription is pending, and that the presentity should >>> get a winfo notification about the fact that its pending, so that >>> they can make a policy decision. This assumption is based on another >>> assumption I made, which is that the ONLY reason that a watcher would >>> go into the pending state, is if you have not specified a policy for >>> them yet. >>> >>> However, geopriv doesnt make this assumption. They have an element >>> called "confirm-subscription". If present, it means that the >>> presentity should be alerted about the subscription, and asked for >>> confirmation. As a result, there is a way to EXPLICITLY say "let me >>> know if this person subscribes". >>> >>> I think there are legitimate use cases for this, which came up during >>> the geopriv meeting in Minneapolis. In particular, I may grant my >>> boss permission to subscribe during the day, but during the evening, >>> I want to be prompted each time, to see if I will grant it or not. >>> >>> To do this, we could follow their lead and add a >>> "confirm-subscription" boolean, which would explicitly place the >>> watcher into the pending state. >>> >>> I think this makes sense, and I would suggest adding this capability >>> to xcap-auth. >> >> >> >> I think I like this. So if we were to do this, would that mean the >> default for when no rules apply would become "deny"? > > > Yes. Generally, for any boolean type, the default is FALSE. > >> >> This does, however, bring up a concern that I tried to express in >> Minneapolis, but am not sure I ever managed to make my point. Most >> existing presence systems have a concept of blocking an identity. The >> additive permissions approach seems to make this difficult to >> implement. If I, for example, want to block alice@example.com, I must >> make sure that no other rule can possibly include alice. This is >> further complicated if some of my rules apply to external lists. Even >> if Alice is not on such a list today, someone might put her on one >> tomorrow, and invalidate my block. The easiest way to make sure this >> never happens would be to add an except clause for Alice to _every_ >> rule I have. That seems pretty cumbersome and error prone. >> >> And yes, I understand the arguments in geopriv about black-lists being >> useless. I just don't think I could sell those arguments to a customer. > > > I think this is a separate discussion, which we are having in the thread > associated with issue 8, exceptions. Do you see a specific interaction > with subscription confirmation? No. It simply triggered the thought in my head--but I agree it is being covered enough in other threads. > > -Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 3 18:02:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13827; Wed, 3 Dec 2003 18:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARg1V-0003ll-00; Wed, 03 Dec 2003 18:03:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARg1V-0003li-00; Wed, 03 Dec 2003 18:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1N-0000Kv-CW; Wed, 03 Dec 2003 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1D-0000Kd-1R for simple@optimus.ietf.org; Wed, 03 Dec 2003 18:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13821 for ; Wed, 3 Dec 2003 18:02:32 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARg19-0003lX-00 for simple@ietf.org; Wed, 03 Dec 2003 18:02:47 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARg18-0003lJ-00 for simple@ietf.org; Wed, 03 Dec 2003 18:02:46 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3N2iV12682 for ; Thu, 4 Dec 2003 01:02:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Dec 2003 01:02:44 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 01:02:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQAALWhzA= To: X-OriginalArrivalTime: 03 Dec 2003 23:02:44.0043 (UTC) FILETIME=[8F6391B0:01C3B9F1] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Question on XCAP-auth - multi-device use case Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 01:02:27 +0200 Content-Transfer-Encoding: quoted-printable Hi, I have a question on xcap-auth usage in case that the presentity has = multiple devices that publish presence information.=20 Here's the use case: User has two devices that publish presence tuples related to the same = application or communication mean (e.g. MMS). The user would like to = give this information (from both devices) only to a group of watchers.=20 In the current xcap-auth there is only one content permission element = that can be used to select tuples, i.e. show-tuple which is based on = RPID class element: --- show-tuple: This permission specifies that the identified tuples can be sent to the watcher. The element has no attributes. Its content is a string that matches the "class" element present within the tuple [12]. --- RPID defines class as an opaque identifier without any semantics. If the user is using one of his devices to make this configuration, he = can basically use the right class values regarding the tuples in _that_ = device. However, as the other device may use whatever classes, the user = can't determine the correct settings for xcap-auth. If both devices came from the same vendor the class names for MMS could = be fixed, but if they come from different vendors, there's no = specification about that. Also, some tuples could come from entities = that the presentity has no control over, such as the MMS server. So, my question is that is it possible at all to authorize tuples coming = from another device than the one updating xcap-auth doc? Wouldn't it make sense to be able to authorize tuples based on something = else than class too, e.g. contact? Actually the contact URI scheme based = authorization would work in the use case given above. Would it be = possible to extend show-tuple with limited regexp matching with contact, = i.e. something like: Show tuple if "contact" matches to "mmsto:*" Another possibility would be to define some application labels to RPID, = even though it is not sure how this would work for more complex apps = than SMS, MMS or e-mail, which are readily identifiable from the contact = URI scheme. Markus =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 3 18:03:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13862 for ; Wed, 3 Dec 2003 18:03:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1Z-0000Lk-BS for simple-archive@odin.ietf.org; Wed, 03 Dec 2003 18:03:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3N3DXw001338 for simple-archive@odin.ietf.org; Wed, 3 Dec 2003 18:03:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1Z-0000LV-4u for simple-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 18:03:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13827; Wed, 3 Dec 2003 18:02:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARg1V-0003ll-00; Wed, 03 Dec 2003 18:03:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARg1V-0003li-00; Wed, 03 Dec 2003 18:03:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1N-0000Kv-CW; Wed, 03 Dec 2003 18:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARg1D-0000Kd-1R for simple@optimus.ietf.org; Wed, 03 Dec 2003 18:02:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13821 for ; Wed, 3 Dec 2003 18:02:32 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARg19-0003lX-00 for simple@ietf.org; Wed, 03 Dec 2003 18:02:47 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ARg18-0003lJ-00 for simple@ietf.org; Wed, 03 Dec 2003 18:02:46 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB3N2iV12682 for ; Thu, 4 Dec 2003 01:02:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Dec 2003 01:02:44 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 01:02:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQAALWhzA= To: X-OriginalArrivalTime: 03 Dec 2003 23:02:44.0043 (UTC) FILETIME=[8F6391B0:01C3B9F1] Content-Transfer-Encoding: quoted-printable Subject: [Simple] Question on XCAP-auth - multi-device use case Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 01:02:27 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I have a question on xcap-auth usage in case that the presentity has = multiple devices that publish presence information.=20 Here's the use case: User has two devices that publish presence tuples related to the same = application or communication mean (e.g. MMS). The user would like to = give this information (from both devices) only to a group of watchers.=20 In the current xcap-auth there is only one content permission element = that can be used to select tuples, i.e. show-tuple which is based on = RPID class element: --- show-tuple: This permission specifies that the identified tuples can be sent to the watcher. The element has no attributes. Its content is a string that matches the "class" element present within the tuple [12]. --- RPID defines class as an opaque identifier without any semantics. If the user is using one of his devices to make this configuration, he = can basically use the right class values regarding the tuples in _that_ = device. However, as the other device may use whatever classes, the user = can't determine the correct settings for xcap-auth. If both devices came from the same vendor the class names for MMS could = be fixed, but if they come from different vendors, there's no = specification about that. Also, some tuples could come from entities = that the presentity has no control over, such as the MMS server. So, my question is that is it possible at all to authorize tuples coming = from another device than the one updating xcap-auth doc? Wouldn't it make sense to be able to authorize tuples based on something = else than class too, e.g. contact? Actually the contact URI scheme based = authorization would work in the use case given above. Would it be = possible to extend show-tuple with limited regexp matching with contact, = i.e. something like: Show tuple if "contact" matches to "mmsto:*" Another possibility would be to define some application labels to RPID, = even though it is not sure how this would work for more complex apps = than SMS, MMS or e-mail, which are readily identifiable from the contact = URI scheme. Markus =20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 4 00:34:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28859; Thu, 4 Dec 2003 00:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARm8s-0002Kr-00; Thu, 04 Dec 2003 00:35:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARm8s-0002Ko-00; Thu, 04 Dec 2003 00:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8k-0007dI-B0; Thu, 04 Dec 2003 00:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8G-0007cn-Np for simple@optimus.ietf.org; Thu, 04 Dec 2003 00:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28848 for ; Thu, 4 Dec 2003 00:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARm8D-0002KP-00 for simple@ietf.org; Thu, 04 Dec 2003 00:34:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARm8D-0002KK-00 for simple@ietf.org; Thu, 04 Dec 2003 00:34:29 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB45Y3ca026484; Thu, 4 Dec 2003 00:34:04 -0500 (EST) Message-ID: <3FCEC746.9010207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Question on XCAP-auth - multi-device use case References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 00:33:58 -0500 Content-Transfer-Encoding: 7bit Markus, Some good questions in here. I think that the underlying assumption with the "class" parameter is that it is not generated in an isolated fashion by the various devices under my control. Rather, by some means (unspecified), a user or provider can gain awareness or set what the class is. I would typically expect the latter case, where the phone, through configuration, would learn the class for the tuples it publishes. That said, I agree that it would be valuable to have a richer set of ways to select tuples for publication. What you are proposing touches on the "what is a tuple" discussions we have been having for some time. It really sounds like you want to have a way to say "publish tuples corresponding to service X", which would work only if we had a clear way of saying that a tuple corresponds to service X. The scheme is a close approximation to that, but as we have seen from discussions in other threads, it doesnt solve the whole problem. As such, I'm hesitant to try and add a feature to xcap-auth that tries to allow for tuple selection based on service, before we have really nailed down the corresponding tuple discussion. -Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi, > > I have a question on xcap-auth usage in case that the presentity > has multiple devices that publish presence information. > > Here's the use case: User has two devices that publish presence > tuples related to the same application or communication mean (e.g. > MMS). The user would like to give this information (from both > devices) only to a group of watchers. > > In the current xcap-auth there is only one content permission > element that can be used to select tuples, i.e. show-tuple which is > based on RPID class element: --- show-tuple: This permission > specifies that the identified tuples can be sent to the watcher. > The element has no attributes. Its content is a string that matches > the "class" element present within the tuple [12]. --- RPID defines > class as an opaque identifier without any semantics. > > If the user is using one of his devices to make this configuration, > he can basically use the right class values regarding the tuples in > _that_ device. However, as the other device may use whatever > classes, the user can't determine the correct settings for > xcap-auth. > > If both devices came from the same vendor the class names for MMS > could be fixed, but if they come from different vendors, there's no > specification about that. Also, some tuples could come from > entities that the presentity has no control over, such as the MMS > server. > > So, my question is that is it possible at all to authorize tuples > coming from another device than the one updating xcap-auth doc? > > Wouldn't it make sense to be able to authorize tuples based on > something else than class too, e.g. contact? Actually the contact > URI scheme based authorization would work in the use case given > above. Would it be possible to extend show-tuple with limited > regexp matching with contact, i.e. something like: Show tuple if > "contact" matches to "mmsto:*" > > Another possibility would be to define some application labels to > RPID, even though it is not sure how this would work for more > complex apps than SMS, MMS or e-mail, which are readily > identifiable from the contact URI scheme. > > Markus > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 4 00:35:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28881 for ; Thu, 4 Dec 2003 00:35:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8w-0007ed-0x for simple-archive@odin.ietf.org; Thu, 04 Dec 2003 00:35:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB45ZElp029422 for simple-archive@odin.ietf.org; Thu, 4 Dec 2003 00:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8v-0007eT-Tg for simple-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 00:35:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28859; Thu, 4 Dec 2003 00:34:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARm8s-0002Kr-00; Thu, 04 Dec 2003 00:35:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARm8s-0002Ko-00; Thu, 04 Dec 2003 00:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8k-0007dI-B0; Thu, 04 Dec 2003 00:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARm8G-0007cn-Np for simple@optimus.ietf.org; Thu, 04 Dec 2003 00:34:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28848 for ; Thu, 4 Dec 2003 00:34:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARm8D-0002KP-00 for simple@ietf.org; Thu, 04 Dec 2003 00:34:29 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARm8D-0002KK-00 for simple@ietf.org; Thu, 04 Dec 2003 00:34:29 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB45Y3ca026484; Thu, 4 Dec 2003 00:34:04 -0500 (EST) Message-ID: <3FCEC746.9010207@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus.Isomaki@nokia.com CC: simple@ietf.org Subject: Re: [Simple] Question on XCAP-auth - multi-device use case References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 00:33:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Markus, Some good questions in here. I think that the underlying assumption with the "class" parameter is that it is not generated in an isolated fashion by the various devices under my control. Rather, by some means (unspecified), a user or provider can gain awareness or set what the class is. I would typically expect the latter case, where the phone, through configuration, would learn the class for the tuples it publishes. That said, I agree that it would be valuable to have a richer set of ways to select tuples for publication. What you are proposing touches on the "what is a tuple" discussions we have been having for some time. It really sounds like you want to have a way to say "publish tuples corresponding to service X", which would work only if we had a clear way of saying that a tuple corresponds to service X. The scheme is a close approximation to that, but as we have seen from discussions in other threads, it doesnt solve the whole problem. As such, I'm hesitant to try and add a feature to xcap-auth that tries to allow for tuple selection based on service, before we have really nailed down the corresponding tuple discussion. -Jonathan R. Markus.Isomaki@nokia.com wrote: > Hi, > > I have a question on xcap-auth usage in case that the presentity > has multiple devices that publish presence information. > > Here's the use case: User has two devices that publish presence > tuples related to the same application or communication mean (e.g. > MMS). The user would like to give this information (from both > devices) only to a group of watchers. > > In the current xcap-auth there is only one content permission > element that can be used to select tuples, i.e. show-tuple which is > based on RPID class element: --- show-tuple: This permission > specifies that the identified tuples can be sent to the watcher. > The element has no attributes. Its content is a string that matches > the "class" element present within the tuple [12]. --- RPID defines > class as an opaque identifier without any semantics. > > If the user is using one of his devices to make this configuration, > he can basically use the right class values regarding the tuples in > _that_ device. However, as the other device may use whatever > classes, the user can't determine the correct settings for > xcap-auth. > > If both devices came from the same vendor the class names for MMS > could be fixed, but if they come from different vendors, there's no > specification about that. Also, some tuples could come from > entities that the presentity has no control over, such as the MMS > server. > > So, my question is that is it possible at all to authorize tuples > coming from another device than the one updating xcap-auth doc? > > Wouldn't it make sense to be able to authorize tuples based on > something else than class too, e.g. contact? Actually the contact > URI scheme based authorization would work in the use case given > above. Would it be possible to extend show-tuple with limited > regexp matching with contact, i.e. something like: Show tuple if > "contact" matches to "mmsto:*" > > Another possibility would be to define some application labels to > RPID, even though it is not sure how this would work for more > complex apps than SMS, MMS or e-mail, which are readily > identifiable from the contact URI scheme. > > Markus > > _______________________________________________ Simple mailing list > Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 4 01:23:55 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00115; Thu, 4 Dec 2003 01:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARmuF-0002vI-00; Thu, 04 Dec 2003 01:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARmuE-0002vF-00; Thu, 04 Dec 2003 01:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmu9-0000sJ-Jj; Thu, 04 Dec 2003 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmtt-0000rp-N2 for simple@optimus.ietf.org; Thu, 04 Dec 2003 01:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00102; Thu, 4 Dec 2003 01:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARmtq-0002ul-00; Thu, 04 Dec 2003 01:23:42 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARmtp-0002uf-00; Thu, 04 Dec 2003 01:23:41 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB46NEca026514; Thu, 4 Dec 2003 01:23:15 -0500 (EST) Message-ID: <3FCED2CD.8020200@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Ben Campbell , Simple WG , geopriv@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data type s References: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 01:23:09 -0500 Content-Transfer-Encoding: 7bit inline. Tschofenig Hannes wrote: > hi jonathan, > > ~~ snip~~ > >>I did look at the slides, but I dont see or understand the problem. >>WHy is the result counter-intuitive? It says that the civil location >>that gets distributed is at the city level, and the D flag is TRUE. >>Seems OK to me... maybe I am missing something... > > > the result is perfectly fine from the perspective of the permission > combining algorithm. > > let me consider the example again: > > i want to disclose location information at a coarse granularity (in this > case country) for everyone (and additionally allow them to further > distribute this location information). > additionally i specify a second rule which says that one particular person > is allowed to see my detailed location (city in this case) but i do not want > to allow the distribution of this information (= D-flag set to false). > > usually someone would assume that the outcome is that allison requesting > location information would not be allowed to further distribute information. > however, based on the rule combining algorithm this is not the case. > > you can easily extend this example to other attributes (e.g., encryption). > > don't you think that this is counter-intuitive? I can see how it may not be the result you might want, but I dont think its counter-intuitive. Its a natural consequence of the two key properties here - orthogonality of permissions and additivity of permissions. The problem is that you don't want the D flag to really be orthogonal to the transformation applied to the data. Rather, you want it to be more of an integer, like the location granularity itself, that specifies the maximum level of detail which is allowed to be distributed. Using this model, your two rules would be: country country and sip:mankin@psg.com city For Allison, she would get city information, but she, like everyone else, is only allowed to distribute inforamtion about my country. By structuring the "D flag" in this way, it can once again be orthogonal to the other permissions. This is becoming more of a geopriv discussion, so I am cc'ing geopriv. I know folks dont like cross-posting, but I suspect there are enough folks on geopriv and not simple that it is probably the right thing here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 4 01:24:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00157 for ; Thu, 4 Dec 2003 01:24:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmuI-0000ts-PH for simple-archive@odin.ietf.org; Thu, 04 Dec 2003 01:24:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB46OAYY003459 for simple-archive@odin.ietf.org; Thu, 4 Dec 2003 01:24:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmuI-0000ti-Lw for simple-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 01:24:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00115; Thu, 4 Dec 2003 01:23:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARmuF-0002vI-00; Thu, 04 Dec 2003 01:24:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARmuE-0002vF-00; Thu, 04 Dec 2003 01:24:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmu9-0000sJ-Jj; Thu, 04 Dec 2003 01:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARmtt-0000rp-N2 for simple@optimus.ietf.org; Thu, 04 Dec 2003 01:23:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00102; Thu, 4 Dec 2003 01:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARmtq-0002ul-00; Thu, 04 Dec 2003 01:23:42 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ARmtp-0002uf-00; Thu, 04 Dec 2003 01:23:41 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB46NEca026514; Thu, 4 Dec 2003 01:23:15 -0500 (EST) Message-ID: <3FCED2CD.8020200@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes CC: Ben Campbell , Simple WG , geopriv@ietf.org Subject: Re: [Simple] xcap/geopriv alignment issue 5: permission data type s References: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BC049C@mchp905a.mch.sbs.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 01:23:09 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Tschofenig Hannes wrote: > hi jonathan, > > ~~ snip~~ > >>I did look at the slides, but I dont see or understand the problem. >>WHy is the result counter-intuitive? It says that the civil location >>that gets distributed is at the city level, and the D flag is TRUE. >>Seems OK to me... maybe I am missing something... > > > the result is perfectly fine from the perspective of the permission > combining algorithm. > > let me consider the example again: > > i want to disclose location information at a coarse granularity (in this > case country) for everyone (and additionally allow them to further > distribute this location information). > additionally i specify a second rule which says that one particular person > is allowed to see my detailed location (city in this case) but i do not want > to allow the distribution of this information (= D-flag set to false). > > usually someone would assume that the outcome is that allison requesting > location information would not be allowed to further distribute information. > however, based on the rule combining algorithm this is not the case. > > you can easily extend this example to other attributes (e.g., encryption). > > don't you think that this is counter-intuitive? I can see how it may not be the result you might want, but I dont think its counter-intuitive. Its a natural consequence of the two key properties here - orthogonality of permissions and additivity of permissions. The problem is that you don't want the D flag to really be orthogonal to the transformation applied to the data. Rather, you want it to be more of an integer, like the location granularity itself, that specifies the maximum level of detail which is allowed to be distributed. Using this model, your two rules would be: country country and sip:mankin@psg.com city For Allison, she would get city information, but she, like everyone else, is only allowed to distribute inforamtion about my country. By structuring the "D flag" in this way, it can once again be orthogonal to the other permissions. This is becoming more of a geopriv discussion, so I am cc'ing geopriv. I know folks dont like cross-posting, but I suspect there are enough folks on geopriv and not simple that it is probably the right thing here. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 4 06:31:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20146; Thu, 4 Dec 2003 06:31:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrhT-0006R4-00; Thu, 04 Dec 2003 06:31:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARrhT-0006R1-00; Thu, 04 Dec 2003 06:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrhG-0006c3-7P; Thu, 04 Dec 2003 06:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrgK-0006NK-1t for simple@optimus.ietf.org; Thu, 04 Dec 2003 06:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20025 for ; Thu, 4 Dec 2003 06:29:46 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrgF-0006Px-00 for simple@ietf.org; Thu, 04 Dec 2003 06:29:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARrgF-0006Pq-00 for simple@ietf.org; Thu, 04 Dec 2003 06:29:59 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4BTxw24906 for ; Thu, 4 Dec 2003 13:29:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Dec 2003 13:29:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 13:29:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question on XCAP-auth - multi-device use case Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B120@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQAALWhzAALLSjQA== To: , X-OriginalArrivalTime: 04 Dec 2003 11:29:58.0337 (UTC) FILETIME=[F2B5EB10:01C3BA59] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 13:29:57 +0200 Content-Transfer-Encoding: quoted-printable Markus, I basically agree with you. In filtering, we use conditions using xpath = like expressions. So for xcap-auth, it would look something like: //class=3DMMS This enables any kind of conditional inclusion of a tuple, not limited = to class. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Markus.Isomaki@nokia.com > Sent: 04.December.2003 01:02 > To: simple@ietf.org > Subject: [Simple] Question on XCAP-auth - multi-device use case >=20 >=20 > Hi, >=20 > I have a question on xcap-auth usage in case that the=20 > presentity has multiple devices that publish presence information.=20 >=20 > Here's the use case: > User has two devices that publish presence tuples related to=20 > the same application or communication mean (e.g. MMS). The=20 > user would like to give this information (from both devices)=20 > only to a group of watchers.=20 >=20 > In the current xcap-auth there is only one content permission=20 > element that can be used to select tuples, i.e. show-tuple=20 > which is based on RPID class element: > --- > show-tuple: This permission specifies that the identified=20 > tuples can > be sent to the watcher. The element has no attributes.=20 > Its content > is a string that matches the "class" element present within the > tuple [12]. > --- > RPID defines class as an opaque identifier without any semantics. >=20 > If the user is using one of his devices to make this=20 > configuration, he can basically use the right class values=20 > regarding the tuples in _that_ device. However, as the other=20 > device may use whatever classes, the user can't determine the=20 > correct settings for xcap-auth. >=20 > If both devices came from the same vendor the class names for=20 > MMS could be fixed, but if they come from different vendors,=20 > there's no specification about that. Also, some tuples could=20 > come from entities that the presentity has no control over,=20 > such as the MMS server. >=20 > So, my question is that is it possible at all to authorize=20 > tuples coming from another device than the one updating xcap-auth doc? >=20 > Wouldn't it make sense to be able to authorize tuples based=20 > on something else than class too, e.g. contact? Actually the=20 > contact URI scheme based authorization would work in the use=20 > case given above. Would it be possible to extend show-tuple=20 > with limited regexp matching with contact, i.e. something like: > Show tuple if "contact" matches to "mmsto:*" >=20 > Another possibility would be to define some application=20 > labels to RPID, even though it is not sure how this would=20 > work for more complex apps than SMS, MMS or e-mail, which are=20 > readily identifiable from the contact URI scheme. >=20 > Markus =20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Thu Dec 4 06:31:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20198 for ; Thu, 4 Dec 2003 06:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrhY-0006gW-EP for simple-archive@odin.ietf.org; Thu, 04 Dec 2003 06:31:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4BVKiN025692 for simple-archive@odin.ietf.org; Thu, 4 Dec 2003 06:31:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrhY-0006gJ-B6 for simple-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 06:31:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20146; Thu, 4 Dec 2003 06:31:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrhT-0006R4-00; Thu, 04 Dec 2003 06:31:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARrhT-0006R1-00; Thu, 04 Dec 2003 06:31:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrhG-0006c3-7P; Thu, 04 Dec 2003 06:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARrgK-0006NK-1t for simple@optimus.ietf.org; Thu, 04 Dec 2003 06:30:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20025 for ; Thu, 4 Dec 2003 06:29:46 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARrgF-0006Px-00 for simple@ietf.org; Thu, 04 Dec 2003 06:29:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1ARrgF-0006Pq-00 for simple@ietf.org; Thu, 04 Dec 2003 06:29:59 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB4BTxw24906 for ; Thu, 4 Dec 2003 13:29:59 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Dec 2003 13:29:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 4 Dec 2003 13:29:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Question on XCAP-auth - multi-device use case Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B120@esebe019.ntc.nokia.com> Thread-Topic: [Simple] xcap/geopriv alignment issue 8: exceptions Thread-Index: AcO5F0C6qChxQ2znSomvJOTU8bToIgAg+dzQAALWhzAALLSjQA== To: , X-OriginalArrivalTime: 04 Dec 2003 11:29:58.0337 (UTC) FILETIME=[F2B5EB10:01C3BA59] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 13:29:57 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Markus, I basically agree with you. In filtering, we use conditions using xpath = like expressions. So for xcap-auth, it would look something like: //class=3DMMS This enables any kind of conditional inclusion of a tuple, not limited = to class. Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Markus.Isomaki@nokia.com > Sent: 04.December.2003 01:02 > To: simple@ietf.org > Subject: [Simple] Question on XCAP-auth - multi-device use case >=20 >=20 > Hi, >=20 > I have a question on xcap-auth usage in case that the=20 > presentity has multiple devices that publish presence information.=20 >=20 > Here's the use case: > User has two devices that publish presence tuples related to=20 > the same application or communication mean (e.g. MMS). The=20 > user would like to give this information (from both devices)=20 > only to a group of watchers.=20 >=20 > In the current xcap-auth there is only one content permission=20 > element that can be used to select tuples, i.e. show-tuple=20 > which is based on RPID class element: > --- > show-tuple: This permission specifies that the identified=20 > tuples can > be sent to the watcher. The element has no attributes.=20 > Its content > is a string that matches the "class" element present within the > tuple [12]. > --- > RPID defines class as an opaque identifier without any semantics. >=20 > If the user is using one of his devices to make this=20 > configuration, he can basically use the right class values=20 > regarding the tuples in _that_ device. However, as the other=20 > device may use whatever classes, the user can't determine the=20 > correct settings for xcap-auth. >=20 > If both devices came from the same vendor the class names for=20 > MMS could be fixed, but if they come from different vendors,=20 > there's no specification about that. Also, some tuples could=20 > come from entities that the presentity has no control over,=20 > such as the MMS server. >=20 > So, my question is that is it possible at all to authorize=20 > tuples coming from another device than the one updating xcap-auth doc? >=20 > Wouldn't it make sense to be able to authorize tuples based=20 > on something else than class too, e.g. contact? Actually the=20 > contact URI scheme based authorization would work in the use=20 > case given above. Would it be possible to extend show-tuple=20 > with limited regexp matching with contact, i.e. something like: > Show tuple if "contact" matches to "mmsto:*" >=20 > Another possibility would be to define some application=20 > labels to RPID, even though it is not sure how this would=20 > work for more complex apps than SMS, MMS or e-mail, which are=20 > readily identifiable from the contact URI scheme. >=20 > Markus =20 >=20 > _______________________________________________ > 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-admin@ietf.org Thu Dec 4 18:01:29 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22932; Thu, 4 Dec 2003 18:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Tg-0003yG-00; Thu, 04 Dec 2003 18:01:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AS2P7-0003tz-00; Thu, 04 Dec 2003 17:57:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AS2Am-00076n-2z; Thu, 04 Dec 2003 17:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Ac-0005gP-5X; Thu, 04 Dec 2003 17:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS29u-0005fg-Kf for simple@optimus.ietf.org; Thu, 04 Dec 2003 17:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22135 for ; Thu, 4 Dec 2003 17:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS29s-0003dL-00 for simple@ietf.org; Thu, 04 Dec 2003 17:41:16 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AS29q-0003dH-00 for simple@ietf.org; Thu, 04 Dec 2003 17:41:14 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 7A236B6656 for ; Thu, 4 Dec 2003 17:41:10 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120417410931802 ; Thu, 04 Dec 2003 17:41:09 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 17:41:09 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Simple] Re: MS(r)P: Reconnect issue Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO48zN43Q8UXgfzSZeRdGBN42qsqwAg61FA From: "Andrew Allen" To: "Michael Hammer" Cc: , X-OriginalArrivalTime: 04 Dec 2003 22:41:09.0917 (UTC) FILETIME=[B6715CD0:01C3BAB7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 17:41:09 -0500 Content-Transfer-Encoding: quoted-printable Mike, Being a packet guy I am not sure what the relative priorities are for all networks during a circuit switched cellular handover however what you suggest makes sense. I am not sure what your point is though related to the MS(r)P reconnect issue. In GPRS the IP packet tunnel should be maintained during cell-cell handovers so the MS(r)P connection should not drop during handover. My main concern is that MS(r)P not have mandates (such as SDP encryption, use of TLS for SIP etc) put on it that make it incompatible with the cellular SIP infrastructure just because of this reconnection issue and that the wireless endpoints do not continually attempt to reconnect at the TCP layer consuming scarce radio resources when the far endpoint is either out of radio coverage or the battery is dead.=20 If an Invite or Update is sent as part of an existing dialog then this will not be seen as a "new call attempt" if that is your concern. Andrew > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, December 02, 2003 11:41 AM > To: Andrew Allen > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Re: MS(r)P: Reconnect issue >=20 > Andrew, >=20 > Is it not true that for hand-offs in mobile networks that existing "calls" > being handed-off into new cells get precedence over new calls? >=20 > It seems that if you use the INVITE versus UPDATE methods, that you lose > this advantage and the dropped call rate will increase. However, if you > do > not feel that there is a resource contention issue, then this may not be a > problem. >=20 > Mike >=20 >=20 > At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: >=20 > >Ben > > > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec > >instead of TLS for security between itself and the mobile UA mandating > TLS > >for SIP/SDP will not help in the 3GPP situation either unless a radical > >change is made to the current 3GPP security architecture. > > > >If some people want to attempt reconnections without re-signaling is it > >possible to use the VISIT 200 OK exchange to initially negotiate support > >for reconnections and to exchange the necessary keys/certificates for > >validation that the reconnect attempt came from the same endpoint as the > >initial VISIT? > > > >I am not a security expert but if this is feasable then it would make > >reconnections possible but optional based on mutual negotiations between > >endpoints. If such a scheme requires TLS on the MS(r)P connection then > TLS > >or TCP could also be part of the SDP negotiation in the initial offer. > > > >For the wireless case I think we will want to use a renegotiation using > >SIP as it is most likely that one of the mobiles went out of radio > >coverage or that the battery died. In this case we want to detect using > >signaling as soon as possible that the mobile is unreachable so that the > >session can be released and the radio resources freed up. So I think you > >can place me in the re-signaling camp. > > > >Andrew > >-------------------------- > >Andrew Allen > >Manager Standards > >Research In Motion Ltd > >BlackBerry Mobile +1 847 809 8636 > >European Mobile +358 50 467 5870 > >http://www.rim.com/ > > > >Sent from my BlackBerry Wireless Handheld > > > > > >-----Original Message----- > >From: Ben Campbell > >To: Andrew Allen > >CC: Simple WG > >Sent: Mon Dec 01 22:40:06 2003 > >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > >Andrew Allen wrote: > > > > > Ben > > > > > > Ben, > > > > > > If Option 2 requires end-to-end encryption of the SDP to protect the > URL > > > then it is not going to be suitable for use by 3GPP for message > sessions > > > at the present time. The 3GPP network currently needs to examine the > SDP > > > to perform authorization and allocation of radio resources for the > > > session. > > > >A possible alternative is the use of the SIPS scheme, where the device > >that must inspect the SDP is a participant in one of the TLS > >handshakes--and therefore can see the contents. But I must admit that > >approach feels a little spooky. > > > > > > > > In the wireless case the chances of dropped connections are probably a > > > lot higher with the mobile potentially moving in and out of coverage > > > (especially if going through tunnels on a train) so this is likely to > be > > > a more common scenario in wireless. > > > > > > What were the main objections to re-invitation as a solution? > > > > > > >The objection was that such TCP drops happen alot, and people wanted the > >lightest weight recovery possible. If a simple TCP reconnect would work, > >it would be nice--but I don't think it will work. > > > > > Why not use UPDATE to attempt to re-establish connections in the case > > > when the dialog still exists? UPDATE is less expensive in terms of SIP > > > messages to re-establish (no ACK required). In the 3GPP case the > sending > > > of a SIP request is likely to trigger a network initiated termination > of > > > the session (a BYE) if the mobile is still out of coverage, which I > > > expect is what is desired in the wireless case to release the network > > > resources. > > > >If we establish that we must use a new SDP exchange, then I expect > >UPDATE and reinvites to both be applicable, depending on the particular > >circumstance. > > > > > > > > Andrew > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>Sent: Monday, December 01, 2003 2:54 PM > > >>To: Ben Campbell > > >>Cc: Simple WG > > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > > >> > > >>Oops, got my options mixed up. See clarification below. > > >> > > >>Ben Campbell wrote: > > >> > > >> > > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > >>>rename) should allow reconnection of dropped TCP connections without > > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > > > there > > > > > >>>was a reason we had originally chose not to allow that, but I could > > > > > > not > > > > > >>>remember the details at the time. Having slept since then, I now > > >> > > >>remember: > > >> > > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > > > active > > > > > >>>session. That TCP connection is then dropped due to something in the > > >>>network. I don't know why, maybe a stateful firewall dropped state, > > > > > > or a > > > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > > > any > > > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > > > the > > > > > >>>endpoints. > > >>> > > >>>It may take each endpoint sometime to actually notice that this has > > >>>occurred. Using common TCP state machine defaults, it will typically > > >>>take just under 10 minutes. It is also likely that the participants > > > > > > will > > > > > >>>not figure it out at the same time. > > >>> > > >>>If H figures it out first, then things are reasonable ok. It just > > > > > > waits > > > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > > > with > > > > > >>>the session URI. > > >>> > > >>>But if V figures it out first, we have a problem. V will reconnect, > > > > > > and > > > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > > >>>already has a perfectly good connection for that session. It has two > > >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > > > > > still > > > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > > > request > > > > > >>>on the new connection. > > >>> > > >>>Option 1 is the currently defined behavior. It seems pretty obvious > > > > > > that > > > > > >>>this pretty much prevents reconnections. Option 2 would allow > > >>>reconnections, but it allows a really nasty session hijacking attack > > > > > > if > > > > > >>>an attacker happens to learn the session URI. > > >>> > > >>>I discussed this with several people a while back, and the consensus > > >>>seemed to be that option 2 was not feasible, so we had to require a > > > > > > new > > > > > >>>sdp exchange with a new session URI in order to reconnect. > > >> > > >> > > > >> > > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > > > confidentiality > > > > > >>>of the session URI. If we were to accept option 1, we would then > > > > > > have a > > > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > > > either > > > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > > > also > > > > > >>>requires the host to listen for new connections pretty much forever, > > >>>which is not particularly pleasant. > > >>> > > >> > > >>For the above paragraph, I meant option 2. My apologies if anyone hurt > > >>their brain trying to figure out how that paragraph applied to option > > > > > > 1. > > > > > >> > > >>>Thoughts? Have I missed an option? > > >>> > > >> > > >> > > >> > > >>_______________________________________________ > > >>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 exim@www1.ietf.org Thu Dec 4 18:02:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23038 for ; Thu, 4 Dec 2003 18:02:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Tk-00062r-Cu for simple-archive@odin.ietf.org; Thu, 04 Dec 2003 18:01:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4N1mCL023236 for simple-archive@odin.ietf.org; Thu, 4 Dec 2003 18:01:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Tk-00062h-80 for simple-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22932; Thu, 4 Dec 2003 18:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS2Tg-0003yG-00; Thu, 04 Dec 2003 18:01:44 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AS2P7-0003tz-00; Thu, 04 Dec 2003 17:57:01 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AS2Am-00076n-2z; Thu, 04 Dec 2003 17:42:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS2Ac-0005gP-5X; Thu, 04 Dec 2003 17:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS29u-0005fg-Kf for simple@optimus.ietf.org; Thu, 04 Dec 2003 17:41:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22135 for ; Thu, 4 Dec 2003 17:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS29s-0003dL-00 for simple@ietf.org; Thu, 04 Dec 2003 17:41:16 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AS29q-0003dH-00 for simple@ietf.org; Thu, 04 Dec 2003 17:41:14 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 7A236B6656 for ; Thu, 4 Dec 2003 17:41:10 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003120417410931802 ; Thu, 04 Dec 2003 17:41:09 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Dec 2003 17:41:09 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Simple] Re: MS(r)P: Reconnect issue Message-ID: Thread-Topic: [Simple] Re: MS(r)P: Reconnect issue Thread-Index: AcO48zN43Q8UXgfzSZeRdGBN42qsqwAg61FA From: "Andrew Allen" To: "Michael Hammer" Cc: , X-OriginalArrivalTime: 04 Dec 2003 22:41:09.0917 (UTC) FILETIME=[B6715CD0:01C3BAB7] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Dec 2003 17:41:09 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Mike, Being a packet guy I am not sure what the relative priorities are for all networks during a circuit switched cellular handover however what you suggest makes sense. I am not sure what your point is though related to the MS(r)P reconnect issue. In GPRS the IP packet tunnel should be maintained during cell-cell handovers so the MS(r)P connection should not drop during handover. My main concern is that MS(r)P not have mandates (such as SDP encryption, use of TLS for SIP etc) put on it that make it incompatible with the cellular SIP infrastructure just because of this reconnection issue and that the wireless endpoints do not continually attempt to reconnect at the TCP layer consuming scarce radio resources when the far endpoint is either out of radio coverage or the battery is dead.=20 If an Invite or Update is sent as part of an existing dialog then this will not be seen as a "new call attempt" if that is your concern. Andrew > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, December 02, 2003 11:41 AM > To: Andrew Allen > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] Re: MS(r)P: Reconnect issue >=20 > Andrew, >=20 > Is it not true that for hand-offs in mobile networks that existing "calls" > being handed-off into new cells get precedence over new calls? >=20 > It seems that if you use the INVITE versus UPDATE methods, that you lose > this advantage and the dropped call rate will increase. However, if you > do > not feel that there is a resource contention issue, then this may not be a > problem. >=20 > Mike >=20 >=20 > At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: >=20 > >Ben > > > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec > >instead of TLS for security between itself and the mobile UA mandating > TLS > >for SIP/SDP will not help in the 3GPP situation either unless a radical > >change is made to the current 3GPP security architecture. > > > >If some people want to attempt reconnections without re-signaling is it > >possible to use the VISIT 200 OK exchange to initially negotiate support > >for reconnections and to exchange the necessary keys/certificates for > >validation that the reconnect attempt came from the same endpoint as the > >initial VISIT? > > > >I am not a security expert but if this is feasable then it would make > >reconnections possible but optional based on mutual negotiations between > >endpoints. If such a scheme requires TLS on the MS(r)P connection then > TLS > >or TCP could also be part of the SDP negotiation in the initial offer. > > > >For the wireless case I think we will want to use a renegotiation using > >SIP as it is most likely that one of the mobiles went out of radio > >coverage or that the battery died. In this case we want to detect using > >signaling as soon as possible that the mobile is unreachable so that the > >session can be released and the radio resources freed up. So I think you > >can place me in the re-signaling camp. > > > >Andrew > >-------------------------- > >Andrew Allen > >Manager Standards > >Research In Motion Ltd > >BlackBerry Mobile +1 847 809 8636 > >European Mobile +358 50 467 5870 > >http://www.rim.com/ > > > >Sent from my BlackBerry Wireless Handheld > > > > > >-----Original Message----- > >From: Ben Campbell > >To: Andrew Allen > >CC: Simple WG > >Sent: Mon Dec 01 22:40:06 2003 > >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > >Andrew Allen wrote: > > > > > Ben > > > > > > Ben, > > > > > > If Option 2 requires end-to-end encryption of the SDP to protect the > URL > > > then it is not going to be suitable for use by 3GPP for message > sessions > > > at the present time. The 3GPP network currently needs to examine the > SDP > > > to perform authorization and allocation of radio resources for the > > > session. > > > >A possible alternative is the use of the SIPS scheme, where the device > >that must inspect the SDP is a participant in one of the TLS > >handshakes--and therefore can see the contents. But I must admit that > >approach feels a little spooky. > > > > > > > > In the wireless case the chances of dropped connections are probably a > > > lot higher with the mobile potentially moving in and out of coverage > > > (especially if going through tunnels on a train) so this is likely to > be > > > a more common scenario in wireless. > > > > > > What were the main objections to re-invitation as a solution? > > > > > > >The objection was that such TCP drops happen alot, and people wanted the > >lightest weight recovery possible. If a simple TCP reconnect would work, > >it would be nice--but I don't think it will work. > > > > > Why not use UPDATE to attempt to re-establish connections in the case > > > when the dialog still exists? UPDATE is less expensive in terms of SIP > > > messages to re-establish (no ACK required). In the 3GPP case the > sending > > > of a SIP request is likely to trigger a network initiated termination > of > > > the session (a BYE) if the mobile is still out of coverage, which I > > > expect is what is desired in the wireless case to release the network > > > resources. > > > >If we establish that we must use a new SDP exchange, then I expect > >UPDATE and reinvites to both be applicable, depending on the particular > >circumstance. > > > > > > > > Andrew > > > > > > > > > > > > > > >>-----Original Message----- > > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>Sent: Monday, December 01, 2003 2:54 PM > > >>To: Ben Campbell > > >>Cc: Simple WG > > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > > >> > > >>Oops, got my options mixed up. See clarification below. > > >> > > >>Ben Campbell wrote: > > >> > > >> > > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > >>>rename) should allow reconnection of dropped TCP connections without > > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > > > there > > > > > >>>was a reason we had originally chose not to allow that, but I could > > > > > > not > > > > > >>>remember the details at the time. Having slept since then, I now > > >> > > >>remember: > > >> > > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > > > active > > > > > >>>session. That TCP connection is then dropped due to something in the > > >>>network. I don't know why, maybe a stateful firewall dropped state, > > > > > > or a > > > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > > > any > > > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > > > the > > > > > >>>endpoints. > > >>> > > >>>It may take each endpoint sometime to actually notice that this has > > >>>occurred. Using common TCP state machine defaults, it will typically > > >>>take just under 10 minutes. It is also likely that the participants > > > > > > will > > > > > >>>not figure it out at the same time. > > >>> > > >>>If H figures it out first, then things are reasonable ok. It just > > > > > > waits > > > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > > > with > > > > > >>>the session URI. > > >>> > > >>>But if V figures it out first, we have a problem. V will reconnect, > > > > > > and > > > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > > >>>already has a perfectly good connection for that session. It has two > > >>>possible choices: 1) Fail the new VISIT, and assume the old one is > > > > > > still > > > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > > > request > > > > > >>>on the new connection. > > >>> > > >>>Option 1 is the currently defined behavior. It seems pretty obvious > > > > > > that > > > > > >>>this pretty much prevents reconnections. Option 2 would allow > > >>>reconnections, but it allows a really nasty session hijacking attack > > > > > > if > > > > > >>>an attacker happens to learn the session URI. > > >>> > > >>>I discussed this with several people a while back, and the consensus > > >>>seemed to be that option 2 was not feasible, so we had to require a > > > > > > new > > > > > >>>sdp exchange with a new session URI in order to reconnect. > > >> > > >> > > > >> > > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > > > confidentiality > > > > > >>>of the session URI. If we were to accept option 1, we would then > > > > > > have a > > > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > > > either > > > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > > > also > > > > > >>>requires the host to listen for new connections pretty much forever, > > >>>which is not particularly pleasant. > > >>> > > >> > > >>For the above paragraph, I meant option 2. My apologies if anyone hurt > > >>their brain trying to figure out how that paragraph applied to option > > > > > > 1. > > > > > >> > > >>>Thoughts? Have I missed an option? > > >>> > > >> > > >> > > >> > > >>_______________________________________________ > > >>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-admin@ietf.org Thu Dec 4 18:48:31 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26182; Thu, 4 Dec 2003 18:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3DB-0004oU-00; Thu, 04 Dec 2003 18:48:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS3DB-0004oR-00; Thu, 04 Dec 2003 18:48:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3CS-0008C7-QF; Thu, 04 Dec 2003 18:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Ba-0008Au-MO for simple@optimus.ietf.org; Thu, 04 Dec 2003 18:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26116 for ; Thu, 4 Dec 2003 18:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3BU-0004n6-00 for simple@ietf.org; Thu, 04 Dec 2003 18:47:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AS3BR-0004lT-00 for simple@ietf.org; Thu, 04 Dec 2003 18:46:57 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2003 15:47:05 +0000 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB4NkMDM014006; Thu, 4 Dec 2003 18:46:23 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVK71882; Thu, 4 Dec 2003 15:46:21 -0800 (PST) Message-Id: <4.3.2.7.2.20031204181134.00b6fb60@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Andrew Allen" From: Michael Hammer Subject: RE: [Simple] Re: MS(r)P: Reconnect issue Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 18:46:21 -0500 Andrew, I may have misunderstood your previous posting. This thread seemed to imply that sending an UPDATE if the transaction fails due to temporary disconnect, would result in failure of the UPDATE only. Whereas, the failure of a re-INVITE would cause the network to send a BYE and release all resources down through the radio links. But, I had the impression that you were saying that in either case all resources would be freed assuming the user won't reappear. But, from a user's perspective, he would likely re-attempt the dialog or this may be automatic if he did not explicitly terminate it. Thus, the INVITE triggers lower level connection setup including perhaps the TCP that you don't want to be burdened with and at the GPRS and link layers this appears to be a new contention for resources, not a re-establishment of resources as in a handoff. So, in summary, the discussion went from how to resync the dialog due to connection interrupts, to using dialog layer to cause connection breaks, but not wanting re-TCP connections to be a burden. All I was suggesting was that using higher layer functions to cause break and reconnects would lead to the burdens you wanted to avoid, plus have the side effect of putting you at the end of the line for resource requests where contention might occur. Pardon the tangential nature of this sub-thread. Mike At 05:41 PM 12/4/2003 -0500, Andrew Allen wrote: >Mike, > >Being a packet guy I am not sure what the relative priorities are for >all networks during a circuit switched cellular handover however what >you suggest makes sense. > >I am not sure what your point is though related to the MS(r)P reconnect >issue. In GPRS the IP packet tunnel should be maintained during >cell-cell handovers so the MS(r)P connection should not drop during >handover. > >My main concern is that MS(r)P not have mandates (such as SDP >encryption, use of TLS for SIP etc) put on it that make it incompatible >with the cellular SIP infrastructure just because of this reconnection >issue and that the wireless endpoints do not continually attempt to >reconnect at the TCP layer consuming scarce radio resources when the far >endpoint is either out of radio coverage or the battery is dead. > >If an Invite or Update is sent as part of an existing dialog then this >will not be seen as a "new call attempt" if that is your concern. > >Andrew > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, December 02, 2003 11:41 AM > > To: Andrew Allen > > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > > Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > > Andrew, > > > > Is it not true that for hand-offs in mobile networks that existing >"calls" > > being handed-off into new cells get precedence over new calls? > > > > It seems that if you use the INVITE versus UPDATE methods, that you >lose > > this advantage and the dropped call rate will increase. However, if >you > > do > > not feel that there is a resource contention issue, then this may not >be a > > problem. > > > > Mike > > > > > > At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: > > > > >Ben > > > > > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec > > >instead of TLS for security between itself and the mobile UA >mandating > > TLS > > >for SIP/SDP will not help in the 3GPP situation either unless a >radical > > >change is made to the current 3GPP security architecture. > > > > > >If some people want to attempt reconnections without re-signaling is >it > > >possible to use the VISIT 200 OK exchange to initially negotiate >support > > >for reconnections and to exchange the necessary keys/certificates for > > >validation that the reconnect attempt came from the same endpoint as >the > > >initial VISIT? > > > > > >I am not a security expert but if this is feasable then it would make > > >reconnections possible but optional based on mutual negotiations >between > > >endpoints. If such a scheme requires TLS on the MS(r)P connection >then > > TLS > > >or TCP could also be part of the SDP negotiation in the initial >offer. > > > > > >For the wireless case I think we will want to use a renegotiation >using > > >SIP as it is most likely that one of the mobiles went out of radio > > >coverage or that the battery died. In this case we want to detect >using > > >signaling as soon as possible that the mobile is unreachable so that >the > > >session can be released and the radio resources freed up. So I think >you > > >can place me in the re-signaling camp. > > > > > >Andrew > > >-------------------------- > > >Andrew Allen > > >Manager Standards > > >Research In Motion Ltd > > >BlackBerry Mobile +1 847 809 8636 > > >European Mobile +358 50 467 5870 > > >http://www.rim.com/ > > > > > >Sent from my BlackBerry Wireless Handheld > > > > > > > > >-----Original Message----- > > >From: Ben Campbell > > >To: Andrew Allen > > >CC: Simple WG > > >Sent: Mon Dec 01 22:40:06 2003 > > >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > > > >Andrew Allen wrote: > > > > > > > Ben > > > > > > > > Ben, > > > > > > > > If Option 2 requires end-to-end encryption of the SDP to protect >the > > URL > > > > then it is not going to be suitable for use by 3GPP for message > > sessions > > > > at the present time. The 3GPP network currently needs to examine >the > > SDP > > > > to perform authorization and allocation of radio resources for the > > > > session. > > > > > >A possible alternative is the use of the SIPS scheme, where the >device > > >that must inspect the SDP is a participant in one of the TLS > > >handshakes--and therefore can see the contents. But I must admit that > > >approach feels a little spooky. > > > > > > > > > > > In the wireless case the chances of dropped connections are >probably a > > > > lot higher with the mobile potentially moving in and out of >coverage > > > > (especially if going through tunnels on a train) so this is likely >to > > be > > > > a more common scenario in wireless. > > > > > > > > What were the main objections to re-invitation as a solution? > > > > > > > > > >The objection was that such TCP drops happen alot, and people wanted >the > > >lightest weight recovery possible. If a simple TCP reconnect would >work, > > >it would be nice--but I don't think it will work. > > > > > > > Why not use UPDATE to attempt to re-establish connections in the >case > > > > when the dialog still exists? UPDATE is less expensive in terms of >SIP > > > > messages to re-establish (no ACK required). In the 3GPP case the > > sending > > > > of a SIP request is likely to trigger a network initiated >termination > > of > > > > the session (a BYE) if the mobile is still out of coverage, which >I > > > > expect is what is desired in the wireless case to release the >network > > > > resources. > > > > > >If we establish that we must use a new SDP exchange, then I expect > > >UPDATE and reinvites to both be applicable, depending on the >particular > > >circumstance. > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > >>Sent: Monday, December 01, 2003 2:54 PM > > > >>To: Ben Campbell > > > >>Cc: Simple WG > > > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > > > >> > > > >>Oops, got my options mixed up. See clarification below. > > > >> > > > >>Ben Campbell wrote: > > > >> > > > >> > > > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > > >>>rename) should allow reconnection of dropped TCP connections >without > > > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > > > > > there > > > > > > > >>>was a reason we had originally chose not to allow that, but I >could > > > > > > > > not > > > > > > > >>>remember the details at the time. Having slept since then, I now > > > >> > > > >>remember: > > > >> > > > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > > > > > active > > > > > > > >>>session. That TCP connection is then dropped due to something in >the > > > >>>network. I don't know why, maybe a stateful firewall dropped >state, > > > > > > > > or a > > > > > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > > > > > any > > > > > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > > > > > the > > > > > > > >>>endpoints. > > > >>> > > > >>>It may take each endpoint sometime to actually notice that this >has > > > >>>occurred. Using common TCP state machine defaults, it will >typically > > > >>>take just under 10 minutes. It is also likely that the >participants > > > > > > > > will > > > > > > > >>>not figure it out at the same time. > > > >>> > > > >>>If H figures it out first, then things are reasonable ok. It just > > > > > > > > waits > > > > > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > > > > > with > > > > > > > >>>the session URI. > > > >>> > > > >>>But if V figures it out first, we have a problem. V will >reconnect, > > > > > > > > and > > > > > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > > > >>>already has a perfectly good connection for that session. It has >two > > > >>>possible choices: 1) Fail the new VISIT, and assume the old one >is > > > > > > > > still > > > > > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > > > > > request > > > > > > > >>>on the new connection. > > > >>> > > > >>>Option 1 is the currently defined behavior. It seems pretty >obvious > > > > > > > > that > > > > > > > >>>this pretty much prevents reconnections. Option 2 would allow > > > >>>reconnections, but it allows a really nasty session hijacking >attack > > > > > > > > if > > > > > > > >>>an attacker happens to learn the session URI. > > > >>> > > > >>>I discussed this with several people a while back, and the >consensus > > > >>>seemed to be that option 2 was not feasible, so we had to require >a > > > > > > > > new > > > > > > > >>>sdp exchange with a new session URI in order to reconnect. > > > >> > > > >> > > > > >> > > > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > > > > > confidentiality > > > > > > > >>>of the session URI. If we were to accept option 1, we would then > > > > > > > > have a > > > > > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > > > > > either > > > > > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > > > > > also > > > > > > > >>>requires the host to listen for new connections pretty much >forever, > > > >>>which is not particularly pleasant. > > > >>> > > > >> > > > >>For the above paragraph, I meant option 2. My apologies if anyone >hurt > > > >>their brain trying to figure out how that paragraph applied to >option > > > > > > > > 1. > > > > > > > >> > > > >>>Thoughts? Have I missed an option? > > > >>> > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>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 exim@www1.ietf.org Thu Dec 4 18:49:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26218 for ; Thu, 4 Dec 2003 18:49:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3DF-0008HH-Jb for simple-archive@odin.ietf.org; Thu, 04 Dec 2003 18:48:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Nmn70031813 for simple-archive@odin.ietf.org; Thu, 4 Dec 2003 18:48:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3DF-0008H2-Et for simple-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 18:48:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26182; Thu, 4 Dec 2003 18:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3DB-0004oU-00; Thu, 04 Dec 2003 18:48:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS3DB-0004oR-00; Thu, 04 Dec 2003 18:48:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3CS-0008C7-QF; Thu, 04 Dec 2003 18:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS3Ba-0008Au-MO for simple@optimus.ietf.org; Thu, 04 Dec 2003 18:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26116 for ; Thu, 4 Dec 2003 18:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS3BU-0004n6-00 for simple@ietf.org; Thu, 04 Dec 2003 18:47:00 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AS3BR-0004lT-00 for simple@ietf.org; Thu, 04 Dec 2003 18:46:57 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2003 15:47:05 +0000 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB4NkMDM014006; Thu, 4 Dec 2003 18:46:23 -0500 (EST) Received: from mhammer-w2k03.cisco.com (dhcp-hrn-64-100-229-166.cisco.com [64.100.229.166]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AVK71882; Thu, 4 Dec 2003 15:46:21 -0800 (PST) Message-Id: <4.3.2.7.2.20031204181134.00b6fb60@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Andrew Allen" From: Michael Hammer Subject: RE: [Simple] Re: MS(r)P: Reconnect issue Cc: , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 04 Dec 2003 18:46:21 -0500 Andrew, I may have misunderstood your previous posting. This thread seemed to imply that sending an UPDATE if the transaction fails due to temporary disconnect, would result in failure of the UPDATE only. Whereas, the failure of a re-INVITE would cause the network to send a BYE and release all resources down through the radio links. But, I had the impression that you were saying that in either case all resources would be freed assuming the user won't reappear. But, from a user's perspective, he would likely re-attempt the dialog or this may be automatic if he did not explicitly terminate it. Thus, the INVITE triggers lower level connection setup including perhaps the TCP that you don't want to be burdened with and at the GPRS and link layers this appears to be a new contention for resources, not a re-establishment of resources as in a handoff. So, in summary, the discussion went from how to resync the dialog due to connection interrupts, to using dialog layer to cause connection breaks, but not wanting re-TCP connections to be a burden. All I was suggesting was that using higher layer functions to cause break and reconnects would lead to the burdens you wanted to avoid, plus have the side effect of putting you at the end of the line for resource requests where contention might occur. Pardon the tangential nature of this sub-thread. Mike At 05:41 PM 12/4/2003 -0500, Andrew Allen wrote: >Mike, > >Being a packet guy I am not sure what the relative priorities are for >all networks during a circuit switched cellular handover however what >you suggest makes sense. > >I am not sure what your point is though related to the MS(r)P reconnect >issue. In GPRS the IP packet tunnel should be maintained during >cell-cell handovers so the MS(r)P connection should not drop during >handover. > >My main concern is that MS(r)P not have mandates (such as SDP >encryption, use of TLS for SIP etc) put on it that make it incompatible >with the cellular SIP infrastructure just because of this reconnection >issue and that the wireless endpoints do not continually attempt to >reconnect at the TCP layer consuming scarce radio resources when the far >endpoint is either out of radio coverage or the battery is dead. > >If an Invite or Update is sent as part of an existing dialog then this >will not be seen as a "new call attempt" if that is your concern. > >Andrew > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, December 02, 2003 11:41 AM > > To: Andrew Allen > > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > > Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > > Andrew, > > > > Is it not true that for hand-offs in mobile networks that existing >"calls" > > being handed-off into new cells get precedence over new calls? > > > > It seems that if you use the INVITE versus UPDATE methods, that you >lose > > this advantage and the dropped call rate will increase. However, if >you > > do > > not feel that there is a resource contention issue, then this may not >be a > > problem. > > > > Mike > > > > > > At 08:47 AM 12/2/2003 -0500, Andrew Allen wrote: > > > > >Ben > > > > > >Since the 3GPP edge proxy (P-CSCF) that examines the SDP uses IPsec > > >instead of TLS for security between itself and the mobile UA >mandating > > TLS > > >for SIP/SDP will not help in the 3GPP situation either unless a >radical > > >change is made to the current 3GPP security architecture. > > > > > >If some people want to attempt reconnections without re-signaling is >it > > >possible to use the VISIT 200 OK exchange to initially negotiate >support > > >for reconnections and to exchange the necessary keys/certificates for > > >validation that the reconnect attempt came from the same endpoint as >the > > >initial VISIT? > > > > > >I am not a security expert but if this is feasable then it would make > > >reconnections possible but optional based on mutual negotiations >between > > >endpoints. If such a scheme requires TLS on the MS(r)P connection >then > > TLS > > >or TCP could also be part of the SDP negotiation in the initial >offer. > > > > > >For the wireless case I think we will want to use a renegotiation >using > > >SIP as it is most likely that one of the mobiles went out of radio > > >coverage or that the battery died. In this case we want to detect >using > > >signaling as soon as possible that the mobile is unreachable so that >the > > >session can be released and the radio resources freed up. So I think >you > > >can place me in the re-signaling camp. > > > > > >Andrew > > >-------------------------- > > >Andrew Allen > > >Manager Standards > > >Research In Motion Ltd > > >BlackBerry Mobile +1 847 809 8636 > > >European Mobile +358 50 467 5870 > > >http://www.rim.com/ > > > > > >Sent from my BlackBerry Wireless Handheld > > > > > > > > >-----Original Message----- > > >From: Ben Campbell > > >To: Andrew Allen > > >CC: Simple WG > > >Sent: Mon Dec 01 22:40:06 2003 > > >Subject: Re: [Simple] Re: MS(r)P: Reconnect issue > > > > > >Andrew Allen wrote: > > > > > > > Ben > > > > > > > > Ben, > > > > > > > > If Option 2 requires end-to-end encryption of the SDP to protect >the > > URL > > > > then it is not going to be suitable for use by 3GPP for message > > sessions > > > > at the present time. The 3GPP network currently needs to examine >the > > SDP > > > > to perform authorization and allocation of radio resources for the > > > > session. > > > > > >A possible alternative is the use of the SIPS scheme, where the >device > > >that must inspect the SDP is a participant in one of the TLS > > >handshakes--and therefore can see the contents. But I must admit that > > >approach feels a little spooky. > > > > > > > > > > > In the wireless case the chances of dropped connections are >probably a > > > > lot higher with the mobile potentially moving in and out of >coverage > > > > (especially if going through tunnels on a train) so this is likely >to > > be > > > > a more common scenario in wireless. > > > > > > > > What were the main objections to re-invitation as a solution? > > > > > > > > > >The objection was that such TCP drops happen alot, and people wanted >the > > >lightest weight recovery possible. If a simple TCP reconnect would >work, > > >it would be nice--but I don't think it will work. > > > > > > > Why not use UPDATE to attempt to re-establish connections in the >case > > > > when the dialog still exists? UPDATE is less expensive in terms of >SIP > > > > messages to re-establish (no ACK required). In the 3GPP case the > > sending > > > > of a SIP request is likely to trigger a network initiated >termination > > of > > > > the session (a BYE) if the mobile is still out of coverage, which >I > > > > expect is what is desired in the wireless case to release the >network > > > > resources. > > > > > >If we establish that we must use a new SDP exchange, then I expect > > >UPDATE and reinvites to both be applicable, depending on the >particular > > >circumstance. > > > > > > > > > > > Andrew > > > > > > > > > > > > > > > > > > > >>-----Original Message----- > > > >>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > >>Sent: Monday, December 01, 2003 2:54 PM > > > >>To: Ben Campbell > > > >>Cc: Simple WG > > > >>Subject: [Simple] Re: MS(r)P: Reconnect issue > > > >> > > > >>Oops, got my options mixed up. See clarification below. > > > >> > > > >>Ben Campbell wrote: > > > >> > > > >> > > > >>>In Minneapolis, the wg expressed a consensus that MS(r)P (pending > > > >>>rename) should allow reconnection of dropped TCP connections >without > > > >>>requiring a new offer/answer. In that meeting, I mentioned that > > > > > > > > there > > > > > > > >>>was a reason we had originally chose not to allow that, but I >could > > > > > > > > not > > > > > > > >>>remember the details at the time. Having slept since then, I now > > > >> > > > >>remember: > > > >> > > > >>>Consider a visitor V has a TCP connection to a host H, with an > > > > > > > > active > > > > > > > >>>session. That TCP connection is then dropped due to something in >the > > > >>>network. I don't know why, maybe a stateful firewall dropped >state, > > > > > > > > or a > > > > > > > >>>length of fiber was accidentally eaten by a sabre-tooth tiger. In > > > > > > > > any > > > > > > > >>>case, the connection is dropped without a proper FIN handshake at > > > > > > > > the > > > > > > > >>>endpoints. > > > >>> > > > >>>It may take each endpoint sometime to actually notice that this >has > > > >>>occurred. Using common TCP state machine defaults, it will >typically > > > >>>take just under 10 minutes. It is also likely that the >participants > > > > > > > > will > > > > > > > >>>not figure it out at the same time. > > > >>> > > > >>>If H figures it out first, then things are reasonable ok. It just > > > > > > > > waits > > > > > > > >>>some period of time for V to notice, reconnect, and send a VISIT > > > > > > > > with > > > > > > > >>>the session URI. > > > >>> > > > >>>But if V figures it out first, we have a problem. V will >reconnect, > > > > > > > > and > > > > > > > >>>attempt a VISIT with the session URI. The problem is, H thinks it > > > >>>already has a perfectly good connection for that session. It has >two > > > >>>possible choices: 1) Fail the new VISIT, and assume the old one >is > > > > > > > > still > > > > > > > >>>good, or 2) Disconnect the old connection, and accept the VISIT > > > > > > > > request > > > > > > > >>>on the new connection. > > > >>> > > > >>>Option 1 is the currently defined behavior. It seems pretty >obvious > > > > > > > > that > > > > > > > >>>this pretty much prevents reconnections. Option 2 would allow > > > >>>reconnections, but it allows a really nasty session hijacking >attack > > > > > > > > if > > > > > > > >>>an attacker happens to learn the session URI. > > > >>> > > > >>>I discussed this with several people a while back, and the >consensus > > > >>>seemed to be that option 2 was not feasible, so we had to require >a > > > > > > > > new > > > > > > > >>>sdp exchange with a new session URI in order to reconnect. > > > >> > > > >> > > > > >> > > > >>>Option 1 _might_ be acceptable if we could guarantee the > > > > > > > > confidentiality > > > > > > > >>>of the session URI. If we were to accept option 1, we would then > > > > > > > > have a > > > > > > > >>>strong reason to _require_ the sdp exchange be protected by using > > > > > > > > either > > > > > > > >>>SIPS or e2e crypto, and that the VISIT be sent over TLS. Option 1 > > > > > > > > also > > > > > > > >>>requires the host to listen for new connections pretty much >forever, > > > >>>which is not particularly pleasant. > > > >>> > > > >> > > > >>For the above paragraph, I meant option 2. My apologies if anyone >hurt > > > >>their brain trying to figure out how that paragraph applied to >option > > > > > > > > 1. > > > > > > > >> > > > >>>Thoughts? Have I missed an option? > > > >>> > > > >> > > > >> > > > >> > > > >>_______________________________________________ > > > >>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-admin@ietf.org Fri Dec 5 04:31:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27847; Fri, 5 Dec 2003 04:31:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJi-0005pC-00; Fri, 05 Dec 2003 04:32:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCJh-0005p9-00; Fri, 05 Dec 2003 04:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJd-00044L-Rj; Fri, 05 Dec 2003 04:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJ6-00043L-MF for simple@optimus.ietf.org; Fri, 05 Dec 2003 04:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27842 for ; Fri, 5 Dec 2003 04:31:13 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJ3-0005nd-00 for simple@ietf.org; Fri, 05 Dec 2003 04:31:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJ2-0005nC-00 for simple@ietf.org; Fri, 05 Dec 2003 04:31:24 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB59UpZ17584 for ; Fri, 5 Dec 2003 11:30:51 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Dec 2003 11:30:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 11:30:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> Thread-Topic: MSRP or MSP Thread-Index: AcO7EncwdPCV3YjzReaK0GX9W8DUYw== To: X-OriginalArrivalTime: 05 Dec 2003 09:30:49.0642 (UTC) FILETIME=[782B60A0:01C3BB12] Content-Transfer-Encoding: quoted-printable Subject: [Simple] MSRP or MSP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Dec 2003 11:30:49 +0200 Content-Transfer-Encoding: quoted-printable We need decide on the name of the protocol. So which one is it going to = be? I vote for MSP, what's yours? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 5 04:32:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27863 for ; Fri, 5 Dec 2003 04:32:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJm-00045F-Mh for simple-archive@odin.ietf.org; Fri, 05 Dec 2003 04:32:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB59WAex015692 for simple-archive@odin.ietf.org; Fri, 5 Dec 2003 04:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJl-000451-O2 for simple-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 04:32:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27847; Fri, 5 Dec 2003 04:31:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJi-0005pC-00; Fri, 05 Dec 2003 04:32:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASCJh-0005p9-00; Fri, 05 Dec 2003 04:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJd-00044L-Rj; Fri, 05 Dec 2003 04:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASCJ6-00043L-MF for simple@optimus.ietf.org; Fri, 05 Dec 2003 04:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27842 for ; Fri, 5 Dec 2003 04:31:13 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJ3-0005nd-00 for simple@ietf.org; Fri, 05 Dec 2003 04:31:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1ASCJ2-0005nC-00 for simple@ietf.org; Fri, 05 Dec 2003 04:31:24 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB59UpZ17584 for ; Fri, 5 Dec 2003 11:30:51 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 5 Dec 2003 11:30:50 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 5 Dec 2003 11:30:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> Thread-Topic: MSRP or MSP Thread-Index: AcO7EncwdPCV3YjzReaK0GX9W8DUYw== To: X-OriginalArrivalTime: 05 Dec 2003 09:30:49.0642 (UTC) FILETIME=[782B60A0:01C3BB12] Content-Transfer-Encoding: quoted-printable Subject: [Simple] MSRP or MSP Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Dec 2003 11:30:49 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We need decide on the name of the protocol. So which one is it going to = be? I vote for MSP, what's yours? Regards, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 8 06:58:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06537; Mon, 8 Dec 2003 06:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATK1x-0001ks-00; Mon, 08 Dec 2003 06:58:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATK1w-0001km-00; Mon, 08 Dec 2003 06:58:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK1a-0002ZQ-JO; Mon, 08 Dec 2003 06:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK19-0002Yl-F5 for simple@optimus.ietf.org; Mon, 08 Dec 2003 06:57:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06493 for ; Mon, 8 Dec 2003 06:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATK15-0001k3-00 for simple@ietf.org; Mon, 08 Dec 2003 06:57:31 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ATK14-0001k0-00 for simple@ietf.org; Mon, 08 Dec 2003 06:57:30 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB8BvTSs027861; Mon, 8 Dec 2003 12:57:29 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW74B1J4; Mon, 8 Dec 2003 12:57:29 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.152]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B085D18A82; Mon, 8 Dec 2003 13:57:28 +0200 (EET) Message-ID: <3FD46728.9070401@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell Cc: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> In-Reply-To: <200312021749.42661.david.partain@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 13:57:28 +0200 Content-Transfer-Encoding: 7bit Ben: I think there is something unclear with the management of the timeout value that we can find in the direction attribute when the direction is set to "both", as David is suggesting below. According to the spec, I got the impression that the timer is only applicable to the ***answerer***, i.e., that the offerer cannot use it. both: The endpoint is willing to act as either host or visitor. If "both" is selected, it may contain an optional timeout value. This timeout specifies how much time the answerer should wait before giving up on a connection and attempting to take over as host device. If the timeout value is not specified, it defaults to 30 seconds. However, later in the spec, I found out that the answerer cannot use "both" at all: The SDP answer also MUST contain a direction attribute, but its value choices are limited based on the value in the offer.... If the offer contained "both", the answerer SHOULD select "active", but MAY select"passive" if it is unable to reach the host device, or if local policy requires it to act as host. And then later, when the spec indicates how the offerer builds the offer: 4. Insert a direction attribute. This value SHOULD be "both", indicating that the offerer will allow the answerer to override the offerer's decision to host. If "both" is selected, the offerer SHOULD leave the timeout at the default value (by leaving out the value entirely. However, the offerer MAY select a different timeout if circumstances warrant it. The direction value MAY be "passive" if the offerer is prevented from allowing the answerer override this choice. So the questions to solve are: 1) What is the purpose of this timer? An scenario where it is used will help to understand it. 2) Is it possible to use it in offers or answers or both? 3) How does the offerer use this timer? In most circumstances the answers will reply with an "active" direction, so what are the actions at the offerer? Any light to solve these questions is appreciated. Regards, Miguel David Partain (LI/EAB) wrote: > Greetings, > > I don't understand the timer associated with the both direction > attribute (page 11 in the -02 version). I'd be really grateful > if someone could explain to me how it works. > > The text says that this timer specifies how long the "answerer" > should wait before giving up on the connection and trying to > take over has host for the session. > > If I send an INVITE with "both" and set the timer to 45 seconds, > I've also supplied an MSRP URL that the answerer can use to > VISIT me. Does the timer start when the answerer sends the > VISIT to the offerer at the MSRP URL? It doesn't make much > sense to me that the offerer should tell the answerer to wait > after sending the VISIT, but I'm probably missing something. > > And if the answerer doesn't get an OK for the VISIT within > the alloted 45 seconds, what then? How is it expected to take > over as host? > > Is "answerer" above really supposed to be "offerer"? I don't > see how that works either, though, since the offerer has no > URL to VISIT. > > I'm just generally confused and don't understand the timer. > Would some kind soul please enlighten me? > > Thanks much. > > David > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 8 06:58:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06607 for ; Mon, 8 Dec 2003 06:58:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK22-0002l1-4q for simple-archive@odin.ietf.org; Mon, 08 Dec 2003 06:58:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8BwUlj010600 for simple-archive@odin.ietf.org; Mon, 8 Dec 2003 06:58:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK22-0002kt-1F for simple-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 06:58:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06537; Mon, 8 Dec 2003 06:58:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATK1x-0001ks-00; Mon, 08 Dec 2003 06:58:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATK1w-0001km-00; Mon, 08 Dec 2003 06:58:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK1a-0002ZQ-JO; Mon, 08 Dec 2003 06:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATK19-0002Yl-F5 for simple@optimus.ietf.org; Mon, 08 Dec 2003 06:57:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06493 for ; Mon, 8 Dec 2003 06:57:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATK15-0001k3-00 for simple@ietf.org; Mon, 08 Dec 2003 06:57:31 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ATK14-0001k0-00 for simple@ietf.org; Mon, 08 Dec 2003 06:57:30 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB8BvTSs027861; Mon, 8 Dec 2003 12:57:29 +0100 (MET) Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW74B1J4; Mon, 8 Dec 2003 12:57:29 +0100 Received: from ericsson.com (EFQ240013L1IJOG.lmf.ericsson.se [131.160.31.152]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B085D18A82; Mon, 8 Dec 2003 13:57:28 +0200 (EET) Message-ID: <3FD46728.9070401@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell Cc: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> In-Reply-To: <200312021749.42661.david.partain@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 13:57:28 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben: I think there is something unclear with the management of the timeout value that we can find in the direction attribute when the direction is set to "both", as David is suggesting below. According to the spec, I got the impression that the timer is only applicable to the ***answerer***, i.e., that the offerer cannot use it. both: The endpoint is willing to act as either host or visitor. If "both" is selected, it may contain an optional timeout value. This timeout specifies how much time the answerer should wait before giving up on a connection and attempting to take over as host device. If the timeout value is not specified, it defaults to 30 seconds. However, later in the spec, I found out that the answerer cannot use "both" at all: The SDP answer also MUST contain a direction attribute, but its value choices are limited based on the value in the offer.... If the offer contained "both", the answerer SHOULD select "active", but MAY select"passive" if it is unable to reach the host device, or if local policy requires it to act as host. And then later, when the spec indicates how the offerer builds the offer: 4. Insert a direction attribute. This value SHOULD be "both", indicating that the offerer will allow the answerer to override the offerer's decision to host. If "both" is selected, the offerer SHOULD leave the timeout at the default value (by leaving out the value entirely. However, the offerer MAY select a different timeout if circumstances warrant it. The direction value MAY be "passive" if the offerer is prevented from allowing the answerer override this choice. So the questions to solve are: 1) What is the purpose of this timer? An scenario where it is used will help to understand it. 2) Is it possible to use it in offers or answers or both? 3) How does the offerer use this timer? In most circumstances the answers will reply with an "active" direction, so what are the actions at the offerer? Any light to solve these questions is appreciated. Regards, Miguel David Partain (LI/EAB) wrote: > Greetings, > > I don't understand the timer associated with the both direction > attribute (page 11 in the -02 version). I'd be really grateful > if someone could explain to me how it works. > > The text says that this timer specifies how long the "answerer" > should wait before giving up on the connection and trying to > take over has host for the session. > > If I send an INVITE with "both" and set the timer to 45 seconds, > I've also supplied an MSRP URL that the answerer can use to > VISIT me. Does the timer start when the answerer sends the > VISIT to the offerer at the MSRP URL? It doesn't make much > sense to me that the offerer should tell the answerer to wait > after sending the VISIT, but I'm probably missing something. > > And if the answerer doesn't get an OK for the VISIT within > the alloted 45 seconds, what then? How is it expected to take > over as host? > > Is "answerer" above really supposed to be "offerer"? I don't > see how that works either, though, since the offerer has no > URL to VISIT. > > I'm just generally confused and don't understand the timer. > Would some kind soul please enlighten me? > > Thanks much. > > David > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 8 15:00:52 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27252; Mon, 8 Dec 2003 15:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRZ3-0003m9-00; Mon, 08 Dec 2003 15:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATRZ3-0003m6-00; Mon, 08 Dec 2003 15:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRYz-000262-8X; Mon, 08 Dec 2003 15:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRYn-000257-30 for simple@optimus.ietf.org; Mon, 08 Dec 2003 15:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27242 for ; Mon, 8 Dec 2003 15:00:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRYk-0003lp-00 for simple@ietf.org; Mon, 08 Dec 2003 15:00:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ATRYj-0003lh-00 for simple@ietf.org; Mon, 08 Dec 2003 15:00:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB8K0JnG056040; Mon, 8 Dec 2003 14:00:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD4D848.7060700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> <3FD46728.9070401@ericsson.com> In-Reply-To: <3FD46728.9070401@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 14:00:08 -0600 Content-Transfer-Encoding: 7bit Sorry, I somehow missed the original note in my usual deluge of mail. Comments inline to both emails inline: Miguel A. Garcia wrote: > Ben: > > I think there is something unclear with the management of the timeout > value that we can find in the direction attribute when the direction is > set to "both", as David is suggesting below. > > According to the spec, I got the impression that the timer is only > applicable to the ***answerer***, i.e., that the offerer cannot use it. > It depends on what you man by use it. Only the offerer can create an SDP document with direction=both, so only the offerer can select this value. But it only useful in the situation where an endpoint attempts to act as a visitor (i.e. active), is unable to connect, and then attempts to act as host (i.e. passive). > both: The endpoint is willing to act as either host or visitor. If > "both" is selected, it may contain an optional timeout value. This > timeout specifies how much time the answerer should wait before > giving up on a connection and attempting to take over as host > device. If the timeout value is not specified, it defaults to 30 > seconds. > > However, later in the spec, I found out that the answerer cannot use > "both" at all: > > The SDP answer also MUST contain a direction attribute, but its value > choices are limited based on the value in the offer.... > > If the offer contained "both", the answerer SHOULD select "active", > but MAY select"passive" if it is unable to reach the host device, > or if local policy requires it to act as host. That is correct--the answerer will never insert direction=both in the SDP answer. We allow the offerer to tell the answerer "You decide." But we do not allow the answerer to come back and say, "No, you decide." (Believe me, watching my wife and I try to select a restaurant would offer an example of why this is not a good idea :-) ) > > And then later, when the spec indicates how the offerer builds the offer: > > 4. Insert a direction attribute. This value SHOULD be "both", > indicating that the offerer will allow the answerer to override > the offerer's decision to host. If "both" is selected, the > offerer SHOULD leave the timeout at the default value (by leaving > out the value entirely. However, the offerer MAY select a > different timeout if circumstances warrant it. The direction > value MAY be "passive" if the offerer is prevented from allowing > the answerer override this choice. > > So the questions to solve are: > > 1) What is the purpose of this timer? An scenario where it is used will > help to understand it. The general idea was to improve session setup time when an answerer is unable to connect to the host device. Assume A is the offerer and B is the answerer. B attempts a TCP connection to A, which fails. B then sends an SDP response instructing A to connect to B instead. Since it can take some time for a TCP connectin attempt to fail, and since if it takes a real long time to connect, it is likely that network conditions are not particularly good along that path, we specify a shorter time limit after which B should give up. We give A the ability to modify that limit from the default if A knows something about the network conditions that make the default inappropriate. > > 2) Is it possible to use it in offers or answers or both? > What do you mean by "use"? It is only specified by the offerer, but it is only acted upon by the answerer. > 3) How does the offerer use this timer? In most circumstances the > answers will reply with an "active" direction, so what are the actions > at the offerer? If the answer contains "active", the offerer does nothing with this timer value. Keep in mind, B does not return a response until _after_ it successfully visits the host, or fails to do so. If it succeeded in visiting, it returns active. If it fails, and wants to let A attempt to connect to it, it returns passive. > > Any light to solve these questions is appreciated. > > Regards, > > Miguel > > David Partain (LI/EAB) wrote: > >> Greetings, >> >> I don't understand the timer associated with the both direction >> attribute (page 11 in the -02 version). I'd be really grateful >> if someone could explain to me how it works. >> >> The text says that this timer specifies how long the "answerer" >> should wait before giving up on the connection and trying to >> take over has host for the session. >> >> If I send an INVITE with "both" and set the timer to 45 seconds, >> I've also supplied an MSRP URL that the answerer can use to >> VISIT me. Does the timer start when the answerer sends the >> VISIT to the offerer at the MSRP URL? It doesn't make much >> sense to me that the offerer should tell the answerer to wait >> after sending the VISIT, but I'm probably missing something. The timer starts when the answerer attempts to open a TCP connection to the host device. If the connection attempt has not completed in 45 seconds, it may abandon the connection and assume a passive role by returning a response with direction=passive. >> >> And if the answerer doesn't get an OK for the VISIT within >> the alloted 45 seconds, what then? How is it expected to take >> over as host? The timer does not apply to the VISIT transaction. It only applies to the attempt to open the TCP connection. >> >> Is "answerer" above really supposed to be "offerer"? I don't >> see how that works either, though, since the offerer has no >> URL to VISIT. No, the offerer never acts upon this timer value. It may select a value for the answerer to use. >> >> I'm just generally confused and don't understand the timer. >> Would some kind soul please enlighten me? >> >> Thanks much. >> >> David >> >> >> >> _______________________________________________ >> 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 exim@www1.ietf.org Mon Dec 8 15:01:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27293 for ; Mon, 8 Dec 2003 15:01:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRZ7-00027f-N4 for simple-archive@odin.ietf.org; Mon, 08 Dec 2003 15:01:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8K19FR008155 for simple-archive@odin.ietf.org; Mon, 8 Dec 2003 15:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRZ7-00027S-II for simple-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 15:01:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27252; Mon, 8 Dec 2003 15:00:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRZ3-0003m9-00; Mon, 08 Dec 2003 15:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATRZ3-0003m6-00; Mon, 08 Dec 2003 15:01:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRYz-000262-8X; Mon, 08 Dec 2003 15:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRYn-000257-30 for simple@optimus.ietf.org; Mon, 08 Dec 2003 15:00:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27242 for ; Mon, 8 Dec 2003 15:00:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRYk-0003lp-00 for simple@ietf.org; Mon, 08 Dec 2003 15:00:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ATRYj-0003lh-00 for simple@ietf.org; Mon, 08 Dec 2003 15:00:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB8K0JnG056040; Mon, 8 Dec 2003 14:00:30 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD4D848.7060700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Miguel A. Garcia" CC: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> <3FD46728.9070401@ericsson.com> In-Reply-To: <3FD46728.9070401@ericsson.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 14:00:08 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry, I somehow missed the original note in my usual deluge of mail. Comments inline to both emails inline: Miguel A. Garcia wrote: > Ben: > > I think there is something unclear with the management of the timeout > value that we can find in the direction attribute when the direction is > set to "both", as David is suggesting below. > > According to the spec, I got the impression that the timer is only > applicable to the ***answerer***, i.e., that the offerer cannot use it. > It depends on what you man by use it. Only the offerer can create an SDP document with direction=both, so only the offerer can select this value. But it only useful in the situation where an endpoint attempts to act as a visitor (i.e. active), is unable to connect, and then attempts to act as host (i.e. passive). > both: The endpoint is willing to act as either host or visitor. If > "both" is selected, it may contain an optional timeout value. This > timeout specifies how much time the answerer should wait before > giving up on a connection and attempting to take over as host > device. If the timeout value is not specified, it defaults to 30 > seconds. > > However, later in the spec, I found out that the answerer cannot use > "both" at all: > > The SDP answer also MUST contain a direction attribute, but its value > choices are limited based on the value in the offer.... > > If the offer contained "both", the answerer SHOULD select "active", > but MAY select"passive" if it is unable to reach the host device, > or if local policy requires it to act as host. That is correct--the answerer will never insert direction=both in the SDP answer. We allow the offerer to tell the answerer "You decide." But we do not allow the answerer to come back and say, "No, you decide." (Believe me, watching my wife and I try to select a restaurant would offer an example of why this is not a good idea :-) ) > > And then later, when the spec indicates how the offerer builds the offer: > > 4. Insert a direction attribute. This value SHOULD be "both", > indicating that the offerer will allow the answerer to override > the offerer's decision to host. If "both" is selected, the > offerer SHOULD leave the timeout at the default value (by leaving > out the value entirely. However, the offerer MAY select a > different timeout if circumstances warrant it. The direction > value MAY be "passive" if the offerer is prevented from allowing > the answerer override this choice. > > So the questions to solve are: > > 1) What is the purpose of this timer? An scenario where it is used will > help to understand it. The general idea was to improve session setup time when an answerer is unable to connect to the host device. Assume A is the offerer and B is the answerer. B attempts a TCP connection to A, which fails. B then sends an SDP response instructing A to connect to B instead. Since it can take some time for a TCP connectin attempt to fail, and since if it takes a real long time to connect, it is likely that network conditions are not particularly good along that path, we specify a shorter time limit after which B should give up. We give A the ability to modify that limit from the default if A knows something about the network conditions that make the default inappropriate. > > 2) Is it possible to use it in offers or answers or both? > What do you mean by "use"? It is only specified by the offerer, but it is only acted upon by the answerer. > 3) How does the offerer use this timer? In most circumstances the > answers will reply with an "active" direction, so what are the actions > at the offerer? If the answer contains "active", the offerer does nothing with this timer value. Keep in mind, B does not return a response until _after_ it successfully visits the host, or fails to do so. If it succeeded in visiting, it returns active. If it fails, and wants to let A attempt to connect to it, it returns passive. > > Any light to solve these questions is appreciated. > > Regards, > > Miguel > > David Partain (LI/EAB) wrote: > >> Greetings, >> >> I don't understand the timer associated with the both direction >> attribute (page 11 in the -02 version). I'd be really grateful >> if someone could explain to me how it works. >> >> The text says that this timer specifies how long the "answerer" >> should wait before giving up on the connection and trying to >> take over has host for the session. >> >> If I send an INVITE with "both" and set the timer to 45 seconds, >> I've also supplied an MSRP URL that the answerer can use to >> VISIT me. Does the timer start when the answerer sends the >> VISIT to the offerer at the MSRP URL? It doesn't make much >> sense to me that the offerer should tell the answerer to wait >> after sending the VISIT, but I'm probably missing something. The timer starts when the answerer attempts to open a TCP connection to the host device. If the connection attempt has not completed in 45 seconds, it may abandon the connection and assume a passive role by returning a response with direction=passive. >> >> And if the answerer doesn't get an OK for the VISIT within >> the alloted 45 seconds, what then? How is it expected to take >> over as host? The timer does not apply to the VISIT transaction. It only applies to the attempt to open the TCP connection. >> >> Is "answerer" above really supposed to be "offerer"? I don't >> see how that works either, though, since the offerer has no >> URL to VISIT. No, the offerer never acts upon this timer value. It may select a value for the answerer to use. >> >> I'm just generally confused and don't understand the timer. >> Would some kind soul please enlighten me? >> >> Thanks much. >> >> David >> >> >> >> _______________________________________________ >> 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-admin@ietf.org Mon Dec 8 15:49:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02041; Mon, 8 Dec 2003 15:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSKR-0005Fn-00; Mon, 08 Dec 2003 15:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATSKQ-0005Fk-00; Mon, 08 Dec 2003 15:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSKO-0004dX-Po; Mon, 08 Dec 2003 15:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSJo-0004cj-P5 for simple@optimus.ietf.org; Mon, 08 Dec 2003 15:49:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02031 for ; Mon, 8 Dec 2003 15:49:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSJn-0005FY-00 for simple@ietf.org; Mon, 08 Dec 2003 15:49:23 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ATSJm-0005FV-00 for simple@ietf.org; Mon, 08 Dec 2003 15:49:22 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB8KnFnG060620; Mon, 8 Dec 2003 14:49:21 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD4E3BF.2090100@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 14:49:03 -0600 Content-Transfer-Encoding: 7bit I had planned to use MSP, but it looks like that one got used a long time back by RFC1312. Robert mentioned to me offline that even a protocol with no intermediaries could be said to relay a message from an endpoint to its peer. From that perspective, maybe the easiest thing is sticking with MSRP. We could always say the R does not stand for anything now, but is reserved for future use ;-) hisham.khartabil@nokia.com wrote: > We need decide on the name of the protocol. So which one is it going to be? > > I vote for MSP, what's yours? > > Regards, > Hisham > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 8 15:50:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02067 for ; Mon, 8 Dec 2003 15:50:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSKT-0004eY-UJ for simple-archive@odin.ietf.org; Mon, 08 Dec 2003 15:50:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Ko5vh017880 for simple-archive@odin.ietf.org; Mon, 8 Dec 2003 15:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSKT-0004eJ-2e for simple-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 15:50:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02041; Mon, 8 Dec 2003 15:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSKR-0005Fn-00; Mon, 08 Dec 2003 15:50:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATSKQ-0005Fk-00; Mon, 08 Dec 2003 15:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSKO-0004dX-Po; Mon, 08 Dec 2003 15:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSJo-0004cj-P5 for simple@optimus.ietf.org; Mon, 08 Dec 2003 15:49:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02031 for ; Mon, 8 Dec 2003 15:49:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSJn-0005FY-00 for simple@ietf.org; Mon, 08 Dec 2003 15:49:23 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ATSJm-0005FV-00 for simple@ietf.org; Mon, 08 Dec 2003 15:49:22 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hB8KnFnG060620; Mon, 8 Dec 2003 14:49:21 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD4E3BF.2090100@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 14:49:03 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I had planned to use MSP, but it looks like that one got used a long time back by RFC1312. Robert mentioned to me offline that even a protocol with no intermediaries could be said to relay a message from an endpoint to its peer. From that perspective, maybe the easiest thing is sticking with MSRP. We could always say the R does not stand for anything now, but is reserved for future use ;-) hisham.khartabil@nokia.com wrote: > We need decide on the name of the protocol. So which one is it going to be? > > I vote for MSP, what's yours? > > Regards, > Hisham > > _______________________________________________ > 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-admin@ietf.org Mon Dec 8 16:10:54 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02962; Mon, 8 Dec 2003 16:10:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeq-0005dO-00; Mon, 08 Dec 2003 16:11:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATSep-0005dL-00; Mon, 08 Dec 2003 16:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSej-0005eT-58; Mon, 08 Dec 2003 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSeL-0005dx-MI for simple@optimus.ietf.org; Mon, 08 Dec 2003 16:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02946 for ; Mon, 8 Dec 2003 16:10:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeJ-0005d1-00 for simple@ietf.org; Mon, 08 Dec 2003 16:10:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeJ-0005cg-00 for simple@ietf.org; Mon, 08 Dec 2003 16:10:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2003 21:10:48 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB8LA2DM000557; Mon, 8 Dec 2003 16:10:02 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEM86439; Mon, 8 Dec 2003 16:10:01 -0500 (EST) Message-ID: <3FD4E8A9.9030409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> <3FD4E3BF.2090100@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 16:10:01 -0500 Content-Transfer-Encoding: 7bit I'm in favor of continuing with the name MSRP. There is however a slight risk that we will need to devise a new protocol for use specifically between relays. If so, we may be forced to call it MSRRP. :-) Paul Ben Campbell wrote: > I had planned to use MSP, but it looks like that one got used a long > time back by RFC1312. > > Robert mentioned to me offline that even a protocol with no > intermediaries could be said to relay a message from an endpoint to its > peer. From that perspective, maybe the easiest thing is sticking with MSRP. > > We could always say the R does not stand for anything now, but is > reserved for future use ;-) > > > > hisham.khartabil@nokia.com wrote: > >> We need decide on the name of the protocol. So which one is it going >> to be? >> >> I vote for MSP, what's yours? >> >> Regards, >> Hisham >> >> _______________________________________________ >> 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 exim@www1.ietf.org Mon Dec 8 16:11:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03000 for ; Mon, 8 Dec 2003 16:11:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSes-0005fT-Oh for simple-archive@odin.ietf.org; Mon, 08 Dec 2003 16:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8LBAIS021784 for simple-archive@odin.ietf.org; Mon, 8 Dec 2003 16:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSes-0005fH-H3 for simple-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 16:11:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02962; Mon, 8 Dec 2003 16:10:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeq-0005dO-00; Mon, 08 Dec 2003 16:11:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATSep-0005dL-00; Mon, 08 Dec 2003 16:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSej-0005eT-58; Mon, 08 Dec 2003 16:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATSeL-0005dx-MI for simple@optimus.ietf.org; Mon, 08 Dec 2003 16:10:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02946 for ; Mon, 8 Dec 2003 16:10:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeJ-0005d1-00 for simple@ietf.org; Mon, 08 Dec 2003 16:10:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ATSeJ-0005cg-00 for simple@ietf.org; Mon, 08 Dec 2003 16:10:35 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-5.cisco.com with ESMTP; 08 Dec 2003 21:10:48 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB8LA2DM000557; Mon, 8 Dec 2003 16:10:02 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEM86439; Mon, 8 Dec 2003 16:10:01 -0500 (EST) Message-ID: <3FD4E8A9.9030409@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> <3FD4E3BF.2090100@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 16:10:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'm in favor of continuing with the name MSRP. There is however a slight risk that we will need to devise a new protocol for use specifically between relays. If so, we may be forced to call it MSRRP. :-) Paul Ben Campbell wrote: > I had planned to use MSP, but it looks like that one got used a long > time back by RFC1312. > > Robert mentioned to me offline that even a protocol with no > intermediaries could be said to relay a message from an endpoint to its > peer. From that perspective, maybe the easiest thing is sticking with MSRP. > > We could always say the R does not stand for anything now, but is > reserved for future use ;-) > > > > hisham.khartabil@nokia.com wrote: > >> We need decide on the name of the protocol. So which one is it going >> to be? >> >> I vote for MSP, what's yours? >> >> Regards, >> Hisham >> >> _______________________________________________ >> 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-admin@ietf.org Mon Dec 8 17:52:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08990; Mon, 8 Dec 2003 17:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUEj-0000Wk-00; Mon, 08 Dec 2003 17:52:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATUEi-0000Wf-00; Mon, 08 Dec 2003 17:52:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEU-0001Ob-GI; Mon, 08 Dec 2003 17:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEL-0001NZ-Bn for simple@optimus.ietf.org; Mon, 08 Dec 2003 17:51:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08962 for ; Mon, 8 Dec 2003 17:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUEI-0000W6-00 for simple@ietf.org; Mon, 08 Dec 2003 17:51:50 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ATUEI-0000V5-00 for simple@ietf.org; Mon, 08 Dec 2003 17:51:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hB8MpJd26007; Mon, 8 Dec 2003 16:51:19 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@ietf.org Content-Type: text/plain Message-Id: <1070923876.11433.228.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] pdif MIME type Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 16:51:16 -0600 Content-Transfer-Encoding: 7bit A quick reminder to those working on SIMPLE implementations: draft-ietf-impp-cpim-pidf-08.txt authoritatively defines the media type for the PIDF presence document as application/pidf+xml This was a change from earlier versions of the document which used "application/cpim-pidf+xml". draft-ietf-simple-presence-10.txt still contains the older type. It will be corrected to reflect the new type name as it goes through the RFC editing process. If you have not already done so, please adjust your implementations to use "application/pidf+xml" now. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 8 17:52:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09074 for ; Mon, 8 Dec 2003 17:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEm-0001VE-Bu for simple-archive@odin.ietf.org; Mon, 08 Dec 2003 17:52:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8MqKIK005770 for simple-archive@odin.ietf.org; Mon, 8 Dec 2003 17:52:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEm-0001Uz-6w for simple-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 17:52:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08990; Mon, 8 Dec 2003 17:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUEj-0000Wk-00; Mon, 08 Dec 2003 17:52:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATUEi-0000Wf-00; Mon, 08 Dec 2003 17:52:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEU-0001Ob-GI; Mon, 08 Dec 2003 17:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATUEL-0001NZ-Bn for simple@optimus.ietf.org; Mon, 08 Dec 2003 17:51:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08962 for ; Mon, 8 Dec 2003 17:51:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATUEI-0000W6-00 for simple@ietf.org; Mon, 08 Dec 2003 17:51:50 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ATUEI-0000V5-00 for simple@ietf.org; Mon, 08 Dec 2003 17:51:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hB8MpJd26007; Mon, 8 Dec 2003 16:51:19 -0600 From: Robert Sparks To: simple@ietf.org, sip-implementors@ietf.org Content-Type: text/plain Message-Id: <1070923876.11433.228.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] pdif MIME type Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 08 Dec 2003 16:51:16 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A quick reminder to those working on SIMPLE implementations: draft-ietf-impp-cpim-pidf-08.txt authoritatively defines the media type for the PIDF presence document as application/pidf+xml This was a change from earlier versions of the document which used "application/cpim-pidf+xml". draft-ietf-simple-presence-10.txt still contains the older type. It will be corrected to reflect the new type name as it goes through the RFC editing process. If you have not already done so, please adjust your implementations to use "application/pidf+xml" now. Thanks, RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 9 00:22:53 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28181; Tue, 9 Dec 2003 00:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATaKy-0000ew-00; Tue, 09 Dec 2003 00:23:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATaKx-0000et-00; Tue, 09 Dec 2003 00:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaKr-0008PC-Mv; Tue, 09 Dec 2003 00:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaKg-0008Ov-9R for simple@optimus.ietf.org; Tue, 09 Dec 2003 00:22:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28166 for ; Tue, 9 Dec 2003 00:22:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATaKd-0000eZ-00 for simple@ietf.org; Tue, 09 Dec 2003 00:22:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ATaKd-0000eT-00 for simple@ietf.org; Tue, 09 Dec 2003 00:22:47 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB95MBca001882; Tue, 9 Dec 2003 00:22:12 -0500 (EST) Message-ID: <3FD55BF9.1030506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> <3FD4E3BF.2090100@dynamicsoft.com> <3FD4E8A9.9030409@cisco.com> In-Reply-To: <3FD4E8A9.9030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Dec 2003 00:22:01 -0500 Content-Transfer-Encoding: 7bit I also vote to continue with msrp. -Jonathan R. Paul Kyzivat wrote: > I'm in favor of continuing with the name MSRP. > > There is however a slight risk that we will need to devise a new > protocol for use specifically between relays. If so, we may be forced to > call it MSRRP. :-) > > Paul > > Ben Campbell wrote: > >> I had planned to use MSP, but it looks like that one got used a long >> time back by RFC1312. >> >> Robert mentioned to me offline that even a protocol with no >> intermediaries could be said to relay a message from an endpoint to >> its peer. From that perspective, maybe the easiest thing is sticking >> with MSRP. >> >> We could always say the R does not stand for anything now, but is >> reserved for future use ;-) >> >> >> >> hisham.khartabil@nokia.com wrote: >> >>> We need decide on the name of the protocol. So which one is it going >>> to be? >>> >>> I vote for MSP, what's yours? >>> >>> Regards, >>> Hisham >>> >>> _______________________________________________ >>> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 9 00:23:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28210 for ; Tue, 9 Dec 2003 00:23:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaL1-0008Q7-B3 for simple-archive@odin.ietf.org; Tue, 09 Dec 2003 00:23:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB95NBIR032363 for simple-archive@odin.ietf.org; Tue, 9 Dec 2003 00:23:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaL1-0008Pu-75 for simple-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 00:23:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28181; Tue, 9 Dec 2003 00:22:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATaKy-0000ew-00; Tue, 09 Dec 2003 00:23:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATaKx-0000et-00; Tue, 09 Dec 2003 00:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaKr-0008PC-Mv; Tue, 09 Dec 2003 00:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATaKg-0008Ov-9R for simple@optimus.ietf.org; Tue, 09 Dec 2003 00:22:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28166 for ; Tue, 9 Dec 2003 00:22:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATaKd-0000eZ-00 for simple@ietf.org; Tue, 09 Dec 2003 00:22:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1ATaKd-0000eT-00 for simple@ietf.org; Tue, 09 Dec 2003 00:22:47 -0500 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hB95MBca001882; Tue, 9 Dec 2003 00:22:12 -0500 (EST) Message-ID: <3FD55BF9.1030506@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Ben Campbell , hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP or MSP References: <2038BCC78B1AD641891A0D1AE133DBB7017974A7@esebe019.ntc.nokia.com> <3FD4E3BF.2090100@dynamicsoft.com> <3FD4E8A9.9030409@cisco.com> In-Reply-To: <3FD4E8A9.9030409@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Dec 2003 00:22:01 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I also vote to continue with msrp. -Jonathan R. Paul Kyzivat wrote: > I'm in favor of continuing with the name MSRP. > > There is however a slight risk that we will need to devise a new > protocol for use specifically between relays. If so, we may be forced to > call it MSRRP. :-) > > Paul > > Ben Campbell wrote: > >> I had planned to use MSP, but it looks like that one got used a long >> time back by RFC1312. >> >> Robert mentioned to me offline that even a protocol with no >> intermediaries could be said to relay a message from an endpoint to >> its peer. From that perspective, maybe the easiest thing is sticking >> with MSRP. >> >> We could always say the R does not stand for anything now, but is >> reserved for future use ;-) >> >> >> >> hisham.khartabil@nokia.com wrote: >> >>> We need decide on the name of the protocol. So which one is it going >>> to be? >>> >>> I vote for MSP, what's yours? >>> >>> Regards, >>> Hisham >>> >>> _______________________________________________ >>> 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 9 16:57:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19165; Tue, 9 Dec 2003 16:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATprp-0001gq-00; Tue, 09 Dec 2003 16:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATprp-0001gj-00; Tue, 09 Dec 2003 16:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprl-0003lX-DZ; Tue, 09 Dec 2003 16:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprV-0003kJ-7k for simple@optimus.ietf.org; Tue, 09 Dec 2003 16:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19148 for ; Tue, 9 Dec 2003 16:57:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATprT-0001gA-00 for simple@ietf.org; Tue, 09 Dec 2003 16:57:43 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ATprS-0001g6-00 for simple@ietf.org; Tue, 09 Dec 2003 16:57:42 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB9LvcSs001070; Tue, 9 Dec 2003 22:57:38 +0100 (MET) Received: from ericsson.com (sealwp02-137.sw.ericsson.se [153.88.142.137]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW9B7GPW; Tue, 9 Dec 2003 22:58:23 +0100 Message-ID: <3FD64551.3050903@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> <3FD46728.9070401@ericsson.com> <3FD4D848.7060700@dynamicsoft.com> In-Reply-To: <3FD4D848.7060700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Dec 2003 23:57:37 +0200 Content-Transfer-Encoding: 7bit Ben: Thanks for your answers, they are crystal clear, and I think I got the idea. Just a couple of minor comments. Is the default timer (30 seconds) a realistic one. I mean, if the idea is to improve the session setup time, I believe 30 seconds is beyond the user expectations. It should be something shorter, IMHO. But anyway, the offerer can always indicate another shorter timer. Second, you may improve the readability of the text by indicating that the timer affects to the *TCP establishment* as opposed to the VISIT/200 ok timer, or the time the offerer waits for a VISIT. And also highlight that (yes, a bit more) that only the offerer is able to set the value "both". May I suggest something on a similar wording to: both: The *offerer* is willing to act as either host or visitor. If the *offerer selects* "both", it may *add an* optional timeout value. This timeout specifies how much time the answerer should wait, *when establishing the TCP connection*, before giving up *it* on and attempting to take over as host device. If the timeout value is not specified, it defaults to 30 seconds. Thanks, Miguel Ben Campbell wrote: > Sorry, I somehow missed the original note in my usual deluge of mail. > > Comments inline to both emails inline: > > Miguel A. Garcia wrote: > >> Ben: >> >> I think there is something unclear with the management of the timeout >> value that we can find in the direction attribute when the direction >> is set to "both", as David is suggesting below. >> >> According to the spec, I got the impression that the timer is only >> applicable to the ***answerer***, i.e., that the offerer cannot use it. >> > > It depends on what you man by use it. Only the offerer can create an SDP > document with direction=both, so only the offerer can select this value. > But it only useful in the situation where an endpoint attempts to act as > a visitor (i.e. active), is unable to connect, and then attempts to act > as host (i.e. passive). > >> both: The endpoint is willing to act as either host or visitor. If >> "both" is selected, it may contain an optional timeout value. This >> timeout specifies how much time the answerer should wait before >> giving up on a connection and attempting to take over as host >> device. If the timeout value is not specified, it defaults to 30 >> seconds. >> >> However, later in the spec, I found out that the answerer cannot use >> "both" at all: >> >> The SDP answer also MUST contain a direction attribute, but its value >> choices are limited based on the value in the offer.... >> >> If the offer contained "both", the answerer SHOULD select "active", >> but MAY select"passive" if it is unable to reach the host device, >> or if local policy requires it to act as host. > > > That is correct--the answerer will never insert direction=both in the > SDP answer. We allow the offerer to tell the answerer "You decide." But > we do not allow the answerer to come back and say, "No, you decide." > (Believe me, watching my wife and I try to select a restaurant would > offer an example of why this is not a good idea :-) ) > >> >> And then later, when the spec indicates how the offerer builds the offer: >> >> 4. Insert a direction attribute. This value SHOULD be "both", >> indicating that the offerer will allow the answerer to override >> the offerer's decision to host. If "both" is selected, the >> offerer SHOULD leave the timeout at the default value (by leaving >> out the value entirely. However, the offerer MAY select a >> different timeout if circumstances warrant it. The direction >> value MAY be "passive" if the offerer is prevented from allowing >> the answerer override this choice. >> >> So the questions to solve are: >> >> 1) What is the purpose of this timer? An scenario where it is used >> will help to understand it. > > > The general idea was to improve session setup time when an answerer is > unable to connect to the host device. Assume A is the offerer and B is > the answerer. B attempts a TCP connection to A, which fails. B then > sends an SDP response instructing A to connect to B instead. Since it > can take some time for a TCP connectin attempt to fail, and since if it > takes a real long time to connect, it is likely that network conditions > are not particularly good along that path, we specify a shorter time > limit after which B should give up. We give A the ability to modify that > limit from the default if A knows something about the network conditions > that make the default inappropriate. > >> >> 2) Is it possible to use it in offers or answers or both? >> > > What do you mean by "use"? It is only specified by the offerer, but it > is only acted upon by the answerer. > >> 3) How does the offerer use this timer? In most circumstances the >> answers will reply with an "active" direction, so what are the actions >> at the offerer? > > > If the answer contains "active", the offerer does nothing with this > timer value. Keep in mind, B does not return a response until _after_ it > successfully visits the host, or fails to do so. If it succeeded in > visiting, it returns active. If it fails, and wants to let A attempt to > connect to it, it returns passive. > >> >> Any light to solve these questions is appreciated. >> >> Regards, >> >> Miguel >> >> David Partain (LI/EAB) wrote: >> >>> Greetings, >>> >>> I don't understand the timer associated with the both direction >>> attribute (page 11 in the -02 version). I'd be really grateful >>> if someone could explain to me how it works. >>> >>> The text says that this timer specifies how long the "answerer" >>> should wait before giving up on the connection and trying to >>> take over has host for the session. >>> >>> If I send an INVITE with "both" and set the timer to 45 seconds, >>> I've also supplied an MSRP URL that the answerer can use to >>> VISIT me. Does the timer start when the answerer sends the >>> VISIT to the offerer at the MSRP URL? It doesn't make much >>> sense to me that the offerer should tell the answerer to wait >>> after sending the VISIT, but I'm probably missing something. > > > The timer starts when the answerer attempts to open a TCP connection to > the host device. If the connection attempt has not completed in 45 > seconds, it may abandon the connection and assume a passive role by > returning a response with direction=passive. > >>> >>> And if the answerer doesn't get an OK for the VISIT within >>> the alloted 45 seconds, what then? How is it expected to take >>> over as host? > > > The timer does not apply to the VISIT transaction. It only applies to > the attempt to open the TCP connection. > >>> >>> Is "answerer" above really supposed to be "offerer"? I don't >>> see how that works either, though, since the offerer has no >>> URL to VISIT. > > > No, the offerer never acts upon this timer value. It may select a value > for the answerer to use. > > >>> >>> I'm just generally confused and don't understand the timer. >>> Would some kind soul please enlighten me? >>> >>> Thanks much. >>> >>> David >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 9 16:58:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19194 for ; Tue, 9 Dec 2003 16:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprs-0003pn-DN for simple-archive@odin.ietf.org; Tue, 09 Dec 2003 16:58:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9Lw8Pf014735 for simple-archive@odin.ietf.org; Tue, 9 Dec 2003 16:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprs-0003pa-6C for simple-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 16:58:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19165; Tue, 9 Dec 2003 16:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATprp-0001gq-00; Tue, 09 Dec 2003 16:58:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATprp-0001gj-00; Tue, 09 Dec 2003 16:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprl-0003lX-DZ; Tue, 09 Dec 2003 16:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATprV-0003kJ-7k for simple@optimus.ietf.org; Tue, 09 Dec 2003 16:57:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19148 for ; Tue, 9 Dec 2003 16:57:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATprT-0001gA-00 for simple@ietf.org; Tue, 09 Dec 2003 16:57:43 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1ATprS-0001g6-00 for simple@ietf.org; Tue, 09 Dec 2003 16:57:42 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB9LvcSs001070; Tue, 9 Dec 2003 22:57:38 +0100 (MET) Received: from ericsson.com (sealwp02-137.sw.ericsson.se [153.88.142.137]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW9B7GPW; Tue, 9 Dec 2003 22:58:23 +0100 Message-ID: <3FD64551.3050903@ericsson.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es MIME-Version: 1.0 To: Ben Campbell CC: David.Partain@ericsson.com, Simple WG Subject: Re: [Simple] The "both" timer References: <200312021749.42661.david.partain@ericsson.com> <3FD46728.9070401@ericsson.com> <3FD4D848.7060700@dynamicsoft.com> In-Reply-To: <3FD4D848.7060700@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 09 Dec 2003 23:57:37 +0200 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben: Thanks for your answers, they are crystal clear, and I think I got the idea. Just a couple of minor comments. Is the default timer (30 seconds) a realistic one. I mean, if the idea is to improve the session setup time, I believe 30 seconds is beyond the user expectations. It should be something shorter, IMHO. But anyway, the offerer can always indicate another shorter timer. Second, you may improve the readability of the text by indicating that the timer affects to the *TCP establishment* as opposed to the VISIT/200 ok timer, or the time the offerer waits for a VISIT. And also highlight that (yes, a bit more) that only the offerer is able to set the value "both". May I suggest something on a similar wording to: both: The *offerer* is willing to act as either host or visitor. If the *offerer selects* "both", it may *add an* optional timeout value. This timeout specifies how much time the answerer should wait, *when establishing the TCP connection*, before giving up *it* on and attempting to take over as host device. If the timeout value is not specified, it defaults to 30 seconds. Thanks, Miguel Ben Campbell wrote: > Sorry, I somehow missed the original note in my usual deluge of mail. > > Comments inline to both emails inline: > > Miguel A. Garcia wrote: > >> Ben: >> >> I think there is something unclear with the management of the timeout >> value that we can find in the direction attribute when the direction >> is set to "both", as David is suggesting below. >> >> According to the spec, I got the impression that the timer is only >> applicable to the ***answerer***, i.e., that the offerer cannot use it. >> > > It depends on what you man by use it. Only the offerer can create an SDP > document with direction=both, so only the offerer can select this value. > But it only useful in the situation where an endpoint attempts to act as > a visitor (i.e. active), is unable to connect, and then attempts to act > as host (i.e. passive). > >> both: The endpoint is willing to act as either host or visitor. If >> "both" is selected, it may contain an optional timeout value. This >> timeout specifies how much time the answerer should wait before >> giving up on a connection and attempting to take over as host >> device. If the timeout value is not specified, it defaults to 30 >> seconds. >> >> However, later in the spec, I found out that the answerer cannot use >> "both" at all: >> >> The SDP answer also MUST contain a direction attribute, but its value >> choices are limited based on the value in the offer.... >> >> If the offer contained "both", the answerer SHOULD select "active", >> but MAY select"passive" if it is unable to reach the host device, >> or if local policy requires it to act as host. > > > That is correct--the answerer will never insert direction=both in the > SDP answer. We allow the offerer to tell the answerer "You decide." But > we do not allow the answerer to come back and say, "No, you decide." > (Believe me, watching my wife and I try to select a restaurant would > offer an example of why this is not a good idea :-) ) > >> >> And then later, when the spec indicates how the offerer builds the offer: >> >> 4. Insert a direction attribute. This value SHOULD be "both", >> indicating that the offerer will allow the answerer to override >> the offerer's decision to host. If "both" is selected, the >> offerer SHOULD leave the timeout at the default value (by leaving >> out the value entirely. However, the offerer MAY select a >> different timeout if circumstances warrant it. The direction >> value MAY be "passive" if the offerer is prevented from allowing >> the answerer override this choice. >> >> So the questions to solve are: >> >> 1) What is the purpose of this timer? An scenario where it is used >> will help to understand it. > > > The general idea was to improve session setup time when an answerer is > unable to connect to the host device. Assume A is the offerer and B is > the answerer. B attempts a TCP connection to A, which fails. B then > sends an SDP response instructing A to connect to B instead. Since it > can take some time for a TCP connectin attempt to fail, and since if it > takes a real long time to connect, it is likely that network conditions > are not particularly good along that path, we specify a shorter time > limit after which B should give up. We give A the ability to modify that > limit from the default if A knows something about the network conditions > that make the default inappropriate. > >> >> 2) Is it possible to use it in offers or answers or both? >> > > What do you mean by "use"? It is only specified by the offerer, but it > is only acted upon by the answerer. > >> 3) How does the offerer use this timer? In most circumstances the >> answers will reply with an "active" direction, so what are the actions >> at the offerer? > > > If the answer contains "active", the offerer does nothing with this > timer value. Keep in mind, B does not return a response until _after_ it > successfully visits the host, or fails to do so. If it succeeded in > visiting, it returns active. If it fails, and wants to let A attempt to > connect to it, it returns passive. > >> >> Any light to solve these questions is appreciated. >> >> Regards, >> >> Miguel >> >> David Partain (LI/EAB) wrote: >> >>> Greetings, >>> >>> I don't understand the timer associated with the both direction >>> attribute (page 11 in the -02 version). I'd be really grateful >>> if someone could explain to me how it works. >>> >>> The text says that this timer specifies how long the "answerer" >>> should wait before giving up on the connection and trying to >>> take over has host for the session. >>> >>> If I send an INVITE with "both" and set the timer to 45 seconds, >>> I've also supplied an MSRP URL that the answerer can use to >>> VISIT me. Does the timer start when the answerer sends the >>> VISIT to the offerer at the MSRP URL? It doesn't make much >>> sense to me that the offerer should tell the answerer to wait >>> after sending the VISIT, but I'm probably missing something. > > > The timer starts when the answerer attempts to open a TCP connection to > the host device. If the connection attempt has not completed in 45 > seconds, it may abandon the connection and assume a passive role by > returning a response with direction=passive. > >>> >>> And if the answerer doesn't get an OK for the VISIT within >>> the alloted 45 seconds, what then? How is it expected to take >>> over as host? > > > The timer does not apply to the VISIT transaction. It only applies to > the attempt to open the TCP connection. > >>> >>> Is "answerer" above really supposed to be "offerer"? I don't >>> see how that works either, though, since the offerer has no >>> URL to VISIT. > > > No, the offerer never acts upon this timer value. It may select a value > for the answerer to use. > > >>> >>> I'm just generally confused and don't understand the timer. >>> Would some kind soul please enlighten me? >>> >>> Thanks much. >>> >>> David >>> >>> >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >>> >> > -- Miguel-Angel Garcia Oy LM Ericsson AB Jorvas, Finland mailto:Miguel.A.Garcia@ericsson.com Phone: +358 9 299 3553 mailto:Miguel.A.Garcia@piuha.net Mobile: +358 40 514 0002 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 10 07:37:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09944; Wed, 10 Dec 2003 07:37:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU3aV-0000tr-00; Wed, 10 Dec 2003 07:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU3aV-0000to-00; Wed, 10 Dec 2003 07:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3aP-0000Fk-N7; Wed, 10 Dec 2003 07:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3ZZ-0000Ep-OO for simple@optimus.ietf.org; Wed, 10 Dec 2003 07:36:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09933 for ; Wed, 10 Dec 2003 07:36:08 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU3ZY-0000tN-00 for simple@ietf.org; Wed, 10 Dec 2003 07:36:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU3ZY-0000tK-00 for simple@ietf.org; Wed, 10 Dec 2003 07:36:08 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBACa6Q10151 for ; Wed, 10 Dec 2003 14:36:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 14:36:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 14:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO1z9qEP+1CL13GTzaRP1NQra+prgAAGmWgAlJnt0A= To: , , Cc: X-OriginalArrivalTime: 10 Dec 2003 12:36:05.0494 (UTC) FILETIME=[2DCC8960:01C3BF1A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Dec 2003 14:36:05 +0200 Content-Transfer-Encoding: quoted-printable What was the outcome of this discussion? Are we supporting message = retransmission? Regards, Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 28.November.2003 18:56 > To: Ben Campbell; Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >Sent: 10 November 2003 17:09 > >To: Paul Kyzivat > >Cc: hisham.khartabil@nokia.com; simple@ietf.org > >Subject: Re: [Simple] Comments on message-sessions-02 - message retry > > > >Paul Kyzivat wrote: > > > >[...] > > > >> > >> I'm not certain a time period is really necessary. I think this can > be > >> local option. > >> > >> Even uniqueness across streams isn't *required*, though it would be > >> helpful. Instead, we can simply introduce an error response to be > used > >> when a duplicate is detected and supressed. If it was supressed in > error > >> because the sender duplicated a TR-ID from another stream,=20 > the sender > >> would then know to recover. > >> > >> But I agree that some further clarification on TR-ID=20 > uniqueness could > be > >> helpful. > >> > > > >If TR-ID is not required to be unique across sessions, and you allow > >clients to attempt to find duplicate messages using TR-ID across > >sessions, then you introduce the possibility of false=20 > detection caused > >by TR-ID collisions. This seems bad to me. > > > [Chris Boulton] I totally agree. >=20 > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > >_____________________________________________________________ > __________ > _ > >This email has been scanned for all viruses by the MessageLabs Email > >Security System. For more information on a proactive email security > >service working around the clock, around the globe, visit > >http://www.messagelabs.com > >_____________________________________________________________ > __________ > _ >=20 > ______________________________________________________________ > __________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ______________________________________________________________ > __________ >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 10 07:37:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09964 for ; Wed, 10 Dec 2003 07:37:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3aX-0000HU-Au for simple-archive@odin.ietf.org; Wed, 10 Dec 2003 07:37:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBACb98I001076 for simple-archive@odin.ietf.org; Wed, 10 Dec 2003 07:37:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3aW-0000HH-Ry for simple-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 07:37:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09944; Wed, 10 Dec 2003 07:37:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU3aV-0000tr-00; Wed, 10 Dec 2003 07:37:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU3aV-0000to-00; Wed, 10 Dec 2003 07:37:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3aP-0000Fk-N7; Wed, 10 Dec 2003 07:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU3ZZ-0000Ep-OO for simple@optimus.ietf.org; Wed, 10 Dec 2003 07:36:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09933 for ; Wed, 10 Dec 2003 07:36:08 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU3ZY-0000tN-00 for simple@ietf.org; Wed, 10 Dec 2003 07:36:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU3ZY-0000tK-00 for simple@ietf.org; Wed, 10 Dec 2003 07:36:08 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBACa6Q10151 for ; Wed, 10 Dec 2003 14:36:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 14:36:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 14:36:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcO1z9qEP+1CL13GTzaRP1NQra+prgAAGmWgAlJnt0A= To: , , Cc: X-OriginalArrivalTime: 10 Dec 2003 12:36:05.0494 (UTC) FILETIME=[2DCC8960:01C3BF1A] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 10 Dec 2003 14:36:05 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable What was the outcome of this discussion? Are we supporting message = retransmission? Regards, Hisham > -----Original Message----- > From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 28.November.2003 18:56 > To: Ben Campbell; Paul Kyzivat > Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >Sent: 10 November 2003 17:09 > >To: Paul Kyzivat > >Cc: hisham.khartabil@nokia.com; simple@ietf.org > >Subject: Re: [Simple] Comments on message-sessions-02 - message retry > > > >Paul Kyzivat wrote: > > > >[...] > > > >> > >> I'm not certain a time period is really necessary. I think this can > be > >> local option. > >> > >> Even uniqueness across streams isn't *required*, though it would be > >> helpful. Instead, we can simply introduce an error response to be > used > >> when a duplicate is detected and supressed. If it was supressed in > error > >> because the sender duplicated a TR-ID from another stream,=20 > the sender > >> would then know to recover. > >> > >> But I agree that some further clarification on TR-ID=20 > uniqueness could > be > >> helpful. > >> > > > >If TR-ID is not required to be unique across sessions, and you allow > >clients to attempt to find duplicate messages using TR-ID across > >sessions, then you introduce the possibility of false=20 > detection caused > >by TR-ID collisions. This seems bad to me. > > > [Chris Boulton] I totally agree. >=20 > > > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple > > > >_____________________________________________________________ > __________ > _ > >This email has been scanned for all viruses by the MessageLabs Email > >Security System. For more information on a proactive email security > >service working around the clock, around the globe, visit > >http://www.messagelabs.com > >_____________________________________________________________ > __________ > _ >=20 > ______________________________________________________________ > __________ > This email has been scanned for all viruses by the MessageLabs Email > Security System. For more information on a proactive email security > service working around the clock, around the globe, visit > http://www.messagelabs.com > ______________________________________________________________ > __________ >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 11 04:43:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23534; Thu, 11 Dec 2003 04:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNLf-0006kh-00; Thu, 11 Dec 2003 04:43:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUNLe-0006kb-00; Thu, 11 Dec 2003 04:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNLc-0003z0-AC; Thu, 11 Dec 2003 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNL0-0003yT-PN for simple@optimus.ietf.org; Thu, 11 Dec 2003 04:42:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23518 for ; Thu, 11 Dec 2003 04:42:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNKw-0006kL-00 for simple@ietf.org; Thu, 11 Dec 2003 04:42:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUNKv-0006kH-00 for simple@ietf.org; Thu, 11 Dec 2003 04:42:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBB9gMQ07802 for ; Thu, 11 Dec 2003 11:42:22 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Dec 2003 11:42:22 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:42:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> Thread-Topic: XCAP: what does in the 200 of a PUT request Thread-Index: AcO/yxCzEKSYPBQ7TziSfOzAtC82SQ== To: X-OriginalArrivalTime: 11 Dec 2003 09:42:21.0252 (UTC) FILETIME=[12E13040:01C3BFCB] Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP: what does in the 200 of a PUT request Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:42:18 +0200 Content-Transfer-Encoding: quoted-printable This is not clear in XCAP. I also check RFC2616 to find out some sort of = answer, but it is not clear there either. Should the 200 (or 201 for that matter) contain the contents the were = PUT? If so, does it include the resource interdependencies (like the = resource list URI in the list case)? If no, does that mean the client needs to follow the PUT with a GET to = learn of the resource interdependencies? Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 11 04:43:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23557 for ; Thu, 11 Dec 2003 04:43:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNLm-0003zu-FJ for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 04:43:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB9hExF015360 for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 04:43:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNLj-0003ze-4d for simple-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04:43:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23534; Thu, 11 Dec 2003 04:43:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNLf-0006kh-00; Thu, 11 Dec 2003 04:43:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUNLe-0006kb-00; Thu, 11 Dec 2003 04:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNLc-0003z0-AC; Thu, 11 Dec 2003 04:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNL0-0003yT-PN for simple@optimus.ietf.org; Thu, 11 Dec 2003 04:42:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23518 for ; Thu, 11 Dec 2003 04:42:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNKw-0006kL-00 for simple@ietf.org; Thu, 11 Dec 2003 04:42:22 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUNKv-0006kH-00 for simple@ietf.org; Thu, 11 Dec 2003 04:42:21 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBB9gMQ07802 for ; Thu, 11 Dec 2003 11:42:22 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Dec 2003 11:42:22 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:42:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> Thread-Topic: XCAP: what does in the 200 of a PUT request Thread-Index: AcO/yxCzEKSYPBQ7TziSfOzAtC82SQ== To: X-OriginalArrivalTime: 11 Dec 2003 09:42:21.0252 (UTC) FILETIME=[12E13040:01C3BFCB] Content-Transfer-Encoding: quoted-printable Subject: [Simple] XCAP: what does in the 200 of a PUT request Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:42:18 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This is not clear in XCAP. I also check RFC2616 to find out some sort of = answer, but it is not clear there either. Should the 200 (or 201 for that matter) contain the contents the were = PUT? If so, does it include the resource interdependencies (like the = resource list URI in the list case)? If no, does that mean the client needs to follow the PUT with a GET to = learn of the resource interdependencies? Thanks, Hisham _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 11 04:58:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23766; Thu, 11 Dec 2003 04:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNa7-0006xN-00; Thu, 11 Dec 2003 04:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUNa7-0006xK-00; Thu, 11 Dec 2003 04:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNa5-0004M8-NT; Thu, 11 Dec 2003 04:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNZg-0004Lm-SE for simple@optimus.ietf.org; Thu, 11 Dec 2003 04:57:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23755 for ; Thu, 11 Dec 2003 04:57:33 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNZc-0006x3-00 for simple@ietf.org; Thu, 11 Dec 2003 04:57:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUNZb-0006x0-00 for simple@ietf.org; Thu, 11 Dec 2003 04:57:31 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBB9vWQ29151 for ; Thu, 11 Dec 2003 11:57:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Dec 2003 11:57:32 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:57:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:57:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> Thread-Topic: XCAP: what does in the 200 of a PUT request Thread-Index: AcO/yxCzEKSYPBQ7TziSfOzAtC82SQAAafsA To: , X-OriginalArrivalTime: 11 Dec 2003 09:57:32.0400 (UTC) FILETIME=[31F75700:01C3BFCD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:56:38 +0200 Content-Transfer-Encoding: quoted-printable of course the question was: What goes in the body of a 200 response of a = PUT request?=20 Apologies for the lack of clarity in the first post. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 11.December.2003 11:42 > To: simple@ietf.org > Subject: [Simple] XCAP: what does in the 200 of a PUT request >=20 >=20 > This is not clear in XCAP. I also check RFC2616 to find out=20 > some sort of answer, but it is not clear there either. >=20 > Should the 200 (or 201 for that matter) contain the contents=20 > the were PUT? If so, does it include the resource=20 > interdependencies (like the resource list URI in the list case)? >=20 > If no, does that mean the client needs to follow the PUT with=20 > a GET to learn of the resource interdependencies? >=20 > Thanks, > Hisham >=20 > _______________________________________________ > 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 exim@www1.ietf.org Thu Dec 11 04:58:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23787 for ; Thu, 11 Dec 2003 04:58:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNaD-0004QD-Ri for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 04:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBB9w9ON016996 for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 04:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNaB-0004Ml-Rw for simple-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 04:58:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23766; Thu, 11 Dec 2003 04:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNa7-0006xN-00; Thu, 11 Dec 2003 04:58:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUNa7-0006xK-00; Thu, 11 Dec 2003 04:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNa5-0004M8-NT; Thu, 11 Dec 2003 04:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUNZg-0004Lm-SE for simple@optimus.ietf.org; Thu, 11 Dec 2003 04:57:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23755 for ; Thu, 11 Dec 2003 04:57:33 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUNZc-0006x3-00 for simple@ietf.org; Thu, 11 Dec 2003 04:57:32 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUNZb-0006x0-00 for simple@ietf.org; Thu, 11 Dec 2003 04:57:31 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBB9vWQ29151 for ; Thu, 11 Dec 2003 11:57:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Dec 2003 11:57:32 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:57:32 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 11:57:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> Thread-Topic: XCAP: what does in the 200 of a PUT request Thread-Index: AcO/yxCzEKSYPBQ7TziSfOzAtC82SQAAafsA To: , X-OriginalArrivalTime: 11 Dec 2003 09:57:32.0400 (UTC) FILETIME=[31F75700:01C3BFCD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:56:38 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable of course the question was: What goes in the body of a 200 response of a = PUT request?=20 Apologies for the lack of clarity in the first post. /Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext hisham.khartabil@nokia.com > Sent: 11.December.2003 11:42 > To: simple@ietf.org > Subject: [Simple] XCAP: what does in the 200 of a PUT request >=20 >=20 > This is not clear in XCAP. I also check RFC2616 to find out=20 > some sort of answer, but it is not clear there either. >=20 > Should the 200 (or 201 for that matter) contain the contents=20 > the were PUT? If so, does it include the resource=20 > interdependencies (like the resource list URI in the list case)? >=20 > If no, does that mean the client needs to follow the PUT with=20 > a GET to learn of the resource interdependencies? >=20 > Thanks, > Hisham >=20 > _______________________________________________ > 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-admin@ietf.org Thu Dec 11 12:06:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09977; Thu, 11 Dec 2003 12:06:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUGQ-0000rl-00; Thu, 11 Dec 2003 12:06:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUUGP-0000rd-00; Thu, 11 Dec 2003 12:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUGH-0005hD-T4; Thu, 11 Dec 2003 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUFl-0005gH-8Q for simple@optimus.ietf.org; Thu, 11 Dec 2003 12:05:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09940 for ; Thu, 11 Dec 2003 12:05:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUFj-0000qi-00 for simple@ietf.org; Thu, 11 Dec 2003 12:05:28 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AUUFj-0000qf-00 for simple@ietf.org; Thu, 11 Dec 2003 12:05:27 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBBH59nG085906; Thu, 11 Dec 2003 11:05:10 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD8A3C3.6060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, pkyzivat@cisco.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:05:07 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > What was the outcome of this discussion? Are we supporting message retransmission? I think we are agreed to not attempt retransmission on the same connection. We are also agreed that, when a connection fails, we must re-signal to create a new one. I think we still need discussion on how to associate a new connection with the old, when both are associated with the same dialog, and how to deal with retrying any messages that may have failed on the old connection on an associated new connection. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>Sent: 28.November.2003 18:56 >>To: Ben Campbell; Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 - message retry >> >> >> >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 10 November 2003 17:09 >>>To: Paul Kyzivat >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>> >>>Paul Kyzivat wrote: >>> >>>[...] >>> >>> >>>>I'm not certain a time period is really necessary. I think this can >> >>be >> >>>>local option. >>>> >>>>Even uniqueness across streams isn't *required*, though it would be >>>>helpful. Instead, we can simply introduce an error response to be >> >>used >> >>>>when a duplicate is detected and supressed. If it was supressed in >> >>error >> >>>>because the sender duplicated a TR-ID from another stream, >> >>the sender >> >>>>would then know to recover. >>>> >>>>But I agree that some further clarification on TR-ID >> >>uniqueness could >>be >> >>>>helpful. >>>> >>> >>>If TR-ID is not required to be unique across sessions, and you allow >>>clients to attempt to find duplicate messages using TR-ID across >>>sessions, then you introduce the possibility of false >> >>detection caused >> >>>by TR-ID collisions. This seems bad to me. >>> >> >>[Chris Boulton] I totally agree. >> >> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >>>_____________________________________________________________ >> >>__________ >>_ >> >>>This email has been scanned for all viruses by the MessageLabs Email >>>Security System. For more information on a proactive email security >>>service working around the clock, around the globe, visit >>>http://www.messagelabs.com >>>_____________________________________________________________ >> >>__________ >>_ >> >>______________________________________________________________ >>__________ >>This email has been scanned for all viruses by the MessageLabs Email >>Security System. For more information on a proactive email security >>service working around the clock, around the globe, visit >>http://www.messagelabs.com >>______________________________________________________________ >>__________ >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 11 12:06:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10001 for ; Thu, 11 Dec 2003 12:06:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUGS-0005ia-2U for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 12:06:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBH6CSs021979 for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 12:06:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUGR-0005iQ-Vd for simple-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 12:06:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09977; Thu, 11 Dec 2003 12:06:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUGQ-0000rl-00; Thu, 11 Dec 2003 12:06:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUUGP-0000rd-00; Thu, 11 Dec 2003 12:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUGH-0005hD-T4; Thu, 11 Dec 2003 12:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUUFl-0005gH-8Q for simple@optimus.ietf.org; Thu, 11 Dec 2003 12:05:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09940 for ; Thu, 11 Dec 2003 12:05:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUUFj-0000qi-00 for simple@ietf.org; Thu, 11 Dec 2003 12:05:28 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AUUFj-0000qf-00 for simple@ietf.org; Thu, 11 Dec 2003 12:05:27 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBBH59nG085906; Thu, 11 Dec 2003 11:05:10 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD8A3C3.6060508@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, pkyzivat@cisco.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974D6@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 11:05:07 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > What was the outcome of this discussion? Are we supporting message retransmission? I think we are agreed to not attempt retransmission on the same connection. We are also agreed that, when a connection fails, we must re-signal to create a new one. I think we still need discussion on how to associate a new connection with the old, when both are associated with the same dialog, and how to deal with retrying any messages that may have failed on the old connection on an associated new connection. > > Regards, > Hisham > > >>-----Original Message----- >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>Sent: 28.November.2003 18:56 >>To: Ben Campbell; Paul Kyzivat >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 - message retry >> >> >> >> >> >>>-----Original Message----- >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 10 November 2003 17:09 >>>To: Paul Kyzivat >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >>> >>>Paul Kyzivat wrote: >>> >>>[...] >>> >>> >>>>I'm not certain a time period is really necessary. I think this can >> >>be >> >>>>local option. >>>> >>>>Even uniqueness across streams isn't *required*, though it would be >>>>helpful. Instead, we can simply introduce an error response to be >> >>used >> >>>>when a duplicate is detected and supressed. If it was supressed in >> >>error >> >>>>because the sender duplicated a TR-ID from another stream, >> >>the sender >> >>>>would then know to recover. >>>> >>>>But I agree that some further clarification on TR-ID >> >>uniqueness could >>be >> >>>>helpful. >>>> >>> >>>If TR-ID is not required to be unique across sessions, and you allow >>>clients to attempt to find duplicate messages using TR-ID across >>>sessions, then you introduce the possibility of false >> >>detection caused >> >>>by TR-ID collisions. This seems bad to me. >>> >> >>[Chris Boulton] I totally agree. >> >> >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org >>>https://www1.ietf.org/mailman/listinfo/simple >>> >>>_____________________________________________________________ >> >>__________ >>_ >> >>>This email has been scanned for all viruses by the MessageLabs Email >>>Security System. For more information on a proactive email security >>>service working around the clock, around the globe, visit >>>http://www.messagelabs.com >>>_____________________________________________________________ >> >>__________ >>_ >> >>______________________________________________________________ >>__________ >>This email has been scanned for all viruses by the MessageLabs Email >>Security System. For more information on a proactive email security >>service working around the clock, around the globe, visit >>http://www.messagelabs.com >>______________________________________________________________ >>__________ >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 11 13:50:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13875; Thu, 11 Dec 2003 13:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsy-0003uD-00; Thu, 11 Dec 2003 13:50:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUVsx-0003uA-00; Thu, 11 Dec 2003 13:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVsw-0002or-Sd; Thu, 11 Dec 2003 13:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVse-0002o7-LZ for simple@optimus.ietf.org; Thu, 11 Dec 2003 13:49:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13842 for ; Thu, 11 Dec 2003 13:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsc-0003so-00 for simple@ietf.org; Thu, 11 Dec 2003 13:49:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsb-0003sj-00 for simple@ietf.org; Thu, 11 Dec 2003 13:49:41 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBBInb4t016944; Thu, 11 Dec 2003 10:49:38 -0800 (PST) Received: from [205.214.163.16] (vpn-10-50-0-7.qualcomm.com [10.50.0.7]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBBInWhk021605; Thu, 11 Dec 2003 10:49:34 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> To: hisham.khartabil@nokia.com, From: Ted Hardie Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 10:49:31 -0800 At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: >This is not clear in XCAP. I also check RFC2616 to find out some sort of answer, but it is not clear there either. The 200 response doesn't require a response body for HTTP. You can define a response body appropriate for a specific method (Julian Reschke has a webdav-related example in his draft for checkin; a uri for that is: http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-compute-checkin-uri-01.html) For PUT, though, you should probably be able to handle getting a bare 200 response (see section 9.6 of RFC 2616.) Or am I misunderstanding your question? regards, Ted Hardie >Should the 200 (or 201 for that matter) contain the contents the were PUT? If so, does it include the resource interdependencies (like the resource list URI in the list case)? > >If no, does that mean the client needs to follow the PUT with a GET to learn of the resource interdependencies? > >Thanks, >Hisham > >_______________________________________________ >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 exim@www1.ietf.org Thu Dec 11 13:50:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13931 for ; Thu, 11 Dec 2003 13:50:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVt1-0002pj-0m for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 13:50:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBIo6hM010887 for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 13:50:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVt0-0002pW-Qg for simple-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 13:50:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13875; Thu, 11 Dec 2003 13:50:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsy-0003uD-00; Thu, 11 Dec 2003 13:50:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUVsx-0003uA-00; Thu, 11 Dec 2003 13:50:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVsw-0002or-Sd; Thu, 11 Dec 2003 13:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUVse-0002o7-LZ for simple@optimus.ietf.org; Thu, 11 Dec 2003 13:49:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13842 for ; Thu, 11 Dec 2003 13:49:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsc-0003so-00 for simple@ietf.org; Thu, 11 Dec 2003 13:49:42 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AUVsb-0003sj-00 for simple@ietf.org; Thu, 11 Dec 2003 13:49:41 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBBInb4t016944; Thu, 11 Dec 2003 10:49:38 -0800 (PST) Received: from [205.214.163.16] (vpn-10-50-0-7.qualcomm.com [10.50.0.7]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBBInWhk021605; Thu, 11 Dec 2003 10:49:34 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB7017974E5@esebe019.ntc.nokia.com> To: hisham.khartabil@nokia.com, From: Ted Hardie Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 10:49:31 -0800 At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: >This is not clear in XCAP. I also check RFC2616 to find out some sort of answer, but it is not clear there either. The 200 response doesn't require a response body for HTTP. You can define a response body appropriate for a specific method (Julian Reschke has a webdav-related example in his draft for checkin; a uri for that is: http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-compute-checkin-uri-01.html) For PUT, though, you should probably be able to handle getting a bare 200 response (see section 9.6 of RFC 2616.) Or am I misunderstanding your question? regards, Ted Hardie >Should the 200 (or 201 for that matter) contain the contents the were PUT? If so, does it include the resource interdependencies (like the resource list URI in the list case)? > >If no, does that mean the client needs to follow the PUT with a GET to learn of the resource interdependencies? > >Thanks, >Hisham > >_______________________________________________ >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-admin@ietf.org Thu Dec 11 16:21:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25508; Thu, 11 Dec 2003 16:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYF6-0001UA-00; Thu, 11 Dec 2003 16:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUYF5-0001U5-00; Thu, 11 Dec 2003 16:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYF4-0000dg-37; Thu, 11 Dec 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYEh-0000d9-Q8 for simple@optimus.ietf.org; Thu, 11 Dec 2003 16:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25469 for ; Thu, 11 Dec 2003 16:20:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYEg-0001TV-00 for simple@ietf.org; Thu, 11 Dec 2003 16:20:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AUYEf-0001T8-00 for simple@ietf.org; Thu, 11 Dec 2003 16:20:37 -0500 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLKAmR000496; Thu, 11 Dec 2003 16:20:11 -0500 (EST) Message-ID: <3FD8776E.7070102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 08:55:58 -0500 Content-Transfer-Encoding: 7bit I was also unable to find any text on this subject in RFC2616. It was always my underestanding that the PUT 200 OK response had no body. If any of our http experts could provide a more authoritative answer, it would be welcome. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > of course the question was: What goes in the body of a 200 response > of a PUT request? > > Apologies for the lack of clarity in the first post. > > /Hisham > > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of ext >> hisham.khartabil@nokia.com Sent: 11.December.2003 11:42 To: >> simple@ietf.org Subject: [Simple] XCAP: what does in the 200 of a >> PUT request >> >> >> This is not clear in XCAP. I also check RFC2616 to find out some >> sort of answer, but it is not clear there either. >> >> Should the 200 (or 201 for that matter) contain the contents the >> were PUT? If so, does it include the resource interdependencies >> (like the resource list URI in the list case)? >> >> If no, does that mean the client needs to follow the PUT with a >> GET to learn of the resource interdependencies? >> >> Thanks, Hisham >> >> _______________________________________________ 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 11 16:21:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25539 for ; Thu, 11 Dec 2003 16:21:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYF8-0000fk-MM for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 16:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBLL6ka002578 for simple-archive@odin.ietf.org; Thu, 11 Dec 2003 16:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYF8-0000fV-IB for simple-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 16:21:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25508; Thu, 11 Dec 2003 16:21:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYF6-0001UA-00; Thu, 11 Dec 2003 16:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUYF5-0001U5-00; Thu, 11 Dec 2003 16:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYF4-0000dg-37; Thu, 11 Dec 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUYEh-0000d9-Q8 for simple@optimus.ietf.org; Thu, 11 Dec 2003 16:20:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25469 for ; Thu, 11 Dec 2003 16:20:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUYEg-0001TV-00 for simple@ietf.org; Thu, 11 Dec 2003 16:20:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AUYEf-0001T8-00 for simple@ietf.org; Thu, 11 Dec 2003 16:20:37 -0500 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBBLKAmR000496; Thu, 11 Dec 2003 16:20:11 -0500 (EST) Message-ID: <3FD8776E.7070102@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017974E7@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 11 Dec 2003 08:55:58 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I was also unable to find any text on this subject in RFC2616. It was always my underestanding that the PUT 200 OK response had no body. If any of our http experts could provide a more authoritative answer, it would be welcome. Thanks, Jonathan R. hisham.khartabil@nokia.com wrote: > of course the question was: What goes in the body of a 200 response > of a PUT request? > > Apologies for the lack of clarity in the first post. > > /Hisham > > >> -----Original Message----- From: simple-admin@ietf.org >> [mailto:simple-admin@ietf.org]On Behalf Of ext >> hisham.khartabil@nokia.com Sent: 11.December.2003 11:42 To: >> simple@ietf.org Subject: [Simple] XCAP: what does in the 200 of a >> PUT request >> >> >> This is not clear in XCAP. I also check RFC2616 to find out some >> sort of answer, but it is not clear there either. >> >> Should the 200 (or 201 for that matter) contain the contents the >> were PUT? If so, does it include the resource interdependencies >> (like the resource list URI in the list case)? >> >> If no, does that mean the client needs to follow the PUT with a >> GET to learn of the resource interdependencies? >> >> Thanks, Hisham >> >> _______________________________________________ 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 > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 02:09:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24352; Fri, 12 Dec 2003 02:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhQ9-0005iy-00; Fri, 12 Dec 2003 02:09:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUhQ9-0005iv-00; Fri, 12 Dec 2003 02:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhQ7-00030Q-7B; Fri, 12 Dec 2003 02:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhPA-0002l4-Cx for simple@optimus.ietf.org; Fri, 12 Dec 2003 02:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23262 for ; Fri, 12 Dec 2003 02:08:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhP6-0005h7-00 for simple@ietf.org; Fri, 12 Dec 2003 02:08:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUhP5-0005gp-00 for simple@ietf.org; Fri, 12 Dec 2003 02:08:00 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBC780T28357 for ; Fri, 12 Dec 2003 09:08:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 09:07:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:07:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:07:58 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP: what does in the 200 of a PUT request Thread-Index: AcPAF5QSZ2MT8rB7S9GFjB6oT0KETgAZoeyg To: , X-OriginalArrivalTime: 12 Dec 2003 07:07:58.0589 (UTC) FILETIME=[AC50BAD0:01C3C07E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 09:07:58 +0200 Content-Transfer-Encoding: quoted-printable The real question is: is it wrong to have a body in a HTTP 200 response = for a PUT request? If not, can XCAP define what goes in the body? If a body in the 200 is wrong, does that mean the XCAP client needs to = follow the PUT with a GET to learn of the XCAP usage resource = interdependencies? Regards, Hisham > -----Original Message----- > From: ext Ted Hardie [mailto:hardie@qualcomm.com] > Sent: 11.December.2003 20:50 > To: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request >=20 >=20 > At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: > >This is not clear in XCAP. I also check RFC2616 to find out=20 > some sort of answer, but it is not clear there either. >=20 > The 200 response doesn't require a response body for HTTP. =20 > You can define > a response body appropriate for a specific method (Julian Reschke has > a webdav-related example in his draft for checkin; a uri for that is: > http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-comp > ute-checkin-uri-01.html) > For PUT, though, you should probably be able to handle=20 > getting a bare 200 response (see > section 9.6 of RFC 2616.) >=20 > Or am I misunderstanding your question? > regards,=09 > Ted Hardie >=20 >=20 > >Should the 200 (or 201 for that matter) contain the contents=20 > the were PUT? If so, does it include the resource=20 > interdependencies (like the resource list URI in the list case)? > > > >If no, does that mean the client needs to follow the PUT=20 > with a GET to learn of the resource interdependencies? > > > >Thanks, > >Hisham > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 12 02:09:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24890 for ; Fri, 12 Dec 2003 02:09:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhQE-00031Q-Ax for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 02:09:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC79AGT011613 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 02:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhQD-00031E-VQ for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 02:09:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24352; Fri, 12 Dec 2003 02:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhQ9-0005iy-00; Fri, 12 Dec 2003 02:09:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUhQ9-0005iv-00; Fri, 12 Dec 2003 02:09:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhQ7-00030Q-7B; Fri, 12 Dec 2003 02:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhPA-0002l4-Cx for simple@optimus.ietf.org; Fri, 12 Dec 2003 02:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23262 for ; Fri, 12 Dec 2003 02:08:01 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhP6-0005h7-00 for simple@ietf.org; Fri, 12 Dec 2003 02:08:00 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUhP5-0005gp-00 for simple@ietf.org; Fri, 12 Dec 2003 02:08:00 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBC780T28357 for ; Fri, 12 Dec 2003 09:08:00 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 09:07:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:07:58 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:07:58 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> Thread-Topic: [Simple] XCAP: what does in the 200 of a PUT request Thread-Index: AcPAF5QSZ2MT8rB7S9GFjB6oT0KETgAZoeyg To: , X-OriginalArrivalTime: 12 Dec 2003 07:07:58.0589 (UTC) FILETIME=[AC50BAD0:01C3C07E] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 09:07:58 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable The real question is: is it wrong to have a body in a HTTP 200 response = for a PUT request? If not, can XCAP define what goes in the body? If a body in the 200 is wrong, does that mean the XCAP client needs to = follow the PUT with a GET to learn of the XCAP usage resource = interdependencies? Regards, Hisham > -----Original Message----- > From: ext Ted Hardie [mailto:hardie@qualcomm.com] > Sent: 11.December.2003 20:50 > To: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request >=20 >=20 > At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: > >This is not clear in XCAP. I also check RFC2616 to find out=20 > some sort of answer, but it is not clear there either. >=20 > The 200 response doesn't require a response body for HTTP. =20 > You can define > a response body appropriate for a specific method (Julian Reschke has > a webdav-related example in his draft for checkin; a uri for that is: > http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-comp > ute-checkin-uri-01.html) > For PUT, though, you should probably be able to handle=20 > getting a bare 200 response (see > section 9.6 of RFC 2616.) >=20 > Or am I misunderstanding your question? > regards,=09 > Ted Hardie >=20 >=20 > >Should the 200 (or 201 for that matter) contain the contents=20 > the were PUT? If so, does it include the resource=20 > interdependencies (like the resource list URI in the list case)? > > > >If no, does that mean the client needs to follow the PUT=20 > with a GET to learn of the resource interdependencies? > > > >Thanks, > >Hisham > > > >_______________________________________________ > >Simple mailing list > >Simple@ietf.org > >https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 02:18:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28352; Fri, 12 Dec 2003 02:18:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhYp-0005uG-00; Fri, 12 Dec 2003 02:18:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUhYo-0005uD-00; Fri, 12 Dec 2003 02:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYo-00046J-0w; Fri, 12 Dec 2003 02:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYB-00041w-Az for simple@optimus.ietf.org; Fri, 12 Dec 2003 02:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28284 for ; Fri, 12 Dec 2003 02:17:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhY7-0005st-00 for simple@ietf.org; Fri, 12 Dec 2003 02:17:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUhY7-0005si-00 for simple@ietf.org; Fri, 12 Dec 2003 02:17:19 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBC7HJT09020 for ; Fri, 12 Dec 2003 09:17:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 09:17:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:17:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on message-sessions-02 - message retry Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPACSlHSA4EFzTvQOiqIbX5139h9AAdcSnA To: Cc: , , X-OriginalArrivalTime: 12 Dec 2003 07:17:17.0337 (UTC) FILETIME=[F95AE890:01C3C07F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 09:17:16 +0200 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 11.December.2003 19:05 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > What was the outcome of this discussion? Are we supporting=20 > message retransmission? >=20 > I think we are agreed to not attempt retransmission on the same=20 > connection. We are also agreed that, when a connection fails, we must=20 > re-signal to create a new one. Can we define what connection failure means? If a connection is dropped = by the visitor, how does the host know if that was a connection failure = or simply that the visitor is ending the session? >=20 > I think we still need discussion on how to associate a new connection=20 > with the old, when both are associated with the same dialog,=20 > and how to=20 > deal with retrying any messages that may have failed on the old=20 > connection on an associated new connection. Oh yes, this was for the automata case, right? I still think humans are = intelligent enough to know that a message that they sent did not get = through and to resend. In this case, we don't need to associate = connections. This assumption helps greatly in enabling the protocol to = handle long messages. /Hisham >=20 >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>Sent: 28.November.2003 18:56 > >>To: Ben Campbell; Paul Kyzivat > >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > >>Subject: RE: [Simple] Comments on message-sessions-02 -=20 > message retry > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 10 November 2003 17:09 > >>>To: Paul Kyzivat > >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org > >>>Subject: Re: [Simple] Comments on message-sessions-02 -=20 > message retry > >>> > >>>Paul Kyzivat wrote: > >>> > >>>[...] > >>> > >>> > >>>>I'm not certain a time period is really necessary. I=20 > think this can > >> > >>be > >> > >>>>local option. > >>>> > >>>>Even uniqueness across streams isn't *required*, though=20 > it would be > >>>>helpful. Instead, we can simply introduce an error response to be > >> > >>used > >> > >>>>when a duplicate is detected and supressed. If it was supressed in > >> > >>error > >> > >>>>because the sender duplicated a TR-ID from another stream,=20 > >> > >>the sender > >> > >>>>would then know to recover. > >>>> > >>>>But I agree that some further clarification on TR-ID=20 > >> > >>uniqueness could > >>be > >> > >>>>helpful. > >>>> > >>> > >>>If TR-ID is not required to be unique across sessions, and=20 > you allow > >>>clients to attempt to find duplicate messages using TR-ID across > >>>sessions, then you introduce the possibility of false=20 > >> > >>detection caused > >> > >>>by TR-ID collisions. This seems bad to me. > >>> > >> > >>[Chris Boulton] I totally agree. > >> > >> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>>_____________________________________________________________ > >> > >>__________ > >>_ > >> > >>>This email has been scanned for all viruses by the=20 > MessageLabs Email > >>>Security System. For more information on a proactive email security > >>>service working around the clock, around the globe, visit > >>>http://www.messagelabs.com > >>>_____________________________________________________________ > >> > >>__________ > >>_ > >> > >>______________________________________________________________ > >>__________ > >>This email has been scanned for all viruses by the MessageLabs Email > >>Security System. For more information on a proactive email security > >>service working around the clock, around the globe, visit > >>http://www.messagelabs.com > >>______________________________________________________________ > >>__________ > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 12 02:18:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28424 for ; Fri, 12 Dec 2003 02:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYw-00048K-0M for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 02:18:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC7I9SR015816 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 02:18:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYt-000471-DK for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 02:18:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28352; Fri, 12 Dec 2003 02:18:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhYp-0005uG-00; Fri, 12 Dec 2003 02:18:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUhYo-0005uD-00; Fri, 12 Dec 2003 02:18:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYo-00046J-0w; Fri, 12 Dec 2003 02:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUhYB-00041w-Az for simple@optimus.ietf.org; Fri, 12 Dec 2003 02:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28284 for ; Fri, 12 Dec 2003 02:17:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUhY7-0005st-00 for simple@ietf.org; Fri, 12 Dec 2003 02:17:19 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AUhY7-0005si-00 for simple@ietf.org; Fri, 12 Dec 2003 02:17:19 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBC7HJT09020 for ; Fri, 12 Dec 2003 09:17:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 09:17:17 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 09:17:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Simple] Comments on message-sessions-02 - message retry Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPACSlHSA4EFzTvQOiqIbX5139h9AAdcSnA To: Cc: , , X-OriginalArrivalTime: 12 Dec 2003 07:17:17.0337 (UTC) FILETIME=[F95AE890:01C3C07F] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 09:17:16 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 11.December.2003 19:05 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > What was the outcome of this discussion? Are we supporting=20 > message retransmission? >=20 > I think we are agreed to not attempt retransmission on the same=20 > connection. We are also agreed that, when a connection fails, we must=20 > re-signal to create a new one. Can we define what connection failure means? If a connection is dropped = by the visitor, how does the host know if that was a connection failure = or simply that the visitor is ending the session? >=20 > I think we still need discussion on how to associate a new connection=20 > with the old, when both are associated with the same dialog,=20 > and how to=20 > deal with retrying any messages that may have failed on the old=20 > connection on an associated new connection. Oh yes, this was for the automata case, right? I still think humans are = intelligent enough to know that a message that they sent did not get = through and to resend. In this case, we don't need to associate = connections. This assumption helps greatly in enabling the protocol to = handle long messages. /Hisham >=20 >=20 > >=20 > > Regards, > > Hisham > >=20 > >=20 > >>-----Original Message----- > >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > >>Sent: 28.November.2003 18:56 > >>To: Ben Campbell; Paul Kyzivat > >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > >>Subject: RE: [Simple] Comments on message-sessions-02 -=20 > message retry > >> > >> > >> > >> > >> > >>>-----Original Message----- > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > >>>Sent: 10 November 2003 17:09 > >>>To: Paul Kyzivat > >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org > >>>Subject: Re: [Simple] Comments on message-sessions-02 -=20 > message retry > >>> > >>>Paul Kyzivat wrote: > >>> > >>>[...] > >>> > >>> > >>>>I'm not certain a time period is really necessary. I=20 > think this can > >> > >>be > >> > >>>>local option. > >>>> > >>>>Even uniqueness across streams isn't *required*, though=20 > it would be > >>>>helpful. Instead, we can simply introduce an error response to be > >> > >>used > >> > >>>>when a duplicate is detected and supressed. If it was supressed in > >> > >>error > >> > >>>>because the sender duplicated a TR-ID from another stream,=20 > >> > >>the sender > >> > >>>>would then know to recover. > >>>> > >>>>But I agree that some further clarification on TR-ID=20 > >> > >>uniqueness could > >>be > >> > >>>>helpful. > >>>> > >>> > >>>If TR-ID is not required to be unique across sessions, and=20 > you allow > >>>clients to attempt to find duplicate messages using TR-ID across > >>>sessions, then you introduce the possibility of false=20 > >> > >>detection caused > >> > >>>by TR-ID collisions. This seems bad to me. > >>> > >> > >>[Chris Boulton] I totally agree. > >> > >> > >>> > >>>_______________________________________________ > >>>Simple mailing list > >>>Simple@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/simple > >>> > >>>_____________________________________________________________ > >> > >>__________ > >>_ > >> > >>>This email has been scanned for all viruses by the=20 > MessageLabs Email > >>>Security System. For more information on a proactive email security > >>>service working around the clock, around the globe, visit > >>>http://www.messagelabs.com > >>>_____________________________________________________________ > >> > >>__________ > >>_ > >> > >>______________________________________________________________ > >>__________ > >>This email has been scanned for all viruses by the MessageLabs Email > >>Security System. For more information on a proactive email security > >>service working around the clock, around the globe, visit > >>http://www.messagelabs.com > >>______________________________________________________________ > >>__________ > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 03:16:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00854; Fri, 12 Dec 2003 03:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUiSy-0007DO-00; Fri, 12 Dec 2003 03:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUiSx-0007DL-00; Fri, 12 Dec 2003 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiSv-0006gx-CI; Fri, 12 Dec 2003 03:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiSP-0006gH-6P for simple@optimus.ietf.org; Fri, 12 Dec 2003 03:15:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00836 for ; Fri, 12 Dec 2003 03:15:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUiSM-0007CU-00 for simple@ietf.org; Fri, 12 Dec 2003 03:15:26 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AUiSM-0007CR-00 for simple@ietf.org; Fri, 12 Dec 2003 03:15:26 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 5EDB4B5745 for ; Fri, 12 Dec 2003 03:15:27 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003121203152617538 ; Fri, 12 Dec 2003 03:15:26 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Dec 2003 03:15:26 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPACSlHSA4EFzTvQOiqIbX5139h9AAdcSnAAAIzsAA= From: "Andrew Allen" To: , Cc: , , X-OriginalArrivalTime: 12 Dec 2003 08:15:26.0790 (UTC) FILETIME=[193B2E60:01C3C088] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 03:15:26 -0500 Content-Transfer-Encoding: quoted-printable Surely the use of a BYE is mandatory for the normal ending of a session. This is what I understood from the draft anyway. According to message-sessions-02 in clause 4 "When either party wishes to end the session, it informs the peer party with a SIP BYE request. A terminates the session by invalidating associated state, and dropping the connection."=20 If no BYE is received and the connection is dropped then it is a failure condition in my opinion. Andrew > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Friday, December 12, 2003 2:17 AM > To: bcampbell@dynamicsoft.com > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 11.December.2003 19:05 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > > Subject: Re: [Simple] Comments on message-sessions-02 - message retry > > > > > > hisham.khartabil@nokia.com wrote: > > > > > What was the outcome of this discussion? Are we supporting > > message retransmission? > > > > I think we are agreed to not attempt retransmission on the same > > connection. We are also agreed that, when a connection fails, we must > > re-signal to create a new one. >=20 > Can we define what connection failure means? If a connection is dropped by > the visitor, how does the host know if that was a connection failure or > simply that the visitor is ending the session? >=20 > > > > I think we still need discussion on how to associate a new connection > > with the old, when both are associated with the same dialog, > > and how to > > deal with retrying any messages that may have failed on the old > > connection on an associated new connection. >=20 > Oh yes, this was for the automata case, right? I still think humans are > intelligent enough to know that a message that they sent did not get > through and to resend. In this case, we don't need to associate > connections. This assumption helps greatly in enabling the protocol to > handle long messages. >=20 > /Hisham >=20 > > > > > > > > > > Regards, > > > Hisham > > > > > > > > >>-----Original Message----- > > >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > >>Sent: 28.November.2003 18:56 > > >>To: Ben Campbell; Paul Kyzivat > > >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > > >>Subject: RE: [Simple] Comments on message-sessions-02 - > > message retry > > >> > > >> > > >> > > >> > > >> > > >>>-----Original Message----- > > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>>Sent: 10 November 2003 17:09 > > >>>To: Paul Kyzivat > > >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org > > >>>Subject: Re: [Simple] Comments on message-sessions-02 - > > message retry > > >>> > > >>>Paul Kyzivat wrote: > > >>> > > >>>[...] > > >>> > > >>> > > >>>>I'm not certain a time period is really necessary. I > > think this can > > >> > > >>be > > >> > > >>>>local option. > > >>>> > > >>>>Even uniqueness across streams isn't *required*, though > > it would be > > >>>>helpful. Instead, we can simply introduce an error response to be > > >> > > >>used > > >> > > >>>>when a duplicate is detected and supressed. If it was supressed in > > >> > > >>error > > >> > > >>>>because the sender duplicated a TR-ID from another stream, > > >> > > >>the sender > > >> > > >>>>would then know to recover. > > >>>> > > >>>>But I agree that some further clarification on TR-ID > > >> > > >>uniqueness could > > >>be > > >> > > >>>>helpful. > > >>>> > > >>> > > >>>If TR-ID is not required to be unique across sessions, and > > you allow > > >>>clients to attempt to find duplicate messages using TR-ID across > > >>>sessions, then you introduce the possibility of false > > >> > > >>detection caused > > >> > > >>>by TR-ID collisions. This seems bad to me. > > >>> > > >> > > >>[Chris Boulton] I totally agree. > > >> > > >> > > >>> > > >>>_______________________________________________ > > >>>Simple mailing list > > >>>Simple@ietf.org > > >>>https://www1.ietf.org/mailman/listinfo/simple > > >>> > > >>>_____________________________________________________________ > > >> > > >>__________ > > >>_ > > >> > > >>>This email has been scanned for all viruses by the > > MessageLabs Email > > >>>Security System. For more information on a proactive email security > > >>>service working around the clock, around the globe, visit > > >>>http://www.messagelabs.com > > >>>_____________________________________________________________ > > >> > > >>__________ > > >>_ > > >> > > >>______________________________________________________________ > > >>__________ > > >>This email has been scanned for all viruses by the MessageLabs Email > > >>Security System. For more information on a proactive email security > > >>service working around the clock, around the globe, visit > > >>http://www.messagelabs.com > > >>______________________________________________________________ > > >>__________ > > >> > > > > > > >=20 > _______________________________________________ > 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 exim@www1.ietf.org Fri Dec 12 03:16:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00880 for ; Fri, 12 Dec 2003 03:16:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiT2-0006i0-4T for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 03:16:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC8G71s025787 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 03:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiT1-0006hq-Cx for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 03:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00854; Fri, 12 Dec 2003 03:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUiSy-0007DO-00; Fri, 12 Dec 2003 03:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUiSx-0007DL-00; Fri, 12 Dec 2003 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiSv-0006gx-CI; Fri, 12 Dec 2003 03:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUiSP-0006gH-6P for simple@optimus.ietf.org; Fri, 12 Dec 2003 03:15:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00836 for ; Fri, 12 Dec 2003 03:15:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUiSM-0007CU-00 for simple@ietf.org; Fri, 12 Dec 2003 03:15:26 -0500 Received: from [216.9.243.101] (helo=mhs99ykf.rim.net) by ietf-mx with esmtp (Exim 4.12) id 1AUiSM-0007CR-00 for simple@ietf.org; Fri, 12 Dec 2003 03:15:26 -0500 Received: from ngw04ykf.rim.net (ngw04ykf.rim.net [10.102.100.115]) by mhs99ykf.rim.net (Postfix) with SMTP id 5EDB4B5745 for ; Fri, 12 Dec 2003 03:15:27 -0500 (EST) Received: from XCH21YKF.rim.net ([10.102.100.36]) by ngw04ykf.rim.net (NAVGW 2.5.2.9) with SMTP id M2003121203152617538 ; Fri, 12 Dec 2003 03:15:26 -0500 Received: from xch15ykf.rim.net ([10.101.21.36]) by XCH21YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Dec 2003 03:15:26 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: RE: [Simple] Comments on message-sessions-02 - message retry Message-ID: Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPACSlHSA4EFzTvQOiqIbX5139h9AAdcSnAAAIzsAA= From: "Andrew Allen" To: , Cc: , , X-OriginalArrivalTime: 12 Dec 2003 08:15:26.0790 (UTC) FILETIME=[193B2E60:01C3C088] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 03:15:26 -0500 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Surely the use of a BYE is mandatory for the normal ending of a session. This is what I understood from the draft anyway. According to message-sessions-02 in clause 4 "When either party wishes to end the session, it informs the peer party with a SIP BYE request. A terminates the session by invalidating associated state, and dropping the connection."=20 If no BYE is received and the connection is dropped then it is a failure condition in my opinion. Andrew > -----Original Message----- > From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] > Sent: Friday, December 12, 2003 2:17 AM > To: bcampbell@dynamicsoft.com > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > Subject: RE: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 > > -----Original Message----- > > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: 11.December.2003 19:05 > > To: Khartabil Hisham (NMP-MSW/Helsinki) > > Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org > > Subject: Re: [Simple] Comments on message-sessions-02 - message retry > > > > > > hisham.khartabil@nokia.com wrote: > > > > > What was the outcome of this discussion? Are we supporting > > message retransmission? > > > > I think we are agreed to not attempt retransmission on the same > > connection. We are also agreed that, when a connection fails, we must > > re-signal to create a new one. >=20 > Can we define what connection failure means? If a connection is dropped by > the visitor, how does the host know if that was a connection failure or > simply that the visitor is ending the session? >=20 > > > > I think we still need discussion on how to associate a new connection > > with the old, when both are associated with the same dialog, > > and how to > > deal with retrying any messages that may have failed on the old > > connection on an associated new connection. >=20 > Oh yes, this was for the automata case, right? I still think humans are > intelligent enough to know that a message that they sent did not get > through and to resend. In this case, we don't need to associate > connections. This assumption helps greatly in enabling the protocol to > handle long messages. >=20 > /Hisham >=20 > > > > > > > > > > Regards, > > > Hisham > > > > > > > > >>-----Original Message----- > > >>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] > > >>Sent: 28.November.2003 18:56 > > >>To: Ben Campbell; Paul Kyzivat > > >>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org > > >>Subject: RE: [Simple] Comments on message-sessions-02 - > > message retry > > >> > > >> > > >> > > >> > > >> > > >>>-----Original Message----- > > >>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > >>>Sent: 10 November 2003 17:09 > > >>>To: Paul Kyzivat > > >>>Cc: hisham.khartabil@nokia.com; simple@ietf.org > > >>>Subject: Re: [Simple] Comments on message-sessions-02 - > > message retry > > >>> > > >>>Paul Kyzivat wrote: > > >>> > > >>>[...] > > >>> > > >>> > > >>>>I'm not certain a time period is really necessary. I > > think this can > > >> > > >>be > > >> > > >>>>local option. > > >>>> > > >>>>Even uniqueness across streams isn't *required*, though > > it would be > > >>>>helpful. Instead, we can simply introduce an error response to be > > >> > > >>used > > >> > > >>>>when a duplicate is detected and supressed. If it was supressed in > > >> > > >>error > > >> > > >>>>because the sender duplicated a TR-ID from another stream, > > >> > > >>the sender > > >> > > >>>>would then know to recover. > > >>>> > > >>>>But I agree that some further clarification on TR-ID > > >> > > >>uniqueness could > > >>be > > >> > > >>>>helpful. > > >>>> > > >>> > > >>>If TR-ID is not required to be unique across sessions, and > > you allow > > >>>clients to attempt to find duplicate messages using TR-ID across > > >>>sessions, then you introduce the possibility of false > > >> > > >>detection caused > > >> > > >>>by TR-ID collisions. This seems bad to me. > > >>> > > >> > > >>[Chris Boulton] I totally agree. > > >> > > >> > > >>> > > >>>_______________________________________________ > > >>>Simple mailing list > > >>>Simple@ietf.org > > >>>https://www1.ietf.org/mailman/listinfo/simple > > >>> > > >>>_____________________________________________________________ > > >> > > >>__________ > > >>_ > > >> > > >>>This email has been scanned for all viruses by the > > MessageLabs Email > > >>>Security System. For more information on a proactive email security > > >>>service working around the clock, around the globe, visit > > >>>http://www.messagelabs.com > > >>>_____________________________________________________________ > > >> > > >>__________ > > >>_ > > >> > > >>______________________________________________________________ > > >>__________ > > >>This email has been scanned for all viruses by the MessageLabs Email > > >>Security System. For more information on a proactive email security > > >>service working around the clock, around the globe, visit > > >>http://www.messagelabs.com > > >>______________________________________________________________ > > >>__________ > > >> > > > > > > >=20 > _______________________________________________ > 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-admin@ietf.org Fri Dec 12 09:26:17 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09043; Fri, 12 Dec 2003 09:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoFG-0005rV-00; Fri, 12 Dec 2003 09:26:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUoFG-0005rS-00; Fri, 12 Dec 2003 09:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoF0-0004Gq-B3; Fri, 12 Dec 2003 09:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoEx-0004GB-Iv for simple@optimus.ietf.org; Fri, 12 Dec 2003 09:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09032 for ; Fri, 12 Dec 2003 09:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoEv-0005r0-00 for simple@ietf.org; Fri, 12 Dec 2003 09:25:58 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AUoEv-0005qj-00 for simple@ietf.org; Fri, 12 Dec 2003 09:25:57 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBCEPYnG083402; Fri, 12 Dec 2003 08:25:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD9CFDB.1050205@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, pkyzivat@cisco.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 08:25:31 -0600 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 11.December.2003 19:05 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>What was the outcome of this discussion? Are we supporting >> >>message retransmission? >> >>I think we are agreed to not attempt retransmission on the same >>connection. We are also agreed that, when a connection fails, we must >>re-signal to create a new one. > > > Can we define what connection failure means? If a connection is dropped by the visitor, how does the host know if that was a connection failure or simply that the visitor is ending the session? > If the visitor really means it, it should first be sending a BYE, or equivelant if it is not using SIP. This is, by the way, not so much an MSRP issue as a general SIP issue using any connection-oriented media. I wonder if the current COMEDIA draft has anything to say about this? (I will check, unless someone knows off the top of his or her head.) > >>I think we still need discussion on how to associate a new connection >>with the old, when both are associated with the same dialog, >>and how to >>deal with retrying any messages that may have failed on the old >>connection on an associated new connection. > > > Oh yes, this was for the automata case, right? I still think humans are intelligent enough to know that a message that they sent did not get through and to resend. In this case, we don't need to associate connections. This assumption helps greatly in enabling the protocol to handle long messages. > Others have wanted it for the intelligent being case as well. I am personally neutral on this point. > /Hisham > > >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>Sent: 28.November.2003 18:56 >>>>To: Ben Campbell; Paul Kyzivat >>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>>>Subject: RE: [Simple] Comments on message-sessions-02 - >> >>message retry >> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 10 November 2003 17:09 >>>>>To: Paul Kyzivat >>>>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>>>Subject: Re: [Simple] Comments on message-sessions-02 - >> >>message retry >> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>> >>>>> >>>>>>I'm not certain a time period is really necessary. I >> >>think this can >> >>>>be >>>> >>>> >>>>>>local option. >>>>>> >>>>>>Even uniqueness across streams isn't *required*, though >> >>it would be >> >>>>>>helpful. Instead, we can simply introduce an error response to be >>>> >>>>used >>>> >>>> >>>>>>when a duplicate is detected and supressed. If it was supressed in >>>> >>>>error >>>> >>>> >>>>>>because the sender duplicated a TR-ID from another stream, >>>> >>>>the sender >>>> >>>> >>>>>>would then know to recover. >>>>>> >>>>>>But I agree that some further clarification on TR-ID >>>> >>>>uniqueness could >>>>be >>>> >>>> >>>>>>helpful. >>>>>> >>>>> >>>>>If TR-ID is not required to be unique across sessions, and >> >>you allow >> >>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>sessions, then you introduce the possibility of false >>>> >>>>detection caused >>>> >>>> >>>>>by TR-ID collisions. This seems bad to me. >>>>> >>>> >>>>[Chris Boulton] I totally agree. >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>>_____________________________________________________________ >>>> >>>>__________ >>>>_ >>>> >>>> >>>>>This email has been scanned for all viruses by the >> >>MessageLabs Email >> >>>>>Security System. For more information on a proactive email security >>>>>service working around the clock, around the globe, visit >>>>>http://www.messagelabs.com >>>>>_____________________________________________________________ >>>> >>>>__________ >>>>_ >>>> >>>>______________________________________________________________ >>>>__________ >>>>This email has been scanned for all viruses by the MessageLabs Email >>>>Security System. For more information on a proactive email security >>>>service working around the clock, around the globe, visit >>>>http://www.messagelabs.com >>>>______________________________________________________________ >>>>__________ >>>> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 12 09:26:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09062 for ; Fri, 12 Dec 2003 09:26:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoFI-0004Im-R6 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 09:26:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCEQKIT016536 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 09:26:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoFI-0004Ic-MG for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 09:26:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09043; Fri, 12 Dec 2003 09:26:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoFG-0005rV-00; Fri, 12 Dec 2003 09:26:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUoFG-0005rS-00; Fri, 12 Dec 2003 09:26:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoF0-0004Gq-B3; Fri, 12 Dec 2003 09:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUoEx-0004GB-Iv for simple@optimus.ietf.org; Fri, 12 Dec 2003 09:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09032 for ; Fri, 12 Dec 2003 09:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUoEv-0005r0-00 for simple@ietf.org; Fri, 12 Dec 2003 09:25:58 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AUoEv-0005qj-00 for simple@ietf.org; Fri, 12 Dec 2003 09:25:57 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBCEPYnG083402; Fri, 12 Dec 2003 08:25:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FD9CFDB.1050205@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: cboulton@ubiquity.net, pkyzivat@cisco.com, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 08:25:31 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 11.December.2003 19:05 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>Subject: Re: [Simple] Comments on message-sessions-02 - message retry >> >> >>hisham.khartabil@nokia.com wrote: >> >> >>>What was the outcome of this discussion? Are we supporting >> >>message retransmission? >> >>I think we are agreed to not attempt retransmission on the same >>connection. We are also agreed that, when a connection fails, we must >>re-signal to create a new one. > > > Can we define what connection failure means? If a connection is dropped by the visitor, how does the host know if that was a connection failure or simply that the visitor is ending the session? > If the visitor really means it, it should first be sending a BYE, or equivelant if it is not using SIP. This is, by the way, not so much an MSRP issue as a general SIP issue using any connection-oriented media. I wonder if the current COMEDIA draft has anything to say about this? (I will check, unless someone knows off the top of his or her head.) > >>I think we still need discussion on how to associate a new connection >>with the old, when both are associated with the same dialog, >>and how to >>deal with retrying any messages that may have failed on the old >>connection on an associated new connection. > > > Oh yes, this was for the automata case, right? I still think humans are intelligent enough to know that a message that they sent did not get through and to resend. In this case, we don't need to associate connections. This assumption helps greatly in enabling the protocol to handle long messages. > Others have wanted it for the intelligent being case as well. I am personally neutral on this point. > /Hisham > > >> >>>Regards, >>>Hisham >>> >>> >>> >>>>-----Original Message----- >>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>Sent: 28.November.2003 18:56 >>>>To: Ben Campbell; Paul Kyzivat >>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>>>Subject: RE: [Simple] Comments on message-sessions-02 - >> >>message retry >> >>>> >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>Sent: 10 November 2003 17:09 >>>>>To: Paul Kyzivat >>>>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>>>Subject: Re: [Simple] Comments on message-sessions-02 - >> >>message retry >> >>>>>Paul Kyzivat wrote: >>>>> >>>>>[...] >>>>> >>>>> >>>>> >>>>>>I'm not certain a time period is really necessary. I >> >>think this can >> >>>>be >>>> >>>> >>>>>>local option. >>>>>> >>>>>>Even uniqueness across streams isn't *required*, though >> >>it would be >> >>>>>>helpful. Instead, we can simply introduce an error response to be >>>> >>>>used >>>> >>>> >>>>>>when a duplicate is detected and supressed. If it was supressed in >>>> >>>>error >>>> >>>> >>>>>>because the sender duplicated a TR-ID from another stream, >>>> >>>>the sender >>>> >>>> >>>>>>would then know to recover. >>>>>> >>>>>>But I agree that some further clarification on TR-ID >>>> >>>>uniqueness could >>>>be >>>> >>>> >>>>>>helpful. >>>>>> >>>>> >>>>>If TR-ID is not required to be unique across sessions, and >> >>you allow >> >>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>sessions, then you introduce the possibility of false >>>> >>>>detection caused >>>> >>>> >>>>>by TR-ID collisions. This seems bad to me. >>>>> >>>> >>>>[Chris Boulton] I totally agree. >>>> >>>> >>>> >>>>>_______________________________________________ >>>>>Simple mailing list >>>>>Simple@ietf.org >>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>> >>>>>_____________________________________________________________ >>>> >>>>__________ >>>>_ >>>> >>>> >>>>>This email has been scanned for all viruses by the >> >>MessageLabs Email >> >>>>>Security System. For more information on a proactive email security >>>>>service working around the clock, around the globe, visit >>>>>http://www.messagelabs.com >>>>>_____________________________________________________________ >>>> >>>>__________ >>>>_ >>>> >>>>______________________________________________________________ >>>>__________ >>>>This email has been scanned for all viruses by the MessageLabs Email >>>>Security System. For more information on a proactive email security >>>>service working around the clock, around the globe, visit >>>>http://www.messagelabs.com >>>>______________________________________________________________ >>>>__________ >>>> >> >> >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 10:21:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11897; Fri, 12 Dec 2003 10:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUp6E-0006sH-00; Fri, 12 Dec 2003 10:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUp6E-0006sE-00; Fri, 12 Dec 2003 10:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp6D-0006ss-Mx; Fri, 12 Dec 2003 10:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp5x-0006ra-Pc for simple@optimus.ietf.org; Fri, 12 Dec 2003 10:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11874 for ; Fri, 12 Dec 2003 10:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUp5v-0006rC-00 for simple@ietf.org; Fri, 12 Dec 2003 10:20:43 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUp5u-0006r1-00 for simple@ietf.org; Fri, 12 Dec 2003 10:20:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2003 07:22:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBCFK8BN000048; Fri, 12 Dec 2003 07:20:09 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEP87754; Fri, 12 Dec 2003 10:20:07 -0500 (EST) Message-ID: <3FD9DCA7.9070500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen CC: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 10:20:07 -0500 Content-Transfer-Encoding: 7bit BYE certainly isn't required to end the MSRP media session, but some form of signaling is. It could be BYE, but it could be another offer that sets the port to zero in the m-line. But I agree with the basic point - a connection drop is ok after signaling indicating it should go away, otherwise it is an error. Paul Andrew Allen wrote: > > > Surely the use of a BYE is mandatory for the normal ending of a session. > This is what I understood from the draft anyway. > > According to message-sessions-02 in clause 4 > > "When either party wishes to end the session, it informs the peer > party with a SIP BYE request. A terminates the session by > invalidating associated state, and dropping the connection." > > If no BYE is received and the connection is dropped then it is a failure > condition in my opinion. > > Andrew > > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Friday, December 12, 2003 2:17 AM >>To: bcampbell@dynamicsoft.com >>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 - message retry >> >> >> >> >>>-----Original Message----- >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 11.December.2003 19:05 >>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>>Subject: Re: [Simple] Comments on message-sessions-02 - message >> > retry > >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>What was the outcome of this discussion? Are we supporting >>> >>>message retransmission? >>> >>>I think we are agreed to not attempt retransmission on the same >>>connection. We are also agreed that, when a connection fails, we >> > must > >>>re-signal to create a new one. >> >>Can we define what connection failure means? If a connection is > > dropped by > >>the visitor, how does the host know if that was a connection failure > > or > >>simply that the visitor is ending the session? >> >> >>>I think we still need discussion on how to associate a new >> > connection > >>>with the old, when both are associated with the same dialog, >>>and how to >>>deal with retrying any messages that may have failed on the old >>>connection on an associated new connection. >> >>Oh yes, this was for the automata case, right? I still think humans > > are > >>intelligent enough to know that a message that they sent did not get >>through and to resend. In this case, we don't need to associate >>connections. This assumption helps greatly in enabling the protocol to >>handle long messages. >> >>/Hisham >> >> >>> >>>>Regards, >>>>Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: 28.November.2003 18:56 >>>>>To: Ben Campbell; Paul Kyzivat >>>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>>>>Subject: RE: [Simple] Comments on message-sessions-02 - >>>> >>>message retry >>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>Sent: 10 November 2003 17:09 >>>>>>To: Paul Kyzivat >>>>>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>>>>Subject: Re: [Simple] Comments on message-sessions-02 - >>>>> >>>message retry >>> >>>>>>Paul Kyzivat wrote: >>>>>> >>>>>>[...] >>>>>> >>>>>> >>>>>> >>>>>>>I'm not certain a time period is really necessary. I >>>>>> >>>think this can >>> >>>>>be >>>>> >>>>> >>>>>>>local option. >>>>>>> >>>>>>>Even uniqueness across streams isn't *required*, though >>>>>> >>>it would be >>> >>>>>>>helpful. Instead, we can simply introduce an error response to >>>>>> > be > >>>>>used >>>>> >>>>> >>>>>>>when a duplicate is detected and supressed. If it was supressed >>>>>> > in > >>>>>error >>>>> >>>>> >>>>>>>because the sender duplicated a TR-ID from another stream, >>>>>> >>>>>the sender >>>>> >>>>> >>>>>>>would then know to recover. >>>>>>> >>>>>>>But I agree that some further clarification on TR-ID >>>>>> >>>>>uniqueness could >>>>>be >>>>> >>>>> >>>>>>>helpful. >>>>>>> >>>>>> >>>>>>If TR-ID is not required to be unique across sessions, and >>>>> >>>you allow >>> >>>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>>sessions, then you introduce the possibility of false >>>>> >>>>>detection caused >>>>> >>>>> >>>>>>by TR-ID collisions. This seems bad to me. >>>>>> >>>>> >>>>>[Chris Boulton] I totally agree. >>>>> >>>>> >>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_____________________________________________________________ >>>>> >>>>>__________ >>>>>_ >>>>> >>>>> >>>>>>This email has been scanned for all viruses by the >>>>> >>>MessageLabs Email >>> >>>>>>Security System. For more information on a proactive email >>>>> > security > >>>>>>service working around the clock, around the globe, visit >>>>>>http://www.messagelabs.com >>>>>>_____________________________________________________________ >>>>> >>>>>__________ >>>>>_ >>>>> >>>>>______________________________________________________________ >>>>>__________ >>>>>This email has been scanned for all viruses by the MessageLabs >>>> > Email > >>>>>Security System. For more information on a proactive email >>>> > security > >>>>>service working around the clock, around the globe, visit >>>>>http://www.messagelabs.com >>>>>______________________________________________________________ >>>>>__________ >>>>> >>>> >>> >>> >>_______________________________________________ >>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 exim@www1.ietf.org Fri Dec 12 10:21:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11935 for ; Fri, 12 Dec 2003 10:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp6I-0006v1-0w for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 10:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCFL5nI026587 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 10:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp6H-0006uj-Pz for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11897; Fri, 12 Dec 2003 10:21:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUp6E-0006sH-00; Fri, 12 Dec 2003 10:21:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUp6E-0006sE-00; Fri, 12 Dec 2003 10:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp6D-0006ss-Mx; Fri, 12 Dec 2003 10:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUp5x-0006ra-Pc for simple@optimus.ietf.org; Fri, 12 Dec 2003 10:20:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11874 for ; Fri, 12 Dec 2003 10:20:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUp5v-0006rC-00 for simple@ietf.org; Fri, 12 Dec 2003 10:20:43 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUp5u-0006r1-00 for simple@ietf.org; Fri, 12 Dec 2003 10:20:43 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2003 07:22:24 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBCFK8BN000048; Fri, 12 Dec 2003 07:20:09 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEP87754; Fri, 12 Dec 2003 10:20:07 -0500 (EST) Message-ID: <3FD9DCA7.9070500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Allen CC: hisham.khartabil@nokia.com, bcampbell@dynamicsoft.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 10:20:07 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit BYE certainly isn't required to end the MSRP media session, but some form of signaling is. It could be BYE, but it could be another offer that sets the port to zero in the m-line. But I agree with the basic point - a connection drop is ok after signaling indicating it should go away, otherwise it is an error. Paul Andrew Allen wrote: > > > Surely the use of a BYE is mandatory for the normal ending of a session. > This is what I understood from the draft anyway. > > According to message-sessions-02 in clause 4 > > "When either party wishes to end the session, it informs the peer > party with a SIP BYE request. A terminates the session by > invalidating associated state, and dropping the connection." > > If no BYE is received and the connection is dropped then it is a failure > condition in my opinion. > > Andrew > > > >>-----Original Message----- >>From: hisham.khartabil@nokia.com [mailto:hisham.khartabil@nokia.com] >>Sent: Friday, December 12, 2003 2:17 AM >>To: bcampbell@dynamicsoft.com >>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>Subject: RE: [Simple] Comments on message-sessions-02 - message retry >> >> >> >> >>>-----Original Message----- >>>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>Sent: 11.December.2003 19:05 >>>To: Khartabil Hisham (NMP-MSW/Helsinki) >>>Cc: cboulton@ubiquity.net; pkyzivat@cisco.com; simple@ietf.org >>>Subject: Re: [Simple] Comments on message-sessions-02 - message >> > retry > >>> >>>hisham.khartabil@nokia.com wrote: >>> >>> >>>>What was the outcome of this discussion? Are we supporting >>> >>>message retransmission? >>> >>>I think we are agreed to not attempt retransmission on the same >>>connection. We are also agreed that, when a connection fails, we >> > must > >>>re-signal to create a new one. >> >>Can we define what connection failure means? If a connection is > > dropped by > >>the visitor, how does the host know if that was a connection failure > > or > >>simply that the visitor is ending the session? >> >> >>>I think we still need discussion on how to associate a new >> > connection > >>>with the old, when both are associated with the same dialog, >>>and how to >>>deal with retrying any messages that may have failed on the old >>>connection on an associated new connection. >> >>Oh yes, this was for the automata case, right? I still think humans > > are > >>intelligent enough to know that a message that they sent did not get >>through and to resend. In this case, we don't need to associate >>connections. This assumption helps greatly in enabling the protocol to >>handle long messages. >> >>/Hisham >> >> >>> >>>>Regards, >>>>Hisham >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: ext Chris Boulton [mailto:cboulton@ubiquity.net] >>>>>Sent: 28.November.2003 18:56 >>>>>To: Ben Campbell; Paul Kyzivat >>>>>Cc: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >>>>>Subject: RE: [Simple] Comments on message-sessions-02 - >>>> >>>message retry >>> >>>>> >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>>>>>Sent: 10 November 2003 17:09 >>>>>>To: Paul Kyzivat >>>>>>Cc: hisham.khartabil@nokia.com; simple@ietf.org >>>>>>Subject: Re: [Simple] Comments on message-sessions-02 - >>>>> >>>message retry >>> >>>>>>Paul Kyzivat wrote: >>>>>> >>>>>>[...] >>>>>> >>>>>> >>>>>> >>>>>>>I'm not certain a time period is really necessary. I >>>>>> >>>think this can >>> >>>>>be >>>>> >>>>> >>>>>>>local option. >>>>>>> >>>>>>>Even uniqueness across streams isn't *required*, though >>>>>> >>>it would be >>> >>>>>>>helpful. Instead, we can simply introduce an error response to >>>>>> > be > >>>>>used >>>>> >>>>> >>>>>>>when a duplicate is detected and supressed. If it was supressed >>>>>> > in > >>>>>error >>>>> >>>>> >>>>>>>because the sender duplicated a TR-ID from another stream, >>>>>> >>>>>the sender >>>>> >>>>> >>>>>>>would then know to recover. >>>>>>> >>>>>>>But I agree that some further clarification on TR-ID >>>>>> >>>>>uniqueness could >>>>>be >>>>> >>>>> >>>>>>>helpful. >>>>>>> >>>>>> >>>>>>If TR-ID is not required to be unique across sessions, and >>>>> >>>you allow >>> >>>>>>clients to attempt to find duplicate messages using TR-ID across >>>>>>sessions, then you introduce the possibility of false >>>>> >>>>>detection caused >>>>> >>>>> >>>>>>by TR-ID collisions. This seems bad to me. >>>>>> >>>>> >>>>>[Chris Boulton] I totally agree. >>>>> >>>>> >>>>> >>>>>>_______________________________________________ >>>>>>Simple mailing list >>>>>>Simple@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/simple >>>>>> >>>>>>_____________________________________________________________ >>>>> >>>>>__________ >>>>>_ >>>>> >>>>> >>>>>>This email has been scanned for all viruses by the >>>>> >>>MessageLabs Email >>> >>>>>>Security System. For more information on a proactive email >>>>> > security > >>>>>>service working around the clock, around the globe, visit >>>>>>http://www.messagelabs.com >>>>>>_____________________________________________________________ >>>>> >>>>>__________ >>>>>_ >>>>> >>>>>______________________________________________________________ >>>>>__________ >>>>>This email has been scanned for all viruses by the MessageLabs >>>> > Email > >>>>>Security System. For more information on a proactive email >>>> > security > >>>>>service working around the clock, around the globe, visit >>>>>http://www.messagelabs.com >>>>>______________________________________________________________ >>>>>__________ >>>>> >>>> >>> >>> >>_______________________________________________ >>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-admin@ietf.org Fri Dec 12 10:41:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12872; Fri, 12 Dec 2003 10:41:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpPj-0007J0-00; Fri, 12 Dec 2003 10:41:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpPj-0007Ix-00; Fri, 12 Dec 2003 10:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPZ-0007kh-MG; Fri, 12 Dec 2003 10:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPW-0007kU-0i for simple@optimus.ietf.org; Fri, 12 Dec 2003 10:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12851 for ; Fri, 12 Dec 2003 10:40:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpPT-0007IV-00 for simple@ietf.org; Fri, 12 Dec 2003 10:40:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUpPT-0007I8-00 for simple@ietf.org; Fri, 12 Dec 2003 10:40:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2003 07:42:36 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBCFeKAt003087; Fri, 12 Dec 2003 07:40:21 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEP89663; Fri, 12 Dec 2003 10:40:19 -0500 (EST) Message-ID: <3FD9E163.70000@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> <3FD9CFDB.1050205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 10:40:19 -0500 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>> I think we still need discussion on how to associate a new connection >>> with the old, when both are associated with the same dialog, and how >>> to deal with retrying any messages that may have failed on the old >>> connection on an associated new connection. >> >> Oh yes, this was for the automata case, right? I still think humans >> are intelligent enough to know that a message that they sent did not >> get through and to resend. In this case, we don't need to associate >> connections. This assumption helps greatly in enabling the protocol to >> handle long messages. > > Others have wanted it for the intelligent being case as well. I am > personally neutral on this point. Yes, it is needed for all those reasons. But nobody will be forced to use it. If your UA chooses not to retransmit messages, that is fine. When the message is large, the UA might want to think hard before retrying it. But that is an application design issue. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 12 10:41:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12894 for ; Fri, 12 Dec 2003 10:41:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPn-0007ly-HY for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 10:41:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCFfFxX029872 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 10:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPn-0007lj-87 for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 10:41:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12872; Fri, 12 Dec 2003 10:41:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpPj-0007J0-00; Fri, 12 Dec 2003 10:41:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpPj-0007Ix-00; Fri, 12 Dec 2003 10:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPZ-0007kh-MG; Fri, 12 Dec 2003 10:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpPW-0007kU-0i for simple@optimus.ietf.org; Fri, 12 Dec 2003 10:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12851 for ; Fri, 12 Dec 2003 10:40:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpPT-0007IV-00 for simple@ietf.org; Fri, 12 Dec 2003 10:40:55 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AUpPT-0007I8-00 for simple@ietf.org; Fri, 12 Dec 2003 10:40:55 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 12 Dec 2003 07:42:36 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBCFeKAt003087; Fri, 12 Dec 2003 07:40:21 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEP89663; Fri, 12 Dec 2003 10:40:19 -0500 (EST) Message-ID: <3FD9E163.70000@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, cboulton@ubiquity.net, simple@ietf.org Subject: Re: [Simple] Comments on message-sessions-02 - message retry References: <2038BCC78B1AD641891A0D1AE133DBB70118B13A@esebe019.ntc.nokia.com> <3FD9CFDB.1050205@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 10:40:19 -0500 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > >>> I think we still need discussion on how to associate a new connection >>> with the old, when both are associated with the same dialog, and how >>> to deal with retrying any messages that may have failed on the old >>> connection on an associated new connection. >> >> Oh yes, this was for the automata case, right? I still think humans >> are intelligent enough to know that a message that they sent did not >> get through and to resend. In this case, we don't need to associate >> connections. This assumption helps greatly in enabling the protocol to >> handle long messages. > > Others have wanted it for the intelligent being case as well. I am > personally neutral on this point. Yes, it is needed for all those reasons. But nobody will be forced to use it. If your UA chooses not to retransmit messages, that is fine. When the message is large, the UA might want to think hard before retrying it. But that is an application design issue. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 11:34:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15286; Fri, 12 Dec 2003 11:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqEu-0000mc-00; Fri, 12 Dec 2003 11:34:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUqEu-0000mZ-00; Fri, 12 Dec 2003 11:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqEr-0001x1-5g; Fri, 12 Dec 2003 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqE3-0001vy-6e for simple@optimus.ietf.org; Fri, 12 Dec 2003 11:33:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15256 for ; Fri, 12 Dec 2003 11:33:08 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqE2-0000lv-00 for simple@ietf.org; Fri, 12 Dec 2003 11:33:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUqE1-0000ls-00 for simple@ietf.org; Fri, 12 Dec 2003 11:33:09 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCGX8H05946 for ; Fri, 12 Dec 2003 18:33:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 18:33:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 18:33:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on message-sessions-02 - message retry X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797500@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPAxkW6BwSRK9SBQkSi3Xd/JEoirQABuQBA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 16:33:08.0792 (UTC) FILETIME=[A05F1380:01C3C0CD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 18:33:08 +0200 Content-Transfer-Encoding: quoted-printable Ok, for the sake of moving forward, I agree provided the text is clear = that this is not mandated and its an application design issue to = retransmit, especially long messages. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 12.December.2003 17:40 > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > >>> I think we still need discussion on how to associate a=20 > new connection=20 > >>> with the old, when both are associated with the same=20 > dialog, and how=20 > >>> to deal with retrying any messages that may have failed=20 > on the old=20 > >>> connection on an associated new connection. > >> > >> Oh yes, this was for the automata case, right? I still=20 > think humans=20 > >> are intelligent enough to know that a message that they=20 > sent did not=20 > >> get through and to resend. In this case, we don't need to=20 > associate=20 > >> connections. This assumption helps greatly in enabling the=20 > protocol to=20 > >> handle long messages. > >=20 > > Others have wanted it for the intelligent being case as well. I am=20 > > personally neutral on this point. >=20 > Yes, it is needed for all those reasons. >=20 > But nobody will be forced to use it. If your UA chooses not to=20 > retransmit messages, that is fine. When the message is large, the UA=20 > might want to think hard before retrying it. But that is an=20 > application=20 > design issue. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 12 11:34:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15315 for ; Fri, 12 Dec 2003 11:34:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqEw-0001xo-5v for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 11:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCGY6LT007547 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 11:34:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqEw-0001xe-0Q for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:34:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15286; Fri, 12 Dec 2003 11:34:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqEu-0000mc-00; Fri, 12 Dec 2003 11:34:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUqEu-0000mZ-00; Fri, 12 Dec 2003 11:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqEr-0001x1-5g; Fri, 12 Dec 2003 11:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUqE3-0001vy-6e for simple@optimus.ietf.org; Fri, 12 Dec 2003 11:33:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15256 for ; Fri, 12 Dec 2003 11:33:08 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUqE2-0000lv-00 for simple@ietf.org; Fri, 12 Dec 2003 11:33:10 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUqE1-0000ls-00 for simple@ietf.org; Fri, 12 Dec 2003 11:33:09 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBCGX8H05946 for ; Fri, 12 Dec 2003 18:33:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 12 Dec 2003 18:33:08 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 18:33:08 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] Comments on message-sessions-02 - message retry X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797500@esebe019.ntc.nokia.com> Thread-Topic: [Simple] Comments on message-sessions-02 - message retry Thread-Index: AcPAxkW6BwSRK9SBQkSi3Xd/JEoirQABuQBA To: , Cc: , X-OriginalArrivalTime: 12 Dec 2003 16:33:08.0792 (UTC) FILETIME=[A05F1380:01C3C0CD] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 18:33:08 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Ok, for the sake of moving forward, I agree provided the text is clear = that this is not mandated and its an application design issue to = retransmit, especially long messages. Regards, Hisham > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 12.December.2003 17:40 > To: Ben Campbell > Cc: Khartabil Hisham (NMP-MSW/Helsinki); cboulton@ubiquity.net; > simple@ietf.org > Subject: Re: [Simple] Comments on message-sessions-02 - message retry >=20 >=20 >=20 >=20 > Ben Campbell wrote: > >=20 > >>> I think we still need discussion on how to associate a=20 > new connection=20 > >>> with the old, when both are associated with the same=20 > dialog, and how=20 > >>> to deal with retrying any messages that may have failed=20 > on the old=20 > >>> connection on an associated new connection. > >> > >> Oh yes, this was for the automata case, right? I still=20 > think humans=20 > >> are intelligent enough to know that a message that they=20 > sent did not=20 > >> get through and to resend. In this case, we don't need to=20 > associate=20 > >> connections. This assumption helps greatly in enabling the=20 > protocol to=20 > >> handle long messages. > >=20 > > Others have wanted it for the intelligent being case as well. I am=20 > > personally neutral on this point. >=20 > Yes, it is needed for all those reasons. >=20 > But nobody will be forced to use it. If your UA chooses not to=20 > retransmit messages, that is fine. When the message is large, the UA=20 > might want to think hard before retrying it. But that is an=20 > application=20 > design issue. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 12 18:19:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03034; Fri, 12 Dec 2003 18:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYr-00043J-00; Fri, 12 Dec 2003 18:19:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUwYr-00043E-00; Fri, 12 Dec 2003 18:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYo-0006XE-Ax; Fri, 12 Dec 2003 18:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYJ-0006Wd-Sq for simple@optimus.ietf.org; Fri, 12 Dec 2003 18:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02980 for ; Fri, 12 Dec 2003 18:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYH-00042u-00 for simple@ietf.org; Fri, 12 Dec 2003 18:18:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYG-00042q-00 for simple@ietf.org; Fri, 12 Dec 2003 18:18:28 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCNIPVY006567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2003 15:18:26 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCNINU0023475; Fri, 12 Dec 2003 15:18:23 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> To: hisham.khartabil@nokia.com, From: Ted Hardie Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 15:18:22 -0800 At 9:07 AM +0200 12/12/2003, hisham.khartabil@nokia.com wrote: >The real question is: is it wrong to have a body in a HTTP 200 response for a PUT request? If not, can XCAP define what goes in the body? I think the answers are no, no, yes, and no. But that's partly because I think you are missing a few questions. A 200 response can have a body. (Unstated question: is this expected behavior now?) No, not really. Mostly a PUT results in a 200 OK and the client is satisfied that the PUT succeeded. Can XCAP define what goes in the body: Yes, but as I said below, clients will probably need to be to handle the case where they get a "bare" 200. If they are counting on data in the response body there are cases where they will likely break. (Unstated question: is a response body the right tool here?). No, not in my opinion (NB: no AD hat, just an opinion). One of the key reasons for using PUT and making some of the early changes to XCAP was to keep the functionality as a strict subset of the HTTP functionality. That was a good idea from a spec, code, and deployment perspective. If you return response bodies to a PUT along with the 200 response, you're edging out of that "strict subset" mentality, and the more protocol logic is in the response body the further out you are. It's not impossible, but other design choices may make more sense. regards, Ted >If a body in the 200 is wrong, does that mean the XCAP client needs to follow the PUT with a GET to learn of the XCAP usage resource interdependencies? > >Regards, >Hisham > >> -----Original Message----- >> From: ext Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: 11.December.2003 20:50 >> To: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >> Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request >> >> >> At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: >> >This is not clear in XCAP. I also check RFC2616 to find out >> some sort of answer, but it is not clear there either. >> >> The 200 response doesn't require a response body for HTTP. >> You can define >> a response body appropriate for a specific method (Julian Reschke has >> a webdav-related example in his draft for checkin; a uri for that is: >> http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-comp >> ute-checkin-uri-01.html) >> For PUT, though, you should probably be able to handle >> getting a bare 200 response (see >> section 9.6 of RFC 2616.) >> >> Or am I misunderstanding your question? >> regards, >> Ted Hardie >> >> >> >Should the 200 (or 201 for that matter) contain the contents >> the were PUT? If so, does it include the resource >> interdependencies (like the resource list URI in the list case)? >> > >> >If no, does that mean the client needs to follow the PUT >> with a GET to learn of the resource interdependencies? >> > >> >Thanks, >> >Hisham >> > >> >_______________________________________________ >> >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 exim@www1.ietf.org Fri Dec 12 18:19:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03078 for ; Fri, 12 Dec 2003 18:19:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYw-0006Y8-IK for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 18:19:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCNJ9fr025170 for simple-archive@odin.ietf.org; Fri, 12 Dec 2003 18:19:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYv-0006Xt-CG for simple-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 18:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03034; Fri, 12 Dec 2003 18:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYr-00043J-00; Fri, 12 Dec 2003 18:19:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUwYr-00043E-00; Fri, 12 Dec 2003 18:19:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYo-0006XE-Ax; Fri, 12 Dec 2003 18:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUwYJ-0006Wd-Sq for simple@optimus.ietf.org; Fri, 12 Dec 2003 18:18:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02980 for ; Fri, 12 Dec 2003 18:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYH-00042u-00 for simple@ietf.org; Fri, 12 Dec 2003 18:18:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1AUwYG-00042q-00 for simple@ietf.org; Fri, 12 Dec 2003 18:18:28 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCNIPVY006567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2003 15:18:26 -0800 (PST) Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBCNINU0023475; Fri, 12 Dec 2003 15:18:23 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> To: hisham.khartabil@nokia.com, From: Ted Hardie Subject: RE: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Dec 2003 15:18:22 -0800 At 9:07 AM +0200 12/12/2003, hisham.khartabil@nokia.com wrote: >The real question is: is it wrong to have a body in a HTTP 200 response for a PUT request? If not, can XCAP define what goes in the body? I think the answers are no, no, yes, and no. But that's partly because I think you are missing a few questions. A 200 response can have a body. (Unstated question: is this expected behavior now?) No, not really. Mostly a PUT results in a 200 OK and the client is satisfied that the PUT succeeded. Can XCAP define what goes in the body: Yes, but as I said below, clients will probably need to be to handle the case where they get a "bare" 200. If they are counting on data in the response body there are cases where they will likely break. (Unstated question: is a response body the right tool here?). No, not in my opinion (NB: no AD hat, just an opinion). One of the key reasons for using PUT and making some of the early changes to XCAP was to keep the functionality as a strict subset of the HTTP functionality. That was a good idea from a spec, code, and deployment perspective. If you return response bodies to a PUT along with the 200 response, you're edging out of that "strict subset" mentality, and the more protocol logic is in the response body the further out you are. It's not impossible, but other design choices may make more sense. regards, Ted >If a body in the 200 is wrong, does that mean the XCAP client needs to follow the PUT with a GET to learn of the XCAP usage resource interdependencies? > >Regards, >Hisham > >> -----Original Message----- >> From: ext Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: 11.December.2003 20:50 >> To: Khartabil Hisham (NMP-MSW/Helsinki); simple@ietf.org >> Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request >> >> >> At 11:42 AM +0200 12/11/2003, hisham.khartabil@nokia.com wrote: >> >This is not clear in XCAP. I also check RFC2616 to find out >> some sort of answer, but it is not clear there either. >> >> The 200 response doesn't require a response body for HTTP. >> You can define >> a response body appropriate for a specific method (Julian Reschke has >> a webdav-related example in his draft for checkin; a uri for that is: >> http://www.greenbytes.de/tech/webdav/draft-reschke-deltav-comp >> ute-checkin-uri-01.html) >> For PUT, though, you should probably be able to handle >> getting a bare 200 response (see >> section 9.6 of RFC 2616.) >> >> Or am I misunderstanding your question? >> regards, >> Ted Hardie >> >> >> >Should the 200 (or 201 for that matter) contain the contents >> the were PUT? If so, does it include the resource >> interdependencies (like the resource list URI in the list case)? >> > >> >If no, does that mean the client needs to follow the PUT >> with a GET to learn of the resource interdependencies? >> > >> >Thanks, >> >Hisham >> > >> >_______________________________________________ >> >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-admin@ietf.org Sat Dec 13 02:05:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19973; Sat, 13 Dec 2003 02:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV3pu-0004yQ-00; Sat, 13 Dec 2003 02:05:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AV3pu-0004yM-00; Sat, 13 Dec 2003 02:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3pm-0006np-Oq; Sat, 13 Dec 2003 02:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3oy-0006mn-B5 for simple@optimus.ietf.org; Sat, 13 Dec 2003 02:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18874 for ; Sat, 13 Dec 2003 02:04:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV3ou-0004xG-00 for simple@ietf.org; Sat, 13 Dec 2003 02:04:08 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AV3ou-0004wh-00 for simple@ietf.org; Sat, 13 Dec 2003 02:04:08 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBD739dx000756; Sat, 13 Dec 2003 01:03:26 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Dec 2003 01:03:08 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , xmppwg@jabber.org Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [xmppwg] Action Item: character mappings for interoperability Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Dec 2003 01:02:57 -0600 Content-Transfer-Encoding: quoted-printable I'm cross posting this to SIMPLE to help cross-pollinate some ideas here. Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: [huge snip] > Example: jos=E9#26;b=F3b@jabber.com becomes=20 > im:jos%c3%a9&b%c3%b3b@jabber.com > (note for the MIME-impaired: that's jose' and bo'b) >=20 > Actually, it's not clear to me from RFC 3428 whether I should=20 > map into sip:, sips: or im:; I could use some guidance here > from the SIMPLE folk. Well, they're all (potentially) different namespaces. In particular, there's nothing (other than a possible site-local policy) that would ensure that "im:adam@dynamicsoft.com" would map to the same user as "sip:adam@dynamicsoft.com" -- so, you need to have some mechanism by which a distinction is performed. I'll get to that in a second. By contrast, "sip:adam@dynamicsoft.com" and "sips:adam@dynamicsoft.com" *will* always refer to the same user: Any resource described by a SIP URI can be "upgraded" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely. So, when you get to a gateway that is going from XMPP to SIP, I would posit that selection of "sip:" would be appropriate when SASL isn't being used on the XMPP side, and that "sips:" would be appropriate when it is. Now, for the issue I deferred: when a message arrives for a jid, how do you know what to do with it? Let's imagine that I send an IM (from an XMPP client) to the jid "JHildebrand@jabber.com". If my understanding is correct, this *must* end up being routed to the server indicated by the xmpp-server SRV record for "jabber.com." So... does that server attempt to deliver it to an XMPP account called "JHildebrand@jabber.com"? Does it gateway it to "im:JHildebrand@jabber.com"? Does it gateway it to "sip:JHildebrand@jabber.com"? One answer would be "selection amongst those destinations is going to be based on local configuration at the jabber.com XMPP server, since it 'owns' the jabber.com namespace." And that would work, sort of, and be consistent and simple. But it's a very incomplete solution. On a grander scale, we need to ask: if you are sitting at an XMPP client as "JHildebrand@jabber.com", and want to send an IM to "sip:adam@dynamicsoft.com", how do you do that? Can we assume that "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can we assume that jabber.com is? Should this be able to work if the XMPP to SIMPLE gateway is owned by yet a third domain? I think all three solutions need to be possible. We've already discussed how the first would work; that's easy. The scheme to use in translation is a matter of the destination server configuration, potentially selected on a user-by-user basis. The second would require some indication from your client to your server (the host indicated by the xmpp-client SRV record for jabber.com) that you want to break out to a SIP network. I don't know enough about the formatting of jids to propose something ideal, but I would think that using some sort of locally-configured prefix would provide that sort of indication (e.g. sending an IM to "sip#x3A;adam@dynamicsoft.com" would indicate to your server, by the presence of "sip#x3A;", that it should gateway to "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality instead of finding the XMPP server for dynamicsoft.com). In this case, the proper scheme to use is explicitly indicated by the user. The third case will require using a jid that explicitly routes to the third-party gateway; for example, "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this ugliness would be hidden behind some sort of user interface construct that allows users to configure their default SIMPLE gateway). For this case, the scheme is decided by the gateway itself, and will typically be specific to the protocol mapping provided by that gateway (i.e. a gateway that=20 translates to SIMPLE will always use sip: or sips:, as appropriate). At least, that's my two cents on the topic. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sat Dec 13 02:05:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20441 for ; Sat, 13 Dec 2003 02:05:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3q0-0006pG-1d for simple-archive@odin.ietf.org; Sat, 13 Dec 2003 02:05:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBD75GYR026239 for simple-archive@odin.ietf.org; Sat, 13 Dec 2003 02:05:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3pz-0006p8-FU for simple-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 02:05:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19973; Sat, 13 Dec 2003 02:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV3pu-0004yQ-00; Sat, 13 Dec 2003 02:05:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AV3pu-0004yM-00; Sat, 13 Dec 2003 02:05:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3pm-0006np-Oq; Sat, 13 Dec 2003 02:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV3oy-0006mn-B5 for simple@optimus.ietf.org; Sat, 13 Dec 2003 02:04:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18874 for ; Sat, 13 Dec 2003 02:04:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV3ou-0004xG-00 for simple@ietf.org; Sat, 13 Dec 2003 02:04:08 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AV3ou-0004wh-00 for simple@ietf.org; Sat, 13 Dec 2003 02:04:08 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBD739dx000756; Sat, 13 Dec 2003 01:03:26 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 13 Dec 2003 01:03:08 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , xmppwg@jabber.org Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [xmppwg] Action Item: character mappings for interoperability Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 13 Dec 2003 01:02:57 -0600 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I'm cross posting this to SIMPLE to help cross-pollinate some ideas here. Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: [huge snip] > Example: jos=E9#26;b=F3b@jabber.com becomes=20 > im:jos%c3%a9&b%c3%b3b@jabber.com > (note for the MIME-impaired: that's jose' and bo'b) >=20 > Actually, it's not clear to me from RFC 3428 whether I should=20 > map into sip:, sips: or im:; I could use some guidance here > from the SIMPLE folk. Well, they're all (potentially) different namespaces. In particular, there's nothing (other than a possible site-local policy) that would ensure that "im:adam@dynamicsoft.com" would map to the same user as "sip:adam@dynamicsoft.com" -- so, you need to have some mechanism by which a distinction is performed. I'll get to that in a second. By contrast, "sip:adam@dynamicsoft.com" and "sips:adam@dynamicsoft.com" *will* always refer to the same user: Any resource described by a SIP URI can be "upgraded" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely. So, when you get to a gateway that is going from XMPP to SIP, I would posit that selection of "sip:" would be appropriate when SASL isn't being used on the XMPP side, and that "sips:" would be appropriate when it is. Now, for the issue I deferred: when a message arrives for a jid, how do you know what to do with it? Let's imagine that I send an IM (from an XMPP client) to the jid "JHildebrand@jabber.com". If my understanding is correct, this *must* end up being routed to the server indicated by the xmpp-server SRV record for "jabber.com." So... does that server attempt to deliver it to an XMPP account called "JHildebrand@jabber.com"? Does it gateway it to "im:JHildebrand@jabber.com"? Does it gateway it to "sip:JHildebrand@jabber.com"? One answer would be "selection amongst those destinations is going to be based on local configuration at the jabber.com XMPP server, since it 'owns' the jabber.com namespace." And that would work, sort of, and be consistent and simple. But it's a very incomplete solution. On a grander scale, we need to ask: if you are sitting at an XMPP client as "JHildebrand@jabber.com", and want to send an IM to "sip:adam@dynamicsoft.com", how do you do that? Can we assume that "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can we assume that jabber.com is? Should this be able to work if the XMPP to SIMPLE gateway is owned by yet a third domain? I think all three solutions need to be possible. We've already discussed how the first would work; that's easy. The scheme to use in translation is a matter of the destination server configuration, potentially selected on a user-by-user basis. The second would require some indication from your client to your server (the host indicated by the xmpp-client SRV record for jabber.com) that you want to break out to a SIP network. I don't know enough about the formatting of jids to propose something ideal, but I would think that using some sort of locally-configured prefix would provide that sort of indication (e.g. sending an IM to "sip#x3A;adam@dynamicsoft.com" would indicate to your server, by the presence of "sip#x3A;", that it should gateway to "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality instead of finding the XMPP server for dynamicsoft.com). In this case, the proper scheme to use is explicitly indicated by the user. The third case will require using a jid that explicitly routes to the third-party gateway; for example, "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this ugliness would be hidden behind some sort of user interface construct that allows users to configure their default SIMPLE gateway). For this case, the scheme is decided by the gateway itself, and will typically be specific to the protocol mapping provided by that gateway (i.e. a gateway that=20 translates to SIMPLE will always use sip: or sips:, as appropriate). At least, that's my two cents on the topic. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 10:33:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13856; Mon, 15 Dec 2003 10:33:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuiX-00072g-00; Mon, 15 Dec 2003 10:33:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVuiX-00072a-00; Mon, 15 Dec 2003 10:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuiT-0008At-JM; Mon, 15 Dec 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuhm-0008AL-1Z for simple@optimus.ietf.org; Mon, 15 Dec 2003 10:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13810 for ; Mon, 15 Dec 2003 10:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuhj-000724-00 for simple@ietf.org; Mon, 15 Dec 2003 10:32:15 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AVuhj-00071z-00 for simple@ietf.org; Mon, 15 Dec 2003 10:32:15 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hBFFWDK16170 for ; Mon, 15 Dec 2003 10:32:13 -0500 To: Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: (Ted Hardie's message of "Fri, 12 Dec 2003 15:18:22 -0800") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 10:32:13 -0500 Ted Hardie writes: > One of the key reasons for using PUT and making some of the early > changes to XCAP was to keep the functionality as a strict subset of > the HTTP functionality. That was a good idea from a spec, code, and > deployment perspective. If you return response bodies to a PUT > along with the 200 response, you're edging out of that "strict > subset" mentality, and the more protocol logic is in the response > body the further out you. I don't understand why POST wasn't chosen then; it does not have that problem in that most things expect a body in response to a post. I also think that POST is a better choice because the usual intent (as I understand it) in xcap will be to provide data to be used to modify the object at the URI rather than the entire resource. POST seems to me to be a better match for that given the definitions of the methods in HTTP (taken from draft-gettys-http-v11-spec-rev-00.txt - recently published draft candidate for full Standard status): 9.5 POST The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed by the resource identified by the Request-URI in the Request-Line. 9.6 PUT The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 10:33:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13933 for ; Mon, 15 Dec 2003 10:33:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuib-0008Bg-Ba for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 10:33:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFFX9Tv031471 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 10:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuia-0008BW-Jp for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 10:33:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13856; Mon, 15 Dec 2003 10:33:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuiX-00072g-00; Mon, 15 Dec 2003 10:33:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVuiX-00072a-00; Mon, 15 Dec 2003 10:33:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuiT-0008At-JM; Mon, 15 Dec 2003 10:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVuhm-0008AL-1Z for simple@optimus.ietf.org; Mon, 15 Dec 2003 10:32:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13810 for ; Mon, 15 Dec 2003 10:32:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVuhj-000724-00 for simple@ietf.org; Mon, 15 Dec 2003 10:32:15 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AVuhj-00071z-00 for simple@ietf.org; Mon, 15 Dec 2003 10:32:15 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hBFFWDK16170 for ; Mon, 15 Dec 2003 10:32:13 -0500 To: Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence In-Reply-To: (Ted Hardie's message of "Fri, 12 Dec 2003 15:18:22 -0800") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 10:32:13 -0500 Ted Hardie writes: > One of the key reasons for using PUT and making some of the early > changes to XCAP was to keep the functionality as a strict subset of > the HTTP functionality. That was a good idea from a spec, code, and > deployment perspective. If you return response bodies to a PUT > along with the 200 response, you're edging out of that "strict > subset" mentality, and the more protocol logic is in the response > body the further out you. I don't understand why POST wasn't chosen then; it does not have that problem in that most things expect a body in response to a post. I also think that POST is a better choice because the usual intent (as I understand it) in xcap will be to provide data to be used to modify the object at the URI rather than the entire resource. POST seems to me to be a better match for that given the definitions of the methods in HTTP (taken from draft-gettys-http-v11-spec-rev-00.txt - recently published draft candidate for full Standard status): 9.5 POST The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed by the resource identified by the Request-URI in the Request-Line. 9.6 PUT The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. -- Scott Lawrence Pingtel Corp. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 11:42:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16041; Mon, 15 Dec 2003 11:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvnw-0000Qq-00; Mon, 15 Dec 2003 11:42:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvnw-0000Qn-00; Mon, 15 Dec 2003 11:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvnE-0002uc-V6; Mon, 15 Dec 2003 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvn6-0002uP-Cy for simple@optimus.ietf.org; Mon, 15 Dec 2003 11:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16021 for ; Mon, 15 Dec 2003 11:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvn5-0000Q4-00 for simple@ietf.org; Mon, 15 Dec 2003 11:41:51 -0500 Received: from host76-50.teleware.fi ([193.65.76.50] helo=hkisrv08.tw.fi) by ietf-mx with esmtp (Exim 4.12) id 1AVvn4-0000Px-00 for simple@ietf.org; Mon, 15 Dec 2003 11:41:51 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: SIMPLE implementations Thread-Index: AcPDK7xG8wzO4nTQR2SzpVJoXV5Mcw== From: "Toni Heinonen" To: Content-Transfer-Encoding: quoted-printable Subject: [Simple] SIMPLE implementations Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 18:51:54 +0200 Content-Transfer-Encoding: quoted-printable Hello, I saw a nice listing of general SIP implementations at = http://www.sipcenter.com/vsts/vsts_clientsoft.html. However, I did not = see any free instant messaging clients like ICQ or ms messenger. Can = anyone point me to any PC desktop instant messaging software that uses = SIMPLE or uses a proprietary protocol but is moving to SIMPLE? = Preferably open source, but commercial products would be nice too. Can anyone shed the light on why all the instant messaging clients are = still using their own proprietary protocols instead of SIMPLE? Regards, --=20 Toni Heinonen Teleware Oy toni.heinonen@teleware.fi +358 40 836 1815 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 11:43:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16066 for ; Mon, 15 Dec 2003 11:43:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvny-0002zW-H8 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 11:42:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGgkMh011492 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 11:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvny-0002zH-Am for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:42:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16041; Mon, 15 Dec 2003 11:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvnw-0000Qq-00; Mon, 15 Dec 2003 11:42:44 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvnw-0000Qn-00; Mon, 15 Dec 2003 11:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvnE-0002uc-V6; Mon, 15 Dec 2003 11:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvn6-0002uP-Cy for simple@optimus.ietf.org; Mon, 15 Dec 2003 11:41:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16021 for ; Mon, 15 Dec 2003 11:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvn5-0000Q4-00 for simple@ietf.org; Mon, 15 Dec 2003 11:41:51 -0500 Received: from host76-50.teleware.fi ([193.65.76.50] helo=hkisrv08.tw.fi) by ietf-mx with esmtp (Exim 4.12) id 1AVvn4-0000Px-00 for simple@ietf.org; Mon, 15 Dec 2003 11:41:51 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: SIMPLE implementations Thread-Index: AcPDK7xG8wzO4nTQR2SzpVJoXV5Mcw== From: "Toni Heinonen" To: Content-Transfer-Encoding: quoted-printable Subject: [Simple] SIMPLE implementations Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 18:51:54 +0200 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, I saw a nice listing of general SIP implementations at = http://www.sipcenter.com/vsts/vsts_clientsoft.html. However, I did not = see any free instant messaging clients like ICQ or ms messenger. Can = anyone point me to any PC desktop instant messaging software that uses = SIMPLE or uses a proprietary protocol but is moving to SIMPLE? = Preferably open source, but commercial products would be nice too. Can anyone shed the light on why all the instant messaging clients are = still using their own proprietary protocols instead of SIMPLE? Regards, --=20 Toni Heinonen Teleware Oy toni.heinonen@teleware.fi +358 40 836 1815 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 16:12:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00059 for ; Mon, 15 Dec 2003 16:12:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW00d-0000qE-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW00c-0000q7-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:12:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW00c-0000q2-00; Mon, 15 Dec 2003 16:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00X-0007We-6f; Mon, 15 Dec 2003 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00T-0007WR-8x for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00040 for ; Mon, 15 Dec 2003 16:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW00R-0000pz-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW00Q-0000ps-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AW00P-0000pX-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:53 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBFLBHmR002218; Mon, 15 Dec 2003 16:11:21 -0500 (EST) Message-ID: <3FDE236E.5070800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:11:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Scott Lawrence wrote: > Ted Hardie writes: > > >>One of the key reasons for using PUT and making some of the early >>changes to XCAP was to keep the functionality as a strict subset of >>the HTTP functionality. That was a good idea from a spec, code, and >>deployment perspective. If you return response bodies to a PUT >>along with the 200 response, you're edging out of that "strict >>subset" mentality, and the more protocol logic is in the response >>body the further out you. > > > I don't understand why POST wasn't chosen then; it does not have that > problem in that most things expect a body in response to a post. Sure; but this is not a case where the resouce represented by the r-uri is meant to process the content. Rather, the content really is meant to be placed on the server at the designated URI. The fact that, in many cases, the placement occurs in the middle of an XML document, seems irrelevant to me. > > I also think that POST is a better choice because the usual intent (as > I understand it) in xcap will be to provide data to be used to modify > the object at the URI rather than the entire resource. See above; it depends on your interpretation of resource. In our interpretation, the URI points to snipits of XML documents that, when put together, form the whole document. The original version of this spec had POST *and* PUT; one was used for insert, the other for modify. There was strong pushback that using POST was a sure sign that this was an abuse of http, since you could really build any protocol through POST. Ted wrote: > That was a good idea from a spec, code, and deployment perspective. If you return response > bodies to a PUT along with the 200 response, you're edging out of that "strict subset" > mentality, and the more protocol logic is in the response body the further out you > are. It's not impossible, but other design choices may make more sense. This was my thought as well. I did not think that the PUT returned the current content in the body. So, if you create a list, and the server needs to provide the list URI, you will need to PUT then GET the list to learn the URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 16:12:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00092 for ; Mon, 15 Dec 2003 16:12:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00g-0007Yb-QL for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:12:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFLCAdg029043 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:12:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00g-0007YL-5N for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 16:12:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00076 for ; Mon, 15 Dec 2003 16:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW00e-0000qP-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:12:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW00d-0000qI-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:12:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW00c-0000q2-00; Mon, 15 Dec 2003 16:12:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00X-0007We-6f; Mon, 15 Dec 2003 16:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW00T-0007WR-8x for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:11:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00040 for ; Mon, 15 Dec 2003 16:11:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW00R-0000pz-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW00Q-0000ps-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AW00P-0000pX-00 for simple@ietf.org; Mon, 15 Dec 2003 16:11:53 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBFLBHmR002218; Mon, 15 Dec 2003 16:11:21 -0500 (EST) Message-ID: <3FDE236E.5070800@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: simple@ietf.org Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:11:10 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Scott Lawrence wrote: > Ted Hardie writes: > > >>One of the key reasons for using PUT and making some of the early >>changes to XCAP was to keep the functionality as a strict subset of >>the HTTP functionality. That was a good idea from a spec, code, and >>deployment perspective. If you return response bodies to a PUT >>along with the 200 response, you're edging out of that "strict >>subset" mentality, and the more protocol logic is in the response >>body the further out you. > > > I don't understand why POST wasn't chosen then; it does not have that > problem in that most things expect a body in response to a post. Sure; but this is not a case where the resouce represented by the r-uri is meant to process the content. Rather, the content really is meant to be placed on the server at the designated URI. The fact that, in many cases, the placement occurs in the middle of an XML document, seems irrelevant to me. > > I also think that POST is a better choice because the usual intent (as > I understand it) in xcap will be to provide data to be used to modify > the object at the URI rather than the entire resource. See above; it depends on your interpretation of resource. In our interpretation, the URI points to snipits of XML documents that, when put together, form the whole document. The original version of this spec had POST *and* PUT; one was used for insert, the other for modify. There was strong pushback that using POST was a sure sign that this was an abuse of http, since you could really build any protocol through POST. Ted wrote: > That was a good idea from a spec, code, and deployment perspective. If you return response > bodies to a PUT along with the 200 response, you're edging out of that "strict subset" > mentality, and the more protocol logic is in the response body the further out you > are. It's not impossible, but other design choices may make more sense. This was my thought as well. I did not think that the PUT returned the current content in the body. So, if you create a list, and the server needs to provide the list URI, you will need to PUT then GET the list to learn the URI. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 16:21:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00534 for ; Mon, 15 Dec 2003 16:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW09I-0001Eh-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:21:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW09H-0001Ea-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW09H-0001EX-00; Mon, 15 Dec 2003 16:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW09G-0007lL-2E; Mon, 15 Dec 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW08w-0007ku-9J for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00528 for ; Mon, 15 Dec 2003 16:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW08u-0001EF-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW08t-0001E8-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:40 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW08t-0001E5-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFLKTnG032488 for ; Mon, 15 Dec 2003 15:20:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE2594.9010709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Some thoughts on session updates Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 15:20:20 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit We have had a lot of discussion on how we deal with connection failures, session continuance across a failure, duplicate supression, etc. Much of that depends on how we handle session updates. Here are some thoughts for discussion. Although the sense of the room at IETF58 indicated we needed a way to re-establish TCP connections without resignaling, subsequent list discussion has indicated consensus that this will not work, and we will indeed have to re-signal. I am slightly concerned that many of those who favored reconnection without resignaling at the meeting have not participated in the email thread. I must assume that means they agree ;-) Obviously resignaling means a new SDP exchange. For SIP, that would mean a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks about sip, I think the re-INVITE vs UPDATE question is out of scope, and is treated sufficiently well in the UPDATE rfc. So, here are some assumptions and observations about how an updated offer/answer would work. 0) We don't have to worry about early media. (I expect this to be controversial, but I can always hope. The following are based on that assumption.) 1) The active party must remain the active party. If the active party initiates an updated offer, it MUST NOT contain a session URL. 2) The passive party must remain the passive party. If the passive party initates an updated offer, it MUST contain a session URL. This updated URL may be the same as before, or may be completely different, even pointing to a completely different location. 3)If the passive party sends an updated offer with a semantically identical URL as the original, this indicates no change. (I don't know why you would do this, but Paul asked for an example of an update that changes nothing.) Interestingly, the active party _cannot_ send an updated without giving the active party a chance to provide a new session URL. 4) A corrolary of 1) and 2) is that direction=both would not be permitted for an update. 5) Updated offers can occur for both healthy sessions and as a result of connection failures, etc. Thoughts? Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 16:21:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00555 for ; Mon, 15 Dec 2003 16:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW09M-0007na-02 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFLL7tc029972 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:21:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW09L-0007nL-R6 for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 16:21:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00552 for ; Mon, 15 Dec 2003 16:21:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW09K-0001Es-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:21:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW09J-0001El-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:21:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW09H-0001EX-00; Mon, 15 Dec 2003 16:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW09G-0007lL-2E; Mon, 15 Dec 2003 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW08w-0007ku-9J for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:20:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00528 for ; Mon, 15 Dec 2003 16:20:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW08u-0001EF-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW08t-0001E8-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:40 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW08t-0001E5-00 for simple@ietf.org; Mon, 15 Dec 2003 16:20:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFLKTnG032488 for ; Mon, 15 Dec 2003 15:20:33 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE2594.9010709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simple WG X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] MSRP: Some thoughts on session updates Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 15:20:20 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We have had a lot of discussion on how we deal with connection failures, session continuance across a failure, duplicate supression, etc. Much of that depends on how we handle session updates. Here are some thoughts for discussion. Although the sense of the room at IETF58 indicated we needed a way to re-establish TCP connections without resignaling, subsequent list discussion has indicated consensus that this will not work, and we will indeed have to re-signal. I am slightly concerned that many of those who favored reconnection without resignaling at the meeting have not participated in the email thread. I must assume that means they agree ;-) Obviously resignaling means a new SDP exchange. For SIP, that would mean a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks about sip, I think the re-INVITE vs UPDATE question is out of scope, and is treated sufficiently well in the UPDATE rfc. So, here are some assumptions and observations about how an updated offer/answer would work. 0) We don't have to worry about early media. (I expect this to be controversial, but I can always hope. The following are based on that assumption.) 1) The active party must remain the active party. If the active party initiates an updated offer, it MUST NOT contain a session URL. 2) The passive party must remain the passive party. If the passive party initates an updated offer, it MUST contain a session URL. This updated URL may be the same as before, or may be completely different, even pointing to a completely different location. 3)If the passive party sends an updated offer with a semantically identical URL as the original, this indicates no change. (I don't know why you would do this, but Paul asked for an example of an update that changes nothing.) Interestingly, the active party _cannot_ send an updated without giving the active party a chance to provide a new session URL. 4) A corrolary of 1) and 2) is that direction=both would not be permitted for an update. 5) Updated offers can occur for both healthy sessions and as a result of connection failures, etc. Thoughts? Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 16:35:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01603 for ; Mon, 15 Dec 2003 16:35:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Ms-000206-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:35:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0Mr-0001zz-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW0Mr-0001zw-00; Mon, 15 Dec 2003 16:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Mn-00004w-PM; Mon, 15 Dec 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Lx-0008Up-RY for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:34:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01559 for ; Mon, 15 Dec 2003 16:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Lv-0001xr-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0Lv-0001xk-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Lu-0001xh-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:06 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBFLY44t022507; Mon, 15 Dec 2003 13:34:04 -0800 (PST) Received: from [129.46.75.150] (carbuncle.qualcomm.com [129.46.75.150]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBFLY2U0017101; Mon, 15 Dec 2003 13:34:03 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> To: Scott Lawrence , From: Ted Hardie Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 13:34:01 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Scott, At 10:32 AM -0500 12/15/2003, Scott Lawrence wrote: >I also think that POST is a better choice because the usual intent (as >I understand it) in xcap will be to provide data to be used to modify >the object at the URI rather than the entire resource. POST seems to >me to be a better match for that given the definitions of the methods >in HTTP (taken from draft-gettys-http-v11-spec-rev-00.txt - recently >published draft candidate for full Standard status): The difficulty here was the usual difficulty with POST--the semantics of the operation that occurs once the server has accepted the entity are outside the bounds of HTTP. You can layer another protocol on top of POST and return its protocol semantics in the body, but doing so means you can't really take advantage of existing clients. The clients have to *at least* understand how to parse the returned bodies to extract failure conditions and react accordingly. By using a structured view of the resources, on the other hand, you can use PUT in a way that consonant with the base HTTP semantics. A secondary advantage is that building it on top of PUT means you may be able to move toward DAV over time without having to later reconcile the POST-based protocol semantics with the DAV HTTP-based protocol semantics. regards, Ted HArdie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 16:35:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01652 for ; Mon, 15 Dec 2003 16:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Mw-00006C-1H for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFLZ9NF000377 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:35:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Mv-000060-QM for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 16:35:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01619 for ; Mon, 15 Dec 2003 16:35:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Mt-00020H-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:35:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0Ms-00020A-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:35:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW0Mr-0001zw-00; Mon, 15 Dec 2003 16:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Mn-00004w-PM; Mon, 15 Dec 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0Lx-0008Up-RY for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:34:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01559 for ; Mon, 15 Dec 2003 16:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Lv-0001xr-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0Lv-0001xk-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1AW0Lu-0001xh-00 for simple@ietf.org; Mon, 15 Dec 2003 16:34:06 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBFLY44t022507; Mon, 15 Dec 2003 13:34:04 -0800 (PST) Received: from [129.46.75.150] (carbuncle.qualcomm.com [129.46.75.150]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hBFLY2U0017101; Mon, 15 Dec 2003 13:34:03 -0800 (PST) Mime-Version: 1.0 X-Sender: hardie@mage.qualcomm.com Message-Id: In-Reply-To: References: <2038BCC78B1AD641891A0D1AE133DBB70118B139@esebe019.ntc.nokia.com> To: Scott Lawrence , From: Ted Hardie Subject: Re: [Simple] XCAP: what does in the 200 of a PUT request Content-Type: text/plain; charset="us-ascii" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 13:34:01 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Scott, At 10:32 AM -0500 12/15/2003, Scott Lawrence wrote: >I also think that POST is a better choice because the usual intent (as >I understand it) in xcap will be to provide data to be used to modify >the object at the URI rather than the entire resource. POST seems to >me to be a better match for that given the definitions of the methods >in HTTP (taken from draft-gettys-http-v11-spec-rev-00.txt - recently >published draft candidate for full Standard status): The difficulty here was the usual difficulty with POST--the semantics of the operation that occurs once the server has accepted the entity are outside the bounds of HTTP. You can layer another protocol on top of POST and return its protocol semantics in the body, but doing so means you can't really take advantage of existing clients. The clients have to *at least* understand how to parse the returned bodies to extract failure conditions and react accordingly. By using a structured view of the resources, on the other hand, you can use PUT in a way that consonant with the base HTTP semantics. A secondary advantage is that building it on top of PUT means you may be able to move toward DAV over time without having to later reconcile the POST-based protocol semantics with the DAV HTTP-based protocol semantics. regards, Ted HArdie _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 16:53:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02279 for ; Mon, 15 Dec 2003 16:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0eI-0002hI-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0eH-0002hB-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 16:53:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW0eH-0002h8-00; Mon, 15 Dec 2003 16:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0eD-0000lJ-Vs; Mon, 15 Dec 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0di-0000l3-0c for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:52:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02214 for ; Mon, 15 Dec 2003 16:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0df-0002gb-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0dd-0002gL-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW0dd-0002gI-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFLqAnG036018; Mon, 15 Dec 2003 15:52:16 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE2D00.8000301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] Action Item: character mappings for interoperability References: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id hBFLqAnG036018 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 15:52:00 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Is the context of this thread IM only, or do we also care about=20 presence? I am not sure the issues are always exactly the same, since IM=20 addresses may be delivered as part of presence. I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here.=20 Also, if I recall we _do_ have guidance on how to map an im: url to a=20 concrete service using SRV, don't we? It seems to me that if I am a SIP=20 user, the only real hope I have of cross-protocol interoperability is to=20 advertise a PRES or IM URI. Other systems may be able to reach SIP URIs=20 on an ad-hoc basis, but the abstract schema provide a more general=20 approach. More inline: Adam Roach wrote: > I'm cross posting this to SIMPLE to help cross-pollinate some > ideas here. >=20 > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: >=20 > [huge snip] >=20 >=20 >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 >>im:jos%c3%a9&b%c3%b3b@jabber.com >>(note for the MIME-impaired: that's jose' and bo'b) >> >>Actually, it's not clear to me from RFC 3428 whether I should=20 >>map into sip:, sips: or im:; I could use some guidance here >>from the SIMPLE folk. >=20 >=20 > Well, they're all (potentially) different namespaces. In particular, > there's nothing (other than a possible site-local policy) that would > ensure that "im:adam@dynamicsoft.com" would map to the same user as > "sip:adam@dynamicsoft.com" -- so, you need to have some mechanism > by which a distinction is performed. I'll get to that in a second. >=20 > By contrast, "sip:adam@dynamicsoft.com" and > "sips:adam@dynamicsoft.com" *will* always refer to the same > user: >=20 > Any resource described by a SIP URI can be > "upgraded" to a SIPS URI by just changing the scheme, if it is > desired to communicate with that resource securely. >=20 > So, when you get to a gateway that is going from XMPP to SIP, > I would posit that selection of "sip:" would be appropriate > when SASL isn't being used on the XMPP side, and that "sips:" > would be appropriate when it is. >=20 > Now, for the issue I deferred: when a message arrives for a > jid, how do you know what to do with it? Let's imagine that I > send an IM (from an XMPP client) to the jid > "JHildebrand@jabber.com". If my understanding is correct, > this *must* end up being routed to the server indicated by > the xmpp-server SRV record for "jabber.com." So... does that > server attempt to deliver it to an XMPP account called > "JHildebrand@jabber.com"? Does it gateway it to > "im:JHildebrand@jabber.com"? Does it gateway it to > "sip:JHildebrand@jabber.com"? >=20 > One answer would be "selection amongst those destinations > is going to be based on local configuration at the jabber.com > XMPP server, since it 'owns' the jabber.com namespace." And > that would work, sort of, and be consistent and simple. >=20 > But it's a very incomplete solution. >=20 > On a grander scale, we need to ask: if you are sitting at an > XMPP client as "JHildebrand@jabber.com", and want to send an IM > to "sip:adam@dynamicsoft.com", how do you do that? Can we assume > that "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can > we assume that jabber.com is? Should this be able to work if > the XMPP to SIMPLE gateway is owned by yet a third domain? >=20 > I think all three solutions need to be possible. >=20 > We've already discussed how the first would work; that's easy. > The scheme to use in translation is a matter of the destination > server configuration, potentially selected on a user-by-user > basis. I'm not sure I agree on this. As you mention above, even if=20 dynamicsoft.com maintains an xmpp to simple gateway, there is no reason=20 to expect that you can infer an identifier that makes sense to the xmpp=20 side of the gateway from a SIP URI. If dynamicsoft maintains such a=20 gateway, then it would make more sense to advertise an xmpp identity in=20 addition to the SIP identity, or perhaps an im: URI for both. It seems to me that an xmpp device, presented with a SIP URI, can do=20 nothing intelligent with it beyond submitting it to some xmpp-sip=20 gateway that it _already_ knows about, and it cannot use the SIP URI to=20 discover that gateway. >=20 > The second would require some indication from your client to your > server (the host indicated by the xmpp-client SRV record for > jabber.com) that you want to break out to a SIP network. > I don't know enough about the formatting of jids to propose something > ideal, but I would think that using some sort of locally-configured > prefix would provide that sort of indication (e.g. sending > an IM to "sip#x3A;adam@dynamicsoft.com" would indicate to your > server, by the presence of "sip#x3A;", that it should gateway > to "sip:adam@dynamicsoft.com" using its SIMPLE gateway > functionality instead of finding the XMPP server for > dynamicsoft.com). In this case, the proper scheme to use is > explicitly indicated by the user. >=20 > The third case will require using a jid that explicitly routes > to the third-party gateway; for example, > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this > ugliness would be hidden behind some sort of user interface > construct that allows users to configure their default SIMPLE > gateway). For this case, the scheme is decided by the gateway > itself, and will typically be specific to the protocol > mapping provided by that gateway (i.e. a gateway that=20 > translates to SIMPLE will always use sip: or sips:, as > appropriate). >=20 > At least, that's my two cents on the topic. >=20 > /a >=20 > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 15 16:53:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02307 for ; Mon, 15 Dec 2003 16:53:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0eN-0000nD-K3 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:53:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFLrBfM003041 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 16:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0eM-0000mx-OJ for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 16:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02297 for ; Mon, 15 Dec 2003 16:53:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0eK-0002hT-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:53:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0eJ-0002hM-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 16:53:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW0eH-0002h8-00; Mon, 15 Dec 2003 16:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0eD-0000lJ-Vs; Mon, 15 Dec 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW0di-0000l3-0c for simple@optimus.ietf.org; Mon, 15 Dec 2003 16:52:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02214 for ; Mon, 15 Dec 2003 16:52:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW0df-0002gb-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW0dd-0002gL-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:27 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW0dd-0002gI-00 for simple@ietf.org; Mon, 15 Dec 2003 16:52:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFLqAnG036018; Mon, 15 Dec 2003 15:52:16 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE2D00.8000301@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] Action Item: character mappings for interoperability References: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E866E1@dyn-tx-exch-001.dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by magus.nostrum.com id hBFLqAnG036018 Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 15:52:00 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Is the context of this thread IM only, or do we also care about=20 presence? I am not sure the issues are always exactly the same, since IM=20 addresses may be delivered as part of presence. I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here.=20 Also, if I recall we _do_ have guidance on how to map an im: url to a=20 concrete service using SRV, don't we? It seems to me that if I am a SIP=20 user, the only real hope I have of cross-protocol interoperability is to=20 advertise a PRES or IM URI. Other systems may be able to reach SIP URIs=20 on an ad-hoc basis, but the abstract schema provide a more general=20 approach. More inline: Adam Roach wrote: > I'm cross posting this to SIMPLE to help cross-pollinate some > ideas here. >=20 > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: >=20 > [huge snip] >=20 >=20 >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 >>im:jos%c3%a9&b%c3%b3b@jabber.com >>(note for the MIME-impaired: that's jose' and bo'b) >> >>Actually, it's not clear to me from RFC 3428 whether I should=20 >>map into sip:, sips: or im:; I could use some guidance here >>from the SIMPLE folk. >=20 >=20 > Well, they're all (potentially) different namespaces. In particular, > there's nothing (other than a possible site-local policy) that would > ensure that "im:adam@dynamicsoft.com" would map to the same user as > "sip:adam@dynamicsoft.com" -- so, you need to have some mechanism > by which a distinction is performed. I'll get to that in a second. >=20 > By contrast, "sip:adam@dynamicsoft.com" and > "sips:adam@dynamicsoft.com" *will* always refer to the same > user: >=20 > Any resource described by a SIP URI can be > "upgraded" to a SIPS URI by just changing the scheme, if it is > desired to communicate with that resource securely. >=20 > So, when you get to a gateway that is going from XMPP to SIP, > I would posit that selection of "sip:" would be appropriate > when SASL isn't being used on the XMPP side, and that "sips:" > would be appropriate when it is. >=20 > Now, for the issue I deferred: when a message arrives for a > jid, how do you know what to do with it? Let's imagine that I > send an IM (from an XMPP client) to the jid > "JHildebrand@jabber.com". If my understanding is correct, > this *must* end up being routed to the server indicated by > the xmpp-server SRV record for "jabber.com." So... does that > server attempt to deliver it to an XMPP account called > "JHildebrand@jabber.com"? Does it gateway it to > "im:JHildebrand@jabber.com"? Does it gateway it to > "sip:JHildebrand@jabber.com"? >=20 > One answer would be "selection amongst those destinations > is going to be based on local configuration at the jabber.com > XMPP server, since it 'owns' the jabber.com namespace." And > that would work, sort of, and be consistent and simple. >=20 > But it's a very incomplete solution. >=20 > On a grander scale, we need to ask: if you are sitting at an > XMPP client as "JHildebrand@jabber.com", and want to send an IM > to "sip:adam@dynamicsoft.com", how do you do that? Can we assume > that "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can > we assume that jabber.com is? Should this be able to work if > the XMPP to SIMPLE gateway is owned by yet a third domain? >=20 > I think all three solutions need to be possible. >=20 > We've already discussed how the first would work; that's easy. > The scheme to use in translation is a matter of the destination > server configuration, potentially selected on a user-by-user > basis. I'm not sure I agree on this. As you mention above, even if=20 dynamicsoft.com maintains an xmpp to simple gateway, there is no reason=20 to expect that you can infer an identifier that makes sense to the xmpp=20 side of the gateway from a SIP URI. If dynamicsoft maintains such a=20 gateway, then it would make more sense to advertise an xmpp identity in=20 addition to the SIP identity, or perhaps an im: URI for both. It seems to me that an xmpp device, presented with a SIP URI, can do=20 nothing intelligent with it beyond submitting it to some xmpp-sip=20 gateway that it _already_ knows about, and it cannot use the SIP URI to=20 discover that gateway. >=20 > The second would require some indication from your client to your > server (the host indicated by the xmpp-client SRV record for > jabber.com) that you want to break out to a SIP network. > I don't know enough about the formatting of jids to propose something > ideal, but I would think that using some sort of locally-configured > prefix would provide that sort of indication (e.g. sending > an IM to "sip#x3A;adam@dynamicsoft.com" would indicate to your > server, by the presence of "sip#x3A;", that it should gateway > to "sip:adam@dynamicsoft.com" using its SIMPLE gateway > functionality instead of finding the XMPP server for > dynamicsoft.com). In this case, the proper scheme to use is > explicitly indicated by the user. >=20 > The third case will require using a jid that explicitly routes > to the third-party gateway; for example, > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this > ugliness would be hidden behind some sort of user interface > construct that allows users to configure their default SIMPLE > gateway). For this case, the scheme is decided by the gateway > itself, and will typically be specific to the protocol > mapping provided by that gateway (i.e. a gateway that=20 > translates to SIMPLE will always use sip: or sips:, as > appropriate). >=20 > At least, that's my two cents on the topic. >=20 > /a >=20 > _______________________________________________ > 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-admin@ietf.org Mon Dec 15 17:29:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03408 for ; Mon, 15 Dec 2003 17:29:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1DA-0003tP-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:29:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1D9-0003tI-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:29:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1D9-0003tF-00; Mon, 15 Dec 2003 17:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1D3-0002Wn-Vy; Mon, 15 Dec 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1Cr-0002WZ-4Q for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:28:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03402 for ; Mon, 15 Dec 2003 17:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1Co-0003sz-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1Cn-0003ss-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:46 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AW1Ci-0003pG-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:40 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBFMS9dx009782; Mon, 15 Dec 2003 16:28:09 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:28:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866EE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:28:07 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Ben Campbell [mailto:bcampbell@dynamicsoft.com] wrote: > > We've already discussed how the first would work; that's easy. > > The scheme to use in translation is a matter of the destination > > server configuration, potentially selected on a user-by-user > > basis. > > I'm not sure I agree on this. As you mention above, even if > dynamicsoft.com maintains an xmpp to simple gateway, there is > no reason to expect that you can infer an identifier that makes > sense to the xmpp side of the gateway from a SIP URI. If > dynamicsoft maintains such a gateway, then it would make more > sense to advertise an xmpp identity in addition to the SIP > identity... That was what I was assuming, and what I meant by the mapping being at the gateway's discretion (because it "owns" the namespace). For example, such a gateway could certainly decide to translate the JID "ben@dynamicsoft.com" to "sip:bcampbell@dynamicsoft.com" if it so chose. The objection you're raising -- that you couldn't then pass out a single identifier -- is one reason I called it an incomplete solution. (The other objection is that it *requires* the destination domain to run an XMPP server in order to work). I described this model primarily because it was the *only* model that was supported by Joe's proposed mappings. The larger point I was trying to raise is that you can't really come up with a syntactic mapping from JIDs to external systems unless you have a context in which to evaluate the mapping. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 17:29:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03443 for ; Mon, 15 Dec 2003 17:29:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1DE-0002b3-1f for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMTCd1009979 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:29:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1DD-0002as-OQ for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 17:29:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03424 for ; Mon, 15 Dec 2003 17:29:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1DB-0003ta-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:29:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1DA-0003tT-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:29:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1D9-0003tF-00; Mon, 15 Dec 2003 17:29:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1D3-0002Wn-Vy; Mon, 15 Dec 2003 17:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1Cr-0002WZ-4Q for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:28:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03402 for ; Mon, 15 Dec 2003 17:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1Co-0003sz-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1Cn-0003ss-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:46 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AW1Ci-0003pG-00 for simple@ietf.org; Mon, 15 Dec 2003 17:28:40 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBFMS9dx009782; Mon, 15 Dec 2003 16:28:09 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:28:09 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866EE@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:28:07 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Ben Campbell [mailto:bcampbell@dynamicsoft.com] wrote: > > We've already discussed how the first would work; that's easy. > > The scheme to use in translation is a matter of the destination > > server configuration, potentially selected on a user-by-user > > basis. > > I'm not sure I agree on this. As you mention above, even if > dynamicsoft.com maintains an xmpp to simple gateway, there is > no reason to expect that you can infer an identifier that makes > sense to the xmpp side of the gateway from a SIP URI. If > dynamicsoft maintains such a gateway, then it would make more > sense to advertise an xmpp identity in addition to the SIP > identity... That was what I was assuming, and what I meant by the mapping being at the gateway's discretion (because it "owns" the namespace). For example, such a gateway could certainly decide to translate the JID "ben@dynamicsoft.com" to "sip:bcampbell@dynamicsoft.com" if it so chose. The objection you're raising -- that you couldn't then pass out a single identifier -- is one reason I called it an incomplete solution. (The other objection is that it *requires* the destination domain to run an XMPP server in order to work). I described this model primarily because it was the *only* model that was supported by Joe's proposed mappings. The larger point I was trying to raise is that you can't really come up with a syntactic mapping from JIDs to external systems unless you have a context in which to evaluate the mapping. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 17:50:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03795 for ; Mon, 15 Dec 2003 17:50:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1XU-0004Lw-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:50:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1XT-0004Lp-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:50:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1XT-0004Lm-00; Mon, 15 Dec 2003 17:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1XO-00038f-RF; Mon, 15 Dec 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1WQ-00037V-31 for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03768 for ; Mon, 15 Dec 2003 17:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1WN-0004JU-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1WM-0004JN-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:59 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AW1WM-0004JK-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:58 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBFMmKdx009816; Mon, 15 Dec 2003 16:48:20 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:48:20 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866EF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:48:13 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Ben Campbell wrote: > I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here. It's part of the solution space, but only one of the three configurations I mentioned. It's more elegant than what I described, but it is still a solution to the easy part of the problem -- that is, the cast in which the destination determines how translation occurs. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 17:50:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03823 for ; Mon, 15 Dec 2003 17:50:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1XY-00039Z-Al for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:50:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMoCob012115 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1XY-00039K-64 for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 17:50:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03811 for ; Mon, 15 Dec 2003 17:50:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1XV-0004M7-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:50:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1XU-0004M0-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:50:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1XT-0004Lm-00; Mon, 15 Dec 2003 17:50:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1XO-00038f-RF; Mon, 15 Dec 2003 17:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1WQ-00037V-31 for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:49:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03768 for ; Mon, 15 Dec 2003 17:48:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1WN-0004JU-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1WM-0004JN-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:59 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AW1WM-0004JK-00 for simple@ietf.org; Mon, 15 Dec 2003 17:48:58 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBFMmKdx009816; Mon, 15 Dec 2003 16:48:20 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:48:20 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866EF@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: Ben Campbell , Adam Roach Cc: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:48:13 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Ben Campbell wrote: > I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here. It's part of the solution space, but only one of the three configurations I mentioned. It's more elegant than what I described, but it is still a solution to the easy part of the problem -- that is, the cast in which the destination determines how translation occurs. /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 17:55:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03978 for ; Mon, 15 Dec 2003 17:55:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1cF-0004Wh-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:55:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1cE-0004Wa-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1cE-0004WX-00; Mon, 15 Dec 2003 17:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1cF-0003Ik-5a; Mon, 15 Dec 2003 17:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1bK-0003Hi-Ee for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:54:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03954 for ; Mon, 15 Dec 2003 17:54:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1bH-0004Uk-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1bE-0004UI-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AW1bE-0004TX-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2003 14:56:22 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBFMrSBN019297; Mon, 15 Dec 2003 14:53:28 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER44453; Mon, 15 Dec 2003 17:53:27 -0500 (EST) Message-ID: <3FDE3B66.1040500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <3FDE2594.9010709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 17:53:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben, I agree with what you propose. One clarification below. Paul Ben Campbell wrote: > We have had a lot of discussion on how we deal with connection failures, > session continuance across a failure, duplicate supression, etc. Much of > that depends on how we handle session updates. Here are some thoughts > for discussion. > > Although the sense of the room at IETF58 indicated we needed a way to > re-establish TCP connections without resignaling, subsequent list > discussion has indicated consensus that this will not work, and we will > indeed have to re-signal. I am slightly concerned that many of those who > favored reconnection without resignaling at the meeting have not > participated in the email thread. I must assume that means they agree ;-) > > Obviously resignaling means a new SDP exchange. For SIP, that would mean > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks > about sip, I think the re-INVITE vs UPDATE question is out of scope, and > is treated sufficiently well in the UPDATE rfc. > > So, here are some assumptions and observations about how an updated > offer/answer would work. > > 0) We don't have to worry about early media. (I expect this to be > controversial, but I can always hope. The following are based on that > assumption.) > > 1) The active party must remain the active party. If the active party > initiates an updated offer, it MUST NOT contain a session URL. > > 2) The passive party must remain the passive party. If the passive party > initates an updated offer, it MUST contain a session URL. This updated > URL may be the same as before, or may be completely different, even > pointing to a completely different location. > > 3)If the passive party sends an updated offer with a semantically > identical URL as the original, this indicates no change. (I don't know > why you would do this, but Paul asked for an example of an update that > changes nothing.) There are at least two use cases for this: - the session has session timer active. At some point it is necessary to send a reinvite to honor this. It has to have some offer, but there is no intent to change anything. - the session has multiple media - MSRP plus something else, say voice. There is a desire to change some attribute of the voice stream, but not of the MSRP stream. > Interestingly, the active party _cannot_ send an > updated without giving the active party a chance to provide a new > session URL. > > 4) A corrolary of 1) and 2) is that direction=both would not be > permitted for an update. > > 5) Updated offers can occur for both healthy sessions and as a result of > connection failures, etc. > > Thoughts? > > Ben. > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 15 17:55:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04002 for ; Mon, 15 Dec 2003 17:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1cJ-0003Kg-Bx for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:55:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMt7lI012804 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1cJ-0003KR-7B for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 17:55:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03994 for ; Mon, 15 Dec 2003 17:55:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1cG-0004Ws-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:55:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1cF-0004Wl-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:55:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1cE-0004WX-00; Mon, 15 Dec 2003 17:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1cF-0003Ik-5a; Mon, 15 Dec 2003 17:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1bK-0003Hi-Ee for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:54:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03954 for ; Mon, 15 Dec 2003 17:54:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1bH-0004Uk-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1bE-0004UI-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:03 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AW1bE-0004TX-00 for simple@ietf.org; Mon, 15 Dec 2003 17:54:00 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Dec 2003 14:56:22 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBFMrSBN019297; Mon, 15 Dec 2003 14:53:28 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER44453; Mon, 15 Dec 2003 17:53:27 -0500 (EST) Message-ID: <3FDE3B66.1040500@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Simple WG Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <3FDE2594.9010709@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 17:53:26 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben, I agree with what you propose. One clarification below. Paul Ben Campbell wrote: > We have had a lot of discussion on how we deal with connection failures, > session continuance across a failure, duplicate supression, etc. Much of > that depends on how we handle session updates. Here are some thoughts > for discussion. > > Although the sense of the room at IETF58 indicated we needed a way to > re-establish TCP connections without resignaling, subsequent list > discussion has indicated consensus that this will not work, and we will > indeed have to re-signal. I am slightly concerned that many of those who > favored reconnection without resignaling at the meeting have not > participated in the email thread. I must assume that means they agree ;-) > > Obviously resignaling means a new SDP exchange. For SIP, that would mean > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks > about sip, I think the re-INVITE vs UPDATE question is out of scope, and > is treated sufficiently well in the UPDATE rfc. > > So, here are some assumptions and observations about how an updated > offer/answer would work. > > 0) We don't have to worry about early media. (I expect this to be > controversial, but I can always hope. The following are based on that > assumption.) > > 1) The active party must remain the active party. If the active party > initiates an updated offer, it MUST NOT contain a session URL. > > 2) The passive party must remain the passive party. If the passive party > initates an updated offer, it MUST contain a session URL. This updated > URL may be the same as before, or may be completely different, even > pointing to a completely different location. > > 3)If the passive party sends an updated offer with a semantically > identical URL as the original, this indicates no change. (I don't know > why you would do this, but Paul asked for an example of an update that > changes nothing.) There are at least two use cases for this: - the session has session timer active. At some point it is necessary to send a reinvite to honor this. It has to have some offer, but there is no intent to change anything. - the session has multiple media - MSRP plus something else, say voice. There is a desire to change some attribute of the voice stream, but not of the MSRP stream. > Interestingly, the active party _cannot_ send an > updated without giving the active party a chance to provide a new > session URL. > > 4) A corrolary of 1) and 2) is that direction=both would not be > permitted for an update. > > 5) Updated offers can occur for both healthy sessions and as a result of > connection failures, etc. > > Thoughts? > > Ben. > > > _______________________________________________ > 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-admin@ietf.org Mon Dec 15 17:59:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04103 for ; Mon, 15 Dec 2003 17:59:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1g5-0004b4-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:59:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1g4-0004ax-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 17:59:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1g4-0004au-00; Mon, 15 Dec 2003 17:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1g5-0003bx-3N; Mon, 15 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1fZ-0003V1-JM for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04077 for ; Mon, 15 Dec 2003 17:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1fW-0004a8-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1fW-0004a1-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW1fV-0004Zy-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFMvjnG041144; Mon, 15 Dec 2003 16:57:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE3C60.6030305@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple WG Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <3FDE2594.9010709@dynamicsoft.com> <3FDE3B66.1040500@cisco.com> In-Reply-To: <3FDE3B66.1040500@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:57:36 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > There are at least two use cases for this: > > - the session has session timer active. At some point it is necessary to > send a reinvite to honor this. It has to have some offer, but there is > no intent to change anything. > > - the session has multiple media - MSRP plus something else, say voice. > There is a desire to change some attribute of the voice stream, but not > of the MSRP stream. > You are right, of course. Don't know what I was thinking... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 17:59:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04122 for ; Mon, 15 Dec 2003 17:59:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1g9-0003eU-Bg for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFMx5jT013993 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 17:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1g9-0003dc-4K for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 17:59:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04119 for ; Mon, 15 Dec 2003 17:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1g6-0004bF-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:59:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1g5-0004b8-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 17:59:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW1g4-0004au-00; Mon, 15 Dec 2003 17:59:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1g5-0003bx-3N; Mon, 15 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW1fZ-0003V1-JM for simple@optimus.ietf.org; Mon, 15 Dec 2003 17:58:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04077 for ; Mon, 15 Dec 2003 17:58:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW1fW-0004a8-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW1fW-0004a1-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:26 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AW1fV-0004Zy-00 for simple@ietf.org; Mon, 15 Dec 2003 17:58:25 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBFMvjnG041144; Mon, 15 Dec 2003 16:57:56 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDE3C60.6030305@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: Simple WG Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <3FDE2594.9010709@dynamicsoft.com> <3FDE3B66.1040500@cisco.com> In-Reply-To: <3FDE3B66.1040500@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:57:36 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > There are at least two use cases for this: > > - the session has session timer active. At some point it is necessary to > send a reinvite to honor this. It has to have some offer, but there is > no intent to change anything. > > - the session has multiple media - MSRP plus something else, say voice. > There is a desire to change some attribute of the voice stream, but not > of the MSRP stream. > You are right, of course. Don't know what I was thinking... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 18:36:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06201 for ; Mon, 15 Dec 2003 18:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fw-0005VN-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 18:36:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2Fu-0005VG-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 18:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fu-0005VD-00; Mon, 15 Dec 2003 18:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2Fu-0004hK-UV; Mon, 15 Dec 2003 18:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2Fr-0004gp-B2 for simple@optimus.ietf.org; Mon, 15 Dec 2003 18:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06198 for ; Mon, 15 Dec 2003 18:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fo-0005VA-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2Fm-0005V3-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:55 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fm-0005UL-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:54 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:32:40 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC30@corp.webb.net> From: Joe Hildebrand To: xmppwg@jabber.org, "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Action Item: character mappings for interoperability Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:32:34 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hm. I guess I need to show more of my work. I had assumed that on the = XMPP side, the system entity that does server-to-server delivery would do = either something like draft-daigle-napstr-03.txt, or something even simpler, = like draft-ietf-impp-srv-04.txt, except with the "hard" DNS stuff moved to = the server. 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) 2) No? Ok, SRV: do you support SIMPLE? If so, where? (protocol = transcode, resend using SIMPLE) 3) No? Ok, SRV: do you support Wireless Villiage? If so, where? = (protocol transcode, resend using the WV S2S protocol)=20 4) No? Ok, maybe you're an older or less sophisticated XMPP = implementation. I'll look up your A record, and connect on 5269/tcp. (resend using = XMPP S2S) And something similar on the SIMPLE side. More-or-less obviously, the = order of the above should be a policy decision on the part of an admin. = Given that, I'm not sure that allowing a user to explicitly go around the site-wide policy is a good thing.=20 Really, the only question I had was on step 2) above. If I determine = that the other side would rather talk SIMPLE than XMPP, what address do I = put on the message? sips: or im:? --=20 Joe Hildebrand =20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > Sent: Monday, December 15, 2003 2:52 PM > To: Adam Roach > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > mappings for interoperability >=20 > Is the context of this thread IM only, or do we also care=20 > about presence? I am not sure the issues are always exactly=20 > the same, since IM addresses may be delivered as part of presence. >=20 > I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here.=20 > Also, if I recall we _do_ have guidance on how to map an im:=20 > url to a concrete service using SRV, don't we? It seems to me=20 > that if I am a SIP user, the only real hope I have of=20 > cross-protocol interoperability is to advertise a PRES or IM=20 > URI. Other systems may be able to reach SIP URIs on an ad-hoc=20 > basis, but the abstract schema provide a more general approach. >=20 > More inline: >=20 > Adam Roach wrote: >=20 > > I'm cross posting this to SIMPLE to help cross-pollinate some ideas = > > here. > >=20 > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > >=20 > > [huge snip] > >=20 > >=20 > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > >>im:jos%c3%a9&b%c3%b3b@jabber.com > >>(note for the MIME-impaired: that's jose' and bo'b) > >> > >>Actually, it's not clear to me from RFC 3428 whether I=20 > should map into=20 > >>sip:, sips: or im:; I could use some guidance here from the SIMPLE=20 > >>folk. > >=20 > >=20 > > Well, they're all (potentially) different namespaces. In=20 > particular,=20 > > there's nothing (other than a possible site-local policy)=20 > that would=20 > > ensure that "im:adam@dynamicsoft.com" would map to the same user as = > > "sip:adam@dynamicsoft.com" -- so, you need to have some=20 > mechanism by=20 > > which a distinction is performed. I'll get to that in a second. > >=20 > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > user: > >=20 > > Any resource described by a SIP URI can be > > "upgraded" to a SIPS URI by just changing the scheme, if it is > > desired to communicate with that resource securely. > >=20 > > So, when you get to a gateway that is going from XMPP to=20 > SIP, I would=20 > > posit that selection of "sip:" would be appropriate when SASL isn't = > > being used on the XMPP side, and that "sips:" > > would be appropriate when it is. > >=20 > > Now, for the issue I deferred: when a message arrives for a=20 > jid, how=20 > > do you know what to do with it? Let's imagine that I send=20 > an IM (from=20 > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > understanding is correct, this *must* end up being routed to the=20 > > server indicated by the xmpp-server SRV record for=20 > "jabber.com." So...=20 > > does that server attempt to deliver it to an XMPP account called=20 > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > "sip:JHildebrand@jabber.com"? > >=20 > > One answer would be "selection amongst those destinations=20 > is going to=20 > > be based on local configuration at the jabber.com XMPP=20 > server, since=20 > > it 'owns' the jabber.com namespace." And that would work,=20 > sort of, and=20 > > be consistent and simple. > >=20 > > But it's a very incomplete solution. > >=20 > > On a grander scale, we need to ask: if you are sitting at an XMPP=20 > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > "sip:adam@dynamicsoft.com", how do you do that? Can we assume that=20 > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can=20 > we assume=20 > > that jabber.com is? Should this be able to work if the XMPP=20 > to SIMPLE=20 > > gateway is owned by yet a third domain? > >=20 > > I think all three solutions need to be possible. > >=20 > > We've already discussed how the first would work; that's easy. > > The scheme to use in translation is a matter of the=20 > destination server=20 > > configuration, potentially selected on a user-by-user basis. >=20 > I'm not sure I agree on this. As you mention above, even if=20 > dynamicsoft.com maintains an xmpp to simple gateway, there is=20 > no reason to expect that you can infer an identifier that=20 > makes sense to the xmpp side of the gateway from a SIP URI.=20 > If dynamicsoft maintains such a gateway, then it would make=20 > more sense to advertise an xmpp identity in addition to the=20 > SIP identity, or perhaps an im: URI for both. >=20 > It seems to me that an xmpp device, presented with a SIP URI,=20 > can do nothing intelligent with it beyond submitting it to=20 > some xmpp-sip gateway that it _already_ knows about, and it=20 > cannot use the SIP URI to discover that gateway. > >=20 > > The second would require some indication from your client to your=20 > > server (the host indicated by the xmpp-client SRV record for > > jabber.com) that you want to break out to a SIP network. > > I don't know enough about the formatting of jids to propose=20 > something=20 > > ideal, but I would think that using some sort of locally-configured = > > prefix would provide that sort of indication (e.g. sending an IM to = > > "sip#x3A;adam@dynamicsoft.com" would indicate to your=20 > server, by the=20 > > presence of "sip#x3A;", that it should gateway to=20 > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality=20 > > instead of finding the XMPP server for dynamicsoft.com). In=20 > this case,=20 > > the proper scheme to use is explicitly indicated by the user. > >=20 > > The third case will require using a jid that explicitly=20 > routes to the=20 > > third-party gateway; for example,=20 > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > ugliness would be hidden behind some sort of user interface=20 > construct=20 > > that allows users to configure their default SIMPLE=20 > gateway). For this=20 > > case, the scheme is decided by the gateway itself, and will=20 > typically=20 > > be specific to the protocol mapping provided by that=20 > gateway (i.e. a=20 > > gateway that translates to SIMPLE will always use sip: or sips:, as = > > appropriate). > >=20 > > At least, that's my two cents on the topic. > >=20 > > /a > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 18:36:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06252 for ; Mon, 15 Dec 2003 18:36:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2G2-0004iA-El for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 18:36:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFNaA17018106 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 18:36:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2G0-0004hx-TK for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 18:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06217 for ; Mon, 15 Dec 2003 18:36:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fx-0005VY-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 18:36:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2Fw-0005VR-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 18:36:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fu-0005VD-00; Mon, 15 Dec 2003 18:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2Fu-0004hK-UV; Mon, 15 Dec 2003 18:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW2Fr-0004gp-B2 for simple@optimus.ietf.org; Mon, 15 Dec 2003 18:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06198 for ; Mon, 15 Dec 2003 18:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fo-0005VA-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW2Fm-0005V3-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:55 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AW2Fm-0005UL-00 for simple@ietf.org; Mon, 15 Dec 2003 18:35:54 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 16:32:40 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC30@corp.webb.net> From: Joe Hildebrand To: xmppwg@jabber.org, "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: Action Item: character mappings for interoperability Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 16:32:34 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hm. I guess I need to show more of my work. I had assumed that on the = XMPP side, the system entity that does server-to-server delivery would do = either something like draft-daigle-napstr-03.txt, or something even simpler, = like draft-ietf-impp-srv-04.txt, except with the "hard" DNS stuff moved to = the server. 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) 2) No? Ok, SRV: do you support SIMPLE? If so, where? (protocol = transcode, resend using SIMPLE) 3) No? Ok, SRV: do you support Wireless Villiage? If so, where? = (protocol transcode, resend using the WV S2S protocol)=20 4) No? Ok, maybe you're an older or less sophisticated XMPP = implementation. I'll look up your A record, and connect on 5269/tcp. (resend using = XMPP S2S) And something similar on the SIMPLE side. More-or-less obviously, the = order of the above should be a policy decision on the part of an admin. = Given that, I'm not sure that allowing a user to explicitly go around the site-wide policy is a good thing.=20 Really, the only question I had was on step 2) above. If I determine = that the other side would rather talk SIMPLE than XMPP, what address do I = put on the message? sips: or im:? --=20 Joe Hildebrand =20 > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > Sent: Monday, December 15, 2003 2:52 PM > To: Adam Roach > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > mappings for interoperability >=20 > Is the context of this thread IM only, or do we also care=20 > about presence? I am not sure the issues are always exactly=20 > the same, since IM addresses may be delivered as part of presence. >=20 > I wonder (vaguely) if draft-daigle-napstr-03.txt is applicable here.=20 > Also, if I recall we _do_ have guidance on how to map an im:=20 > url to a concrete service using SRV, don't we? It seems to me=20 > that if I am a SIP user, the only real hope I have of=20 > cross-protocol interoperability is to advertise a PRES or IM=20 > URI. Other systems may be able to reach SIP URIs on an ad-hoc=20 > basis, but the abstract schema provide a more general approach. >=20 > More inline: >=20 > Adam Roach wrote: >=20 > > I'm cross posting this to SIMPLE to help cross-pollinate some ideas = > > here. > >=20 > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > >=20 > > [huge snip] > >=20 > >=20 > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > >>im:jos%c3%a9&b%c3%b3b@jabber.com > >>(note for the MIME-impaired: that's jose' and bo'b) > >> > >>Actually, it's not clear to me from RFC 3428 whether I=20 > should map into=20 > >>sip:, sips: or im:; I could use some guidance here from the SIMPLE=20 > >>folk. > >=20 > >=20 > > Well, they're all (potentially) different namespaces. In=20 > particular,=20 > > there's nothing (other than a possible site-local policy)=20 > that would=20 > > ensure that "im:adam@dynamicsoft.com" would map to the same user as = > > "sip:adam@dynamicsoft.com" -- so, you need to have some=20 > mechanism by=20 > > which a distinction is performed. I'll get to that in a second. > >=20 > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > user: > >=20 > > Any resource described by a SIP URI can be > > "upgraded" to a SIPS URI by just changing the scheme, if it is > > desired to communicate with that resource securely. > >=20 > > So, when you get to a gateway that is going from XMPP to=20 > SIP, I would=20 > > posit that selection of "sip:" would be appropriate when SASL isn't = > > being used on the XMPP side, and that "sips:" > > would be appropriate when it is. > >=20 > > Now, for the issue I deferred: when a message arrives for a=20 > jid, how=20 > > do you know what to do with it? Let's imagine that I send=20 > an IM (from=20 > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > understanding is correct, this *must* end up being routed to the=20 > > server indicated by the xmpp-server SRV record for=20 > "jabber.com." So...=20 > > does that server attempt to deliver it to an XMPP account called=20 > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > "sip:JHildebrand@jabber.com"? > >=20 > > One answer would be "selection amongst those destinations=20 > is going to=20 > > be based on local configuration at the jabber.com XMPP=20 > server, since=20 > > it 'owns' the jabber.com namespace." And that would work,=20 > sort of, and=20 > > be consistent and simple. > >=20 > > But it's a very incomplete solution. > >=20 > > On a grander scale, we need to ask: if you are sitting at an XMPP=20 > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > "sip:adam@dynamicsoft.com", how do you do that? Can we assume that=20 > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can=20 > we assume=20 > > that jabber.com is? Should this be able to work if the XMPP=20 > to SIMPLE=20 > > gateway is owned by yet a third domain? > >=20 > > I think all three solutions need to be possible. > >=20 > > We've already discussed how the first would work; that's easy. > > The scheme to use in translation is a matter of the=20 > destination server=20 > > configuration, potentially selected on a user-by-user basis. >=20 > I'm not sure I agree on this. As you mention above, even if=20 > dynamicsoft.com maintains an xmpp to simple gateway, there is=20 > no reason to expect that you can infer an identifier that=20 > makes sense to the xmpp side of the gateway from a SIP URI.=20 > If dynamicsoft maintains such a gateway, then it would make=20 > more sense to advertise an xmpp identity in addition to the=20 > SIP identity, or perhaps an im: URI for both. >=20 > It seems to me that an xmpp device, presented with a SIP URI,=20 > can do nothing intelligent with it beyond submitting it to=20 > some xmpp-sip gateway that it _already_ knows about, and it=20 > cannot use the SIP URI to discover that gateway. > >=20 > > The second would require some indication from your client to your=20 > > server (the host indicated by the xmpp-client SRV record for > > jabber.com) that you want to break out to a SIP network. > > I don't know enough about the formatting of jids to propose=20 > something=20 > > ideal, but I would think that using some sort of locally-configured = > > prefix would provide that sort of indication (e.g. sending an IM to = > > "sip#x3A;adam@dynamicsoft.com" would indicate to your=20 > server, by the=20 > > presence of "sip#x3A;", that it should gateway to=20 > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality=20 > > instead of finding the XMPP server for dynamicsoft.com). In=20 > this case,=20 > > the proper scheme to use is explicitly indicated by the user. > >=20 > > The third case will require using a jid that explicitly=20 > routes to the=20 > > third-party gateway; for example,=20 > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > ugliness would be hidden behind some sort of user interface=20 > construct=20 > > that allows users to configure their default SIMPLE=20 > gateway). For this=20 > > case, the scheme is decided by the gateway itself, and will=20 > typically=20 > > be specific to the protocol mapping provided by that=20 > gateway (i.e. a=20 > > gateway that translates to SIMPLE will always use sip: or sips:, as = > > appropriate). > >=20 > > At least, that's my two cents on the topic. > >=20 > > /a > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 15 19:31:03 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07692 for ; Mon, 15 Dec 2003 19:31:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW37B-0006lM-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 19:31:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW37A-0006lF-00 for simple-archive@ietf.org; Mon, 15 Dec 2003 19:31:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW37A-0006lC-00; Mon, 15 Dec 2003 19:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW377-0006HN-DL; Mon, 15 Dec 2003 19:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW36m-0006E3-59 for simple@optimus.ietf.org; Mon, 15 Dec 2003 19:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07662 for ; Mon, 15 Dec 2003 19:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW36k-0006kh-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW36j-0006ka-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:38 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AW36j-0006jg-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:37 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 17:27:18 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC33@corp.webb.net> From: Joe Hildebrand To: xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 17:27:16 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The objection you're raising -- that you couldn't then pass > out a single identifier -- is one reason I called it an > incomplete solution. (The other objection is that it > *requires* the destination domain to run an XMPP server in > order to work). I'm hoping my other mail addressed this. I'm not sure why I'd have to have the destination domain running an XMPP server. If the originating XMPP server can do the SRV dance, and finds out that the destination server supports SIMPLE but not XMPP, that's when the jid->im: translation takes place. If you want to pass out a single identifer, feel free to pass out im:foo@bar, if that's your thing, and you're an English speaker. XMPP folks (or their UAs) will learn to strip of the im:, just like people strip off the mailto: today. I'm not sure what to suggest to you if your username isn't US-ASCII. You could give out either the unencoded version (which should be easier to type, as long as you only deal with people in your language camp), or the encoded version, which would be really ugly, or both, which seems like overkill. -- Joe Hildebrand _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 15 19:31:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07711 for ; Mon, 15 Dec 2003 19:31:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW37E-0006IY-4I for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 19:31:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG0V8JB024204 for simple-archive@odin.ietf.org; Mon, 15 Dec 2003 19:31:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW37E-0006IJ-0d for simple-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 19:31:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07708 for ; Mon, 15 Dec 2003 19:31:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW37C-0006lX-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 19:31:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW37B-0006lQ-00 for simple-web-archive@ietf.org; Mon, 15 Dec 2003 19:31:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW37A-0006lC-00; Mon, 15 Dec 2003 19:31:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW377-0006HN-DL; Mon, 15 Dec 2003 19:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW36m-0006E3-59 for simple@optimus.ietf.org; Mon, 15 Dec 2003 19:30:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07662 for ; Mon, 15 Dec 2003 19:30:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW36k-0006kh-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW36j-0006ka-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:38 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AW36j-0006jg-00 for simple@ietf.org; Mon, 15 Dec 2003 19:30:37 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Dec 2003 17:27:18 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC33@corp.webb.net> From: Joe Hildebrand To: xmppwg@jabber.org, "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] Action Item: character mappings for int eroperability MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 15 Dec 2003 17:27:16 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > The objection you're raising -- that you couldn't then pass > out a single identifier -- is one reason I called it an > incomplete solution. (The other objection is that it > *requires* the destination domain to run an XMPP server in > order to work). I'm hoping my other mail addressed this. I'm not sure why I'd have to have the destination domain running an XMPP server. If the originating XMPP server can do the SRV dance, and finds out that the destination server supports SIMPLE but not XMPP, that's when the jid->im: translation takes place. If you want to pass out a single identifer, feel free to pass out im:foo@bar, if that's your thing, and you're an English speaker. XMPP folks (or their UAs) will learn to strip of the im:, just like people strip off the mailto: today. I'm not sure what to suggest to you if your username isn't US-ASCII. You could give out either the unencoded version (which should be easier to type, as long as you only deal with people in your language camp), or the encoded version, which would be really ugly, or both, which seems like overkill. -- Joe Hildebrand _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 04:11:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05100 for ; Tue, 16 Dec 2003 04:11:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWBEZ-0005yT-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 04:11:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWBEY-0005yL-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 04:11:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWBEY-0005yI-00; Tue, 16 Dec 2003 04:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBEO-0008GT-ST; Tue, 16 Dec 2003 04:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBDW-0008FR-4s for simple@optimus.ietf.org; Tue, 16 Dec 2003 04:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05083 for ; Tue, 16 Dec 2003 04:10:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWBDT-0005xd-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWBDR-0005xM-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWBDR-0005x4-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:05 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBG9A5H02681 for ; Tue, 16 Dec 2003 11:10:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 11:10:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 11:10:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPDUZvLY4i+eRARQVapV1SVWzz4GgAYnTrA To: , X-OriginalArrivalTime: 16 Dec 2003 09:10:05.0548 (UTC) FILETIME=[652CF2C0:01C3C3B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 11:10:04 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I also agree, but I require a clarification, see inline... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 15.December.2003 23:20 > To: Simple WG > Subject: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > We have had a lot of discussion on how we deal with=20 > connection failures,=20 > session continuance across a failure, duplicate supression,=20 > etc. Much of=20 > that depends on how we handle session updates. Here are some thoughts=20 > for discussion. >=20 > Although the sense of the room at IETF58 indicated we needed a way to=20 > re-establish TCP connections without resignaling, subsequent list=20 > discussion has indicated consensus that this will not work,=20 > and we will=20 > indeed have to re-signal. I am slightly concerned that many=20 > of those who=20 > favored reconnection without resignaling at the meeting have not=20 > participated in the email thread. I must assume that means=20 > they agree ;-) >=20 > Obviously resignaling means a new SDP exchange. For SIP, that=20 > would mean=20 > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks=20 > about sip, I think the re-INVITE vs UPDATE question is out of=20 > scope, and=20 > is treated sufficiently well in the UPDATE rfc. >=20 > So, here are some assumptions and observations about how an updated=20 > offer/answer would work. >=20 > 0) We don't have to worry about early media. (I expect this to be=20 > controversial, but I can always hope. The following are based on that=20 > assumption.) >=20 > 1) The active party must remain the active party. If the active party=20 > initiates an updated offer, it MUST NOT contain a session URL. >=20 > 2) The passive party must remain the passive party. If the=20 > passive party=20 > initates an updated offer, it MUST contain a session URL.=20 > This updated=20 > URL may be the same as before, or may be completely different, even=20 > pointing to a completely different location. >=20 > 3)If the passive party sends an updated offer with a semantically=20 > identical URL as the original, this indicates no change. (I=20 > don't know=20 > why you would do this, but Paul asked for an example of an=20 > update that=20 > changes nothing.) Interestingly, the active party _cannot_ send an=20 > updated without giving the active party a chance to provide a new=20 > session URL. I assume you mean "without giving the passive party a chance...". In this case, do you think that 1) will ever happen? Why can't the = active party send an update without first the passive party providing a = new session URL? Or have I missed your point? /Hisham >=20 > 4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > permitted for an update. >=20 > 5) Updated offers can occur for both healthy sessions and as=20 > a result of=20 > connection failures, etc. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Tue Dec 16 04:11:50 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05126 for ; Tue, 16 Dec 2003 04:11:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBEf-0008HV-ES for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 04:11:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG9BKRB031830 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 04:11:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBEd-0008HJ-UU for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 04:11:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05116 for ; Tue, 16 Dec 2003 04:11:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWBEb-0005ye-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 04:11:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWBEZ-0005yX-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 04:11:16 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWBEY-0005yI-00; Tue, 16 Dec 2003 04:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBEO-0008GT-ST; Tue, 16 Dec 2003 04:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWBDW-0008FR-4s for simple@optimus.ietf.org; Tue, 16 Dec 2003 04:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05083 for ; Tue, 16 Dec 2003 04:10:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWBDT-0005xd-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWBDR-0005xM-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWBDR-0005x4-00 for simple@ietf.org; Tue, 16 Dec 2003 04:10:05 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBG9A5H02681 for ; Tue, 16 Dec 2003 11:10:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 11:10:05 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 11:10:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPDUZvLY4i+eRARQVapV1SVWzz4GgAYnTrA To: , X-OriginalArrivalTime: 16 Dec 2003 09:10:05.0548 (UTC) FILETIME=[652CF2C0:01C3C3B4] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 11:10:04 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I also agree, but I require a clarification, see inline... > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 15.December.2003 23:20 > To: Simple WG > Subject: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > We have had a lot of discussion on how we deal with=20 > connection failures,=20 > session continuance across a failure, duplicate supression,=20 > etc. Much of=20 > that depends on how we handle session updates. Here are some thoughts=20 > for discussion. >=20 > Although the sense of the room at IETF58 indicated we needed a way to=20 > re-establish TCP connections without resignaling, subsequent list=20 > discussion has indicated consensus that this will not work,=20 > and we will=20 > indeed have to re-signal. I am slightly concerned that many=20 > of those who=20 > favored reconnection without resignaling at the meeting have not=20 > participated in the email thread. I must assume that means=20 > they agree ;-) >=20 > Obviously resignaling means a new SDP exchange. For SIP, that=20 > would mean=20 > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks=20 > about sip, I think the re-INVITE vs UPDATE question is out of=20 > scope, and=20 > is treated sufficiently well in the UPDATE rfc. >=20 > So, here are some assumptions and observations about how an updated=20 > offer/answer would work. >=20 > 0) We don't have to worry about early media. (I expect this to be=20 > controversial, but I can always hope. The following are based on that=20 > assumption.) >=20 > 1) The active party must remain the active party. If the active party=20 > initiates an updated offer, it MUST NOT contain a session URL. >=20 > 2) The passive party must remain the passive party. If the=20 > passive party=20 > initates an updated offer, it MUST contain a session URL.=20 > This updated=20 > URL may be the same as before, or may be completely different, even=20 > pointing to a completely different location. >=20 > 3)If the passive party sends an updated offer with a semantically=20 > identical URL as the original, this indicates no change. (I=20 > don't know=20 > why you would do this, but Paul asked for an example of an=20 > update that=20 > changes nothing.) Interestingly, the active party _cannot_ send an=20 > updated without giving the active party a chance to provide a new=20 > session URL. I assume you mean "without giving the passive party a chance...". In this case, do you think that 1) will ever happen? Why can't the = active party send an update without first the passive party providing a = new session URL? Or have I missed your point? /Hisham >=20 > 4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > permitted for an update. >=20 > 5) Updated offers can occur for both healthy sessions and as=20 > a result of=20 > connection failures, etc. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Tue Dec 16 10:39:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18458 for ; Tue, 16 Dec 2003 10:39:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHHz-00054b-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:39:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHH1-0004sE-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:39:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHGz-0004sB-00; Tue, 16 Dec 2003 10:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHGr-0005Vj-F7; Tue, 16 Dec 2003 10:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHG3-0005HP-Hq for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:37:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18062 for ; Tue, 16 Dec 2003 10:37:07 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHG1-0004eI-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHFk-0004ar-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWHFj-0004aS-00 for simple@ietf.org; Tue, 16 Dec 2003 10:36:51 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFam714640 for ; Tue, 16 Dec 2003 17:36:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:36:47 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPDUZvnCmkuBEbXTJmn0RjMurJVeQAlvNfQ To: , X-OriginalArrivalTime: 16 Dec 2003 15:36:47.0470 (UTC) FILETIME=[6A9948E0:01C3C3EA] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:36:47 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Ben, I agree with what you state below. Just to make sure I understand it correctly though, the restrictions for = the active party to stay active and the passive to stay passive when = updating do indeed also apply to adding another MSRP media component to = an existing session? Because, it makes little sense to repeat a "offer both-> try active and = fail -> answer passive" sequence for each new MSRP component added to a = session. This is an additional benefit we would get by the below = restrictions, which is a good thing. Of course, this would not allow = negotiating 'direction' per MSRP session inside a SIP dialog, but I = don't see much use for that anyway. Cheers, Aki > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext Ben Campbell > Sent: 15 December, 2003 23:20 > To: Simple WG > Subject: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > We have had a lot of discussion on how we deal with=20 > connection failures,=20 > session continuance across a failure, duplicate supression,=20 > etc. Much of=20 > that depends on how we handle session updates. Here are some=20 > thoughts=20 > for discussion. >=20 > Although the sense of the room at IETF58 indicated we needed=20 > a way to=20 > re-establish TCP connections without resignaling, subsequent list=20 > discussion has indicated consensus that this will not work,=20 > and we will=20 > indeed have to re-signal. I am slightly concerned that many=20 > of those who=20 > favored reconnection without resignaling at the meeting have not=20 > participated in the email thread. I must assume that means=20 > they agree ;-) >=20 > Obviously resignaling means a new SDP exchange. For SIP,=20 > that would mean=20 > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks=20 > about sip, I think the re-INVITE vs UPDATE question is out=20 > of scope, and=20 > is treated sufficiently well in the UPDATE rfc. >=20 > So, here are some assumptions and observations about how an updated=20 > offer/answer would work. >=20 > 0) We don't have to worry about early media. (I expect this to be=20 > controversial, but I can always hope. The following are=20 > based on that=20 > assumption.) >=20 > 1) The active party must remain the active party. If the=20 > active party=20 > initiates an updated offer, it MUST NOT contain a session URL. >=20 > 2) The passive party must remain the passive party. If the=20 > passive party=20 > initates an updated offer, it MUST contain a session URL.=20 > This updated=20 > URL may be the same as before, or may be completely different, even=20 > pointing to a completely different location. >=20 > 3)If the passive party sends an updated offer with a semantically=20 > identical URL as the original, this indicates no change. (I=20 > don't know=20 > why you would do this, but Paul asked for an example of an=20 > update that=20 > changes nothing.) Interestingly, the active party _cannot_ send an=20 > updated without giving the active party a chance to provide a new=20 > session URL. >=20 > 4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > permitted for an update. >=20 > 5) Updated offers can occur for both healthy sessions and as=20 > a result of=20 > connection failures, etc. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Tue Dec 16 10:39:48 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18581 for ; Tue, 16 Dec 2003 10:39:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHIb-0005AR-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:39:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHIA-00057Q-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:39:46 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHI9-000578-00; Tue, 16 Dec 2003 10:39:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWHI6-0002sa-UW; Tue, 16 Dec 2003 10:39:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHHp-0005mi-UN; Tue, 16 Dec 2003 10:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHH8-0005bT-LJ for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18288 for ; Tue, 16 Dec 2003 10:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHH5-0004tX-00 for simple@ietf.org; Tue, 16 Dec 2003 10:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHGZ-0004mA-00 for simple@ietf.org; Tue, 16 Dec 2003 10:38:06 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHGX-0004bL-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by manatick with esmtp (Exim 4.24) id 1AWG9f-0007w7-Qq for simple@ietf.org; Tue, 16 Dec 2003 09:26:32 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGEQ5nG010594; Tue, 16 Dec 2003 08:26:17 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF15F5.6010404@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 08:25:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I also agree, but I require a clarification, see inline... > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 15.December.2003 23:20 >>To: Simple WG >>Subject: [Simple] MSRP: Some thoughts on session updates >> >> >>We have had a lot of discussion on how we deal with >>connection failures, >>session continuance across a failure, duplicate supression, >>etc. Much of >>that depends on how we handle session updates. Here are some thoughts >>for discussion. >> >>Although the sense of the room at IETF58 indicated we needed a way to >>re-establish TCP connections without resignaling, subsequent list >>discussion has indicated consensus that this will not work, >>and we will >>indeed have to re-signal. I am slightly concerned that many >>of those who >>favored reconnection without resignaling at the meeting have not >>participated in the email thread. I must assume that means >>they agree ;-) >> >>Obviously resignaling means a new SDP exchange. For SIP, that >>would mean >>a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks >>about sip, I think the re-INVITE vs UPDATE question is out of >>scope, and >>is treated sufficiently well in the UPDATE rfc. >> >>So, here are some assumptions and observations about how an updated >>offer/answer would work. >> >>0) We don't have to worry about early media. (I expect this to be >>controversial, but I can always hope. The following are based on that >>assumption.) >> >>1) The active party must remain the active party. If the active party >>initiates an updated offer, it MUST NOT contain a session URL. >> >>2) The passive party must remain the passive party. If the >>passive party >>initates an updated offer, it MUST contain a session URL. >>This updated >>URL may be the same as before, or may be completely different, even >>pointing to a completely different location. >> >>3)If the passive party sends an updated offer with a semantically >>identical URL as the original, this indicates no change. (I >>don't know >>why you would do this, but Paul asked for an example of an >>update that >>changes nothing.) Interestingly, the active party _cannot_ send an >>updated without giving the active party a chance to provide a new >>session URL. > > > I assume you mean "without giving the passive party a chance...". Uhm, yes. Sorry. > > In this case, do you think that 1) will ever happen? Why can't the active party send an update without first the passive party providing a new session URL? > > Or have I missed your point? I think you missed the point. It can send an update without the passive party first supplying a new URL. Basically, it works like this: Active Passive new offer (no url)-------> <-----resp (may have URL)- So, when the active party sends an update, without a URL, the passive party may or may not send a new URL back. The active party cannot prevent the passive party from doing so. It occurs to me their may be a problem here. If the active party is sending an update because it has detected a connection failure, it may need a way to _insist_ on a new URL. If the passive party has not yet noticed the failure, it cannot tell the difference between a "no change" update and a "connection broken" update. > > /Hisham > > >>4) A corrolary of 1) and 2) is that direction=both would not be >>permitted for an update. >> >>5) Updated offers can occur for both healthy sessions and as >>a result of >>connection failures, etc. >> >>Thoughts? >> >>Ben. >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Tue Dec 16 10:40:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18663 for ; Tue, 16 Dec 2003 10:40:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHIW-0005w1-Ga for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:39:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFdiSg022807 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:39:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHIW-0005vm-Cl for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:39:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18567 for ; Tue, 16 Dec 2003 10:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHIT-00059h-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:39:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHI1-00055B-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:39:39 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHGz-0004sB-00; Tue, 16 Dec 2003 10:38:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHGr-0005Vj-F7; Tue, 16 Dec 2003 10:38:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHG3-0005HP-Hq for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:37:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18062 for ; Tue, 16 Dec 2003 10:37:07 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHG1-0004eI-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHFk-0004ar-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:06 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWHFj-0004aS-00 for simple@ietf.org; Tue, 16 Dec 2003 10:36:51 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFam714640 for ; Tue, 16 Dec 2003 17:36:48 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:36:47 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:36:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPDUZvnCmkuBEbXTJmn0RjMurJVeQAlvNfQ To: , X-OriginalArrivalTime: 16 Dec 2003 15:36:47.0470 (UTC) FILETIME=[6A9948E0:01C3C3EA] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:36:47 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Ben, I agree with what you state below. Just to make sure I understand it correctly though, the restrictions for = the active party to stay active and the passive to stay passive when = updating do indeed also apply to adding another MSRP media component to = an existing session? Because, it makes little sense to repeat a "offer both-> try active and = fail -> answer passive" sequence for each new MSRP component added to a = session. This is an additional benefit we would get by the below = restrictions, which is a good thing. Of course, this would not allow = negotiating 'direction' per MSRP session inside a SIP dialog, but I = don't see much use for that anyway. Cheers, Aki > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > Behalf Of > ext Ben Campbell > Sent: 15 December, 2003 23:20 > To: Simple WG > Subject: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > We have had a lot of discussion on how we deal with=20 > connection failures,=20 > session continuance across a failure, duplicate supression,=20 > etc. Much of=20 > that depends on how we handle session updates. Here are some=20 > thoughts=20 > for discussion. >=20 > Although the sense of the room at IETF58 indicated we needed=20 > a way to=20 > re-establish TCP connections without resignaling, subsequent list=20 > discussion has indicated consensus that this will not work,=20 > and we will=20 > indeed have to re-signal. I am slightly concerned that many=20 > of those who=20 > favored reconnection without resignaling at the meeting have not=20 > participated in the email thread. I must assume that means=20 > they agree ;-) >=20 > Obviously resignaling means a new SDP exchange. For SIP,=20 > that would mean=20 > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks=20 > about sip, I think the re-INVITE vs UPDATE question is out=20 > of scope, and=20 > is treated sufficiently well in the UPDATE rfc. >=20 > So, here are some assumptions and observations about how an updated=20 > offer/answer would work. >=20 > 0) We don't have to worry about early media. (I expect this to be=20 > controversial, but I can always hope. The following are=20 > based on that=20 > assumption.) >=20 > 1) The active party must remain the active party. If the=20 > active party=20 > initiates an updated offer, it MUST NOT contain a session URL. >=20 > 2) The passive party must remain the passive party. If the=20 > passive party=20 > initates an updated offer, it MUST contain a session URL.=20 > This updated=20 > URL may be the same as before, or may be completely different, even=20 > pointing to a completely different location. >=20 > 3)If the passive party sends an updated offer with a semantically=20 > identical URL as the original, this indicates no change. (I=20 > don't know=20 > why you would do this, but Paul asked for an example of an=20 > update that=20 > changes nothing.) Interestingly, the active party _cannot_ send an=20 > updated without giving the active party a chance to provide a new=20 > session URL. >=20 > 4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > permitted for an update. >=20 > 5) Updated offers can occur for both healthy sessions and as=20 > a result of=20 > connection failures, etc. >=20 > Thoughts? >=20 > Ben. >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Tue Dec 16 10:40:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18773 for ; Tue, 16 Dec 2003 10:40:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHJ4-0005yJ-Ru for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:40:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFeIXu022949 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHJ4-0005y4-Kx for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:40:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18682 for ; Tue, 16 Dec 2003 10:40:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHJ2-0005FH-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:40:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHIc-0005At-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:40:14 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHI9-000578-00; Tue, 16 Dec 2003 10:39:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWHI6-0002sa-UW; Tue, 16 Dec 2003 10:39:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHHp-0005mi-UN; Tue, 16 Dec 2003 10:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHH8-0005bT-LJ for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:38:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18288 for ; Tue, 16 Dec 2003 10:38:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHH5-0004tX-00 for simple@ietf.org; Tue, 16 Dec 2003 10:38:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHGZ-0004mA-00 for simple@ietf.org; Tue, 16 Dec 2003 10:38:06 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHGX-0004bL-00 for simple@ietf.org; Tue, 16 Dec 2003 10:37:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by manatick with esmtp (Exim 4.24) id 1AWG9f-0007w7-Qq for simple@ietf.org; Tue, 16 Dec 2003 09:26:32 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGEQ5nG010594; Tue, 16 Dec 2003 08:26:17 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF15F5.6010404@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797521@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 08:25:57 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I also agree, but I require a clarification, see inline... > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 15.December.2003 23:20 >>To: Simple WG >>Subject: [Simple] MSRP: Some thoughts on session updates >> >> >>We have had a lot of discussion on how we deal with >>connection failures, >>session continuance across a failure, duplicate supression, >>etc. Much of >>that depends on how we handle session updates. Here are some thoughts >>for discussion. >> >>Although the sense of the room at IETF58 indicated we needed a way to >>re-establish TCP connections without resignaling, subsequent list >>discussion has indicated consensus that this will not work, >>and we will >>indeed have to re-signal. I am slightly concerned that many >>of those who >>favored reconnection without resignaling at the meeting have not >>participated in the email thread. I must assume that means >>they agree ;-) >> >>Obviously resignaling means a new SDP exchange. For SIP, that >>would mean >>a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks >>about sip, I think the re-INVITE vs UPDATE question is out of >>scope, and >>is treated sufficiently well in the UPDATE rfc. >> >>So, here are some assumptions and observations about how an updated >>offer/answer would work. >> >>0) We don't have to worry about early media. (I expect this to be >>controversial, but I can always hope. The following are based on that >>assumption.) >> >>1) The active party must remain the active party. If the active party >>initiates an updated offer, it MUST NOT contain a session URL. >> >>2) The passive party must remain the passive party. If the >>passive party >>initates an updated offer, it MUST contain a session URL. >>This updated >>URL may be the same as before, or may be completely different, even >>pointing to a completely different location. >> >>3)If the passive party sends an updated offer with a semantically >>identical URL as the original, this indicates no change. (I >>don't know >>why you would do this, but Paul asked for an example of an >>update that >>changes nothing.) Interestingly, the active party _cannot_ send an >>updated without giving the active party a chance to provide a new >>session URL. > > > I assume you mean "without giving the passive party a chance...". Uhm, yes. Sorry. > > In this case, do you think that 1) will ever happen? Why can't the active party send an update without first the passive party providing a new session URL? > > Or have I missed your point? I think you missed the point. It can send an update without the passive party first supplying a new URL. Basically, it works like this: Active Passive new offer (no url)-------> <-----resp (may have URL)- So, when the active party sends an update, without a URL, the passive party may or may not send a new URL back. The active party cannot prevent the passive party from doing so. It occurs to me their may be a problem here. If the active party is sending an update because it has detected a connection failure, it may need a way to _insist_ on a new URL. If the passive party has not yet noticed the failure, it cannot tell the difference between a "no change" update and a "connection broken" update. > > /Hisham > > >>4) A corrolary of 1) and 2) is that direction=both would not be >>permitted for an update. >> >>5) Updated offers can occur for both healthy sessions and as >>a result of >>connection failures, etc. >> >>Thoughts? >> >>Ben. >> >> >>_______________________________________________ >>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-admin@ietf.org Tue Dec 16 10:42:21 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19083 for ; Tue, 16 Dec 2003 10:42:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHL4-0005a0-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:42:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHKv-0005YY-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:42:22 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHKv-0005YS-00; Tue, 16 Dec 2003 10:42:13 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWHKw-00032J-1S; Tue, 16 Dec 2003 10:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHKi-0006JH-LX; Tue, 16 Dec 2003 10:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHJp-00067J-Fk for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18834 for ; Tue, 16 Dec 2003 10:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHJn-0005MU-00 for simple@ietf.org; Tue, 16 Dec 2003 10:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHJT-0005JO-00 for simple@ietf.org; Tue, 16 Dec 2003 10:41:02 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHJR-0005It-00 for simple@ietf.org; Tue, 16 Dec 2003 10:40:41 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGFeWnG016510; Tue, 16 Dec 2003 09:40:38 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF2768.8060506@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 09:40:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > Hi Ben, > > I agree with what you state below. > > Just to make sure I understand it correctly though, the restrictions for the active party to stay active and the passive to stay passive when updating do indeed also apply to adding another MSRP media component to an existing session? > > Because, it makes little sense to repeat a "offer both-> try active and fail -> answer passive" sequence for each new MSRP component added to a session. This is an additional benefit we would get by the below restrictions, which is a good thing. Of course, this would not allow negotiating 'direction' per MSRP session inside a SIP dialog, but I don't see much use for that anyway. I think I agree, as long as we are only talking about MSRP sessions. I don't think the direction of some other kind connection oriented media session would necessarily imply the direction for MSRP, but I think one MSRP session can definitely imply a direction for a second MSRP session. > > Cheers, > Aki > > > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On > > Behalf Of > > ext Ben Campbell > > Sent: 15 December, 2003 23:20 > > To: Simple WG > > Subject: [Simple] MSRP: Some thoughts on session updates > > > > > > We have had a lot of discussion on how we deal with > > connection failures, > > session continuance across a failure, duplicate supression, > > etc. Much of > > that depends on how we handle session updates. Here are some > > thoughts > > for discussion. > > > > Although the sense of the room at IETF58 indicated we needed > > a way to > > re-establish TCP connections without resignaling, subsequent list > > discussion has indicated consensus that this will not work, > > and we will > > indeed have to re-signal. I am slightly concerned that many > > of those who > > favored reconnection without resignaling at the meeting have not > > participated in the email thread. I must assume that means > > they agree ;-) > > > > Obviously resignaling means a new SDP exchange. For SIP, > > that would mean > > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks > > about sip, I think the re-INVITE vs UPDATE question is out > > of scope, and > > is treated sufficiently well in the UPDATE rfc. > > > > So, here are some assumptions and observations about how an updated > > offer/answer would work. > > > > 0) We don't have to worry about early media. (I expect this to be > > controversial, but I can always hope. The following are > > based on that > > assumption.) > > > > 1) The active party must remain the active party. If the > > active party > > initiates an updated offer, it MUST NOT contain a session URL. > > > > 2) The passive party must remain the passive party. If the > > passive party > > initates an updated offer, it MUST contain a session URL. > > This updated > > URL may be the same as before, or may be completely different, even > > pointing to a completely different location. > > > > 3)If the passive party sends an updated offer with a semantically > > identical URL as the original, this indicates no change. (I > > don't know > > why you would do this, but Paul asked for an example of an > > update that > > changes nothing.) Interestingly, the active party _cannot_ send an > > updated without giving the active party a chance to provide a new > > session URL. > > > > 4) A corrolary of 1) and 2) is that direction=both would not be > > permitted for an update. > > > > 5) Updated offers can occur for both healthy sessions and as > > a result of > > connection failures, etc. > > > > Thoughts? > > > > Ben. > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Tue Dec 16 10:42:59 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19194 for ; Tue, 16 Dec 2003 10:42:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHLE-0006Pr-25 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:42:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFgWUh024657 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:42:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHLD-0006Pc-V0 for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:42:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19107 for ; Tue, 16 Dec 2003 10:42:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHLB-0005bG-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:42:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHL4-0005a5-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:42:28 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHKv-0005YS-00; Tue, 16 Dec 2003 10:42:13 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWHKw-00032J-1S; Tue, 16 Dec 2003 10:42:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHKi-0006JH-LX; Tue, 16 Dec 2003 10:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHJp-00067J-Fk for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:41:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18834 for ; Tue, 16 Dec 2003 10:41:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHJn-0005MU-00 for simple@ietf.org; Tue, 16 Dec 2003 10:41:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHJT-0005JO-00 for simple@ietf.org; Tue, 16 Dec 2003 10:41:02 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHJR-0005It-00 for simple@ietf.org; Tue, 16 Dec 2003 10:40:41 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGFeWnG016510; Tue, 16 Dec 2003 09:40:38 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF2768.8060506@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D5930A@esebe013.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 09:40:24 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: > Hi Ben, > > I agree with what you state below. > > Just to make sure I understand it correctly though, the restrictions for the active party to stay active and the passive to stay passive when updating do indeed also apply to adding another MSRP media component to an existing session? > > Because, it makes little sense to repeat a "offer both-> try active and fail -> answer passive" sequence for each new MSRP component added to a session. This is an additional benefit we would get by the below restrictions, which is a good thing. Of course, this would not allow negotiating 'direction' per MSRP session inside a SIP dialog, but I don't see much use for that anyway. I think I agree, as long as we are only talking about MSRP sessions. I don't think the direction of some other kind connection oriented media session would necessarily imply the direction for MSRP, but I think one MSRP session can definitely imply a direction for a second MSRP session. > > Cheers, > Aki > > > > -----Original Message----- > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On > > Behalf Of > > ext Ben Campbell > > Sent: 15 December, 2003 23:20 > > To: Simple WG > > Subject: [Simple] MSRP: Some thoughts on session updates > > > > > > We have had a lot of discussion on how we deal with > > connection failures, > > session continuance across a failure, duplicate supression, > > etc. Much of > > that depends on how we handle session updates. Here are some > > thoughts > > for discussion. > > > > Although the sense of the room at IETF58 indicated we needed > > a way to > > re-establish TCP connections without resignaling, subsequent list > > discussion has indicated consensus that this will not work, > > and we will > > indeed have to re-signal. I am slightly concerned that many > > of those who > > favored reconnection without resignaling at the meeting have not > > participated in the email thread. I must assume that means > > they agree ;-) > > > > Obviously resignaling means a new SDP exchange. For SIP, > > that would mean > > a re-INVITE or an UPDATE. Since the MSRP spec only tangentally talks > > about sip, I think the re-INVITE vs UPDATE question is out > > of scope, and > > is treated sufficiently well in the UPDATE rfc. > > > > So, here are some assumptions and observations about how an updated > > offer/answer would work. > > > > 0) We don't have to worry about early media. (I expect this to be > > controversial, but I can always hope. The following are > > based on that > > assumption.) > > > > 1) The active party must remain the active party. If the > > active party > > initiates an updated offer, it MUST NOT contain a session URL. > > > > 2) The passive party must remain the passive party. If the > > passive party > > initates an updated offer, it MUST contain a session URL. > > This updated > > URL may be the same as before, or may be completely different, even > > pointing to a completely different location. > > > > 3)If the passive party sends an updated offer with a semantically > > identical URL as the original, this indicates no change. (I > > don't know > > why you would do this, but Paul asked for an example of an > > update that > > changes nothing.) Interestingly, the active party _cannot_ send an > > updated without giving the active party a chance to provide a new > > session URL. > > > > 4) A corrolary of 1) and 2) is that direction=both would not be > > permitted for an update. > > > > 5) Updated offers can occur for both healthy sessions and as > > a result of > > connection failures, etc. > > > > Thoughts? > > > > Ben. > > > > > > _______________________________________________ > > 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-admin@ietf.org Tue Dec 16 10:47:13 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19764 for ; Tue, 16 Dec 2003 10:47:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHPm-0006LE-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:47:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHPc-0006JA-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:47:14 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWHPb-0006IZ-00; Tue, 16 Dec 2003 10:47:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWHPE-0003IG-LQ; Tue, 16 Dec 2003 10:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHOc-0006fT-S0; Tue, 16 Dec 2003 10:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHNo-0006Xt-MN for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:45:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19483 for ; Tue, 16 Dec 2003 10:45:08 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHNm-00060G-00 for simple@ietf.org; Tue, 16 Dec 2003 10:45:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHNg-0005z5-00 for simple@ietf.org; Tue, 16 Dec 2003 10:45:09 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWHNf-0005yk-00 for simple@ietf.org; Tue, 16 Dec 2003 10:45:04 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFj2724570 for ; Tue, 16 Dec 2003 17:45:02 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:45:02 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:45:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D9252@esebe013.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPD6vkes71bZffPS3OWLIj4z4qDtAAADaAA To: Cc: X-OriginalArrivalTime: 16 Dec 2003 15:45:01.0167 (UTC) FILETIME=[90DD77F0:01C3C3EB] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:45:00 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Ben Campbell wrote: > > Because, it makes little sense to repeat a "offer both->=20 > try active and fail -> answer passive" sequence for each new=20 > MSRP component added to a session. This is an additional=20 > benefit we would get by the below restrictions, which is a=20 > good thing. Of course, this would not allow negotiating=20 > 'direction' per MSRP session inside a SIP dialog, but I=20 > don't see much use for that anyway. >=20 > I think I agree, as long as we are only talking about MSRP=20 > sessions. I=20 > don't think the direction of some other kind connection=20 > oriented media=20 > session would necessarily imply the direction for MSRP, but=20 > I think one=20 > MSRP session can definitely imply a direction for a second=20 > MSRP session. Definitely agree that this would only apply to MSRP. Other connection = oriented medias (or indeed the COMEDIA stuff in general) may define = their own ways for handling this.=20 Cheers, Aki >=20 >=20 > >=20 > > Cheers, > > Aki > >=20 > >=20 > > > -----Original Message----- > > > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On=20 > > > Behalf Of > > > ext Ben Campbell > > > Sent: 15 December, 2003 23:20 > > > To: Simple WG > > > Subject: [Simple] MSRP: Some thoughts on session updates > > >=20 > > >=20 > > > We have had a lot of discussion on how we deal with=20 > > > connection failures,=20 > > > session continuance across a failure, duplicate supression,=20 > > > etc. Much of=20 > > > that depends on how we handle session updates. Here are some=20 > > > thoughts=20 > > > for discussion. > > >=20 > > > Although the sense of the room at IETF58 indicated we needed=20 > > > a way to=20 > > > re-establish TCP connections without resignaling,=20 > subsequent list=20 > > > discussion has indicated consensus that this will not work,=20 > > > and we will=20 > > > indeed have to re-signal. I am slightly concerned that many=20 > > > of those who=20 > > > favored reconnection without resignaling at the meeting=20 > have not=20 > > > participated in the email thread. I must assume that means=20 > > > they agree ;-) > > >=20 > > > Obviously resignaling means a new SDP exchange. For SIP,=20 > > > that would mean=20 > > > a re-INVITE or an UPDATE. Since the MSRP spec only=20 > tangentally talks=20 > > > about sip, I think the re-INVITE vs UPDATE question is out=20 > > > of scope, and=20 > > > is treated sufficiently well in the UPDATE rfc. > > >=20 > > > So, here are some assumptions and observations about=20 > how an updated=20 > > > offer/answer would work. > > >=20 > > > 0) We don't have to worry about early media. (I expect=20 > this to be=20 > > > controversial, but I can always hope. The following are=20 > > > based on that=20 > > > assumption.) > > >=20 > > > 1) The active party must remain the active party. If the=20 > > > active party=20 > > > initiates an updated offer, it MUST NOT contain a session URL. > > >=20 > > > 2) The passive party must remain the passive party. If the=20 > > > passive party=20 > > > initates an updated offer, it MUST contain a session URL.=20 > > > This updated=20 > > > URL may be the same as before, or may be completely=20 > different, even=20 > > > pointing to a completely different location. > > >=20 > > > 3)If the passive party sends an updated offer with a=20 > semantically=20 > > > identical URL as the original, this indicates no change. (I=20 > > > don't know=20 > > > why you would do this, but Paul asked for an example of an=20 > > > update that=20 > > > changes nothing.) Interestingly, the active party=20 > _cannot_ send an=20 > > > updated without giving the active party a chance to=20 > provide a new=20 > > > session URL. > > >=20 > > > 4) A corrolary of 1) and 2) is that direction=3Dboth would not = be=20 > > > permitted for an update. > > >=20 > > > 5) Updated offers can occur for both healthy sessions and as=20 > > > a result of=20 > > > connection failures, etc. > > >=20 > > > Thoughts? > > >=20 > > > Ben. > > >=20 > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 10:56:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21045 for ; Tue, 16 Dec 2003 10:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHYM-0007fR-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHYJ-0007ev-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 10:56:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHYJ-0007es-00; Tue, 16 Dec 2003 10:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHYH-000833-5c; Tue, 16 Dec 2003 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHXh-0007zR-1S for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20888 for ; Tue, 16 Dec 2003 10:55:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHXe-0007UZ-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHXc-0007UL-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWHXb-0007U4-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:20 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFtIJ29496 for ; Tue, 16 Dec 2003 17:55:18 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:55:18 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:55:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPD4v/J8A0t8ovfQXqCPmHnf5TyMgACI+UQ To: Cc: X-OriginalArrivalTime: 16 Dec 2003 15:55:17.0521 (UTC) FILETIME=[003DA010:01C3C3ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:55:16 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 16.December.2003 16:26 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I also agree, but I require a clarification, see inline... > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 15.December.2003 23:20 > >>To: Simple WG > >>Subject: [Simple] MSRP: Some thoughts on session updates > >> > >> > >>We have had a lot of discussion on how we deal with=20 > >>connection failures,=20 > >>session continuance across a failure, duplicate supression,=20 > >>etc. Much of=20 > >>that depends on how we handle session updates. Here are=20 > some thoughts=20 > >>for discussion. > >> > >>Although the sense of the room at IETF58 indicated we=20 > needed a way to=20 > >>re-establish TCP connections without resignaling, subsequent list=20 > >>discussion has indicated consensus that this will not work,=20 > >>and we will=20 > >>indeed have to re-signal. I am slightly concerned that many=20 > >>of those who=20 > >>favored reconnection without resignaling at the meeting have not=20 > >>participated in the email thread. I must assume that means=20 > >>they agree ;-) > >> > >>Obviously resignaling means a new SDP exchange. For SIP, that=20 > >>would mean=20 > >>a re-INVITE or an UPDATE. Since the MSRP spec only=20 > tangentally talks=20 > >>about sip, I think the re-INVITE vs UPDATE question is out of=20 > >>scope, and=20 > >>is treated sufficiently well in the UPDATE rfc. > >> > >>So, here are some assumptions and observations about how an updated=20 > >>offer/answer would work. > >> > >>0) We don't have to worry about early media. (I expect this to be=20 > >>controversial, but I can always hope. The following are=20 > based on that=20 > >>assumption.) > >> > >>1) The active party must remain the active party. If the=20 > active party=20 > >>initiates an updated offer, it MUST NOT contain a session URL. > >> > >>2) The passive party must remain the passive party. If the=20 > >>passive party=20 > >>initates an updated offer, it MUST contain a session URL.=20 > >>This updated=20 > >>URL may be the same as before, or may be completely different, even=20 > >>pointing to a completely different location. > >> > >>3)If the passive party sends an updated offer with a semantically=20 > >>identical URL as the original, this indicates no change. (I=20 > >>don't know=20 > >>why you would do this, but Paul asked for an example of an=20 > >>update that=20 > >>changes nothing.) Interestingly, the active party _cannot_ send an=20 > >>updated without giving the active party a chance to provide a new=20 > >>session URL. > >=20 > >=20 > > I assume you mean "without giving the passive party a chance...". >=20 > Uhm, yes. Sorry. >=20 > >=20 > > In this case, do you think that 1) will ever happen? Why=20 > can't the active party send an update without first the=20 > passive party providing a new session URL? > >=20 > > Or have I missed your point? >=20 > I think you missed the point. It can send an update without=20 > the passive=20 > party first supplying a new URL. Basically, it works like this: >=20 > Active Passive > new offer (no url)-------> > <-----resp (may have URL)- >=20 > So, when the active party sends an update, without a URL, the passive=20 > party may or may not send a new URL back. The active party cannot=20 > prevent the passive party from doing so. What would the active party do with this URL if it came in the SDP = answer from the passive party? >=20 > It occurs to me their may be a problem here. If the active party is=20 > sending an update because it has detected a connection=20 > failure, it may=20 > need a way to _insist_ on a new URL. If the passive party has not yet=20 > noticed the failure, it cannot tell the difference between a=20 > "no change"=20 > update and a "connection broken" update. The passive party should notice since I would assume the active party is = sending an updated offer with a new m-line. The old m-line port is set = to 0. It is a new MSRP session and therefore needs a new media line. You = cannot use an already existing m-line if it has not bee n perviously = disabled by setting the port to 0. Regards, Hisham >=20 > >=20 > > /Hisham > >=20 > >=20 > >>4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > >>permitted for an update. > >> > >>5) Updated offers can occur for both healthy sessions and as=20 > >>a result of=20 > >>connection failures, etc. > >> > >>Thoughts? > >> > >>Ben. > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 10:56:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21130 for ; Tue, 16 Dec 2003 10:56:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHYT-00087R-3H for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:56:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGFuDZa031203 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 10:56:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHYS-00087C-W1 for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 10:56:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21071 for ; Tue, 16 Dec 2003 10:56:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHYQ-0007g3-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:56:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHYN-0007fW-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 10:56:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHYJ-0007es-00; Tue, 16 Dec 2003 10:56:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHYH-000833-5c; Tue, 16 Dec 2003 10:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHXh-0007zR-1S for simple@optimus.ietf.org; Tue, 16 Dec 2003 10:55:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20888 for ; Tue, 16 Dec 2003 10:55:20 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHXe-0007UZ-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHXc-0007UL-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:21 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWHXb-0007U4-00 for simple@ietf.org; Tue, 16 Dec 2003 10:55:20 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFtIJ29496 for ; Tue, 16 Dec 2003 17:55:18 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:55:18 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:55:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPD4v/J8A0t8ovfQXqCPmHnf5TyMgACI+UQ To: Cc: X-OriginalArrivalTime: 16 Dec 2003 15:55:17.0521 (UTC) FILETIME=[003DA010:01C3C3ED] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:55:16 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 16.December.2003 16:26 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > hisham.khartabil@nokia.com wrote: >=20 > > I also agree, but I require a clarification, see inline... > >=20 > >=20 > >>-----Original Message----- > >>From: simple-admin@ietf.org=20 > [mailto:simple-admin@ietf.org]On Behalf Of > >>ext Ben Campbell > >>Sent: 15.December.2003 23:20 > >>To: Simple WG > >>Subject: [Simple] MSRP: Some thoughts on session updates > >> > >> > >>We have had a lot of discussion on how we deal with=20 > >>connection failures,=20 > >>session continuance across a failure, duplicate supression,=20 > >>etc. Much of=20 > >>that depends on how we handle session updates. Here are=20 > some thoughts=20 > >>for discussion. > >> > >>Although the sense of the room at IETF58 indicated we=20 > needed a way to=20 > >>re-establish TCP connections without resignaling, subsequent list=20 > >>discussion has indicated consensus that this will not work,=20 > >>and we will=20 > >>indeed have to re-signal. I am slightly concerned that many=20 > >>of those who=20 > >>favored reconnection without resignaling at the meeting have not=20 > >>participated in the email thread. I must assume that means=20 > >>they agree ;-) > >> > >>Obviously resignaling means a new SDP exchange. For SIP, that=20 > >>would mean=20 > >>a re-INVITE or an UPDATE. Since the MSRP spec only=20 > tangentally talks=20 > >>about sip, I think the re-INVITE vs UPDATE question is out of=20 > >>scope, and=20 > >>is treated sufficiently well in the UPDATE rfc. > >> > >>So, here are some assumptions and observations about how an updated=20 > >>offer/answer would work. > >> > >>0) We don't have to worry about early media. (I expect this to be=20 > >>controversial, but I can always hope. The following are=20 > based on that=20 > >>assumption.) > >> > >>1) The active party must remain the active party. If the=20 > active party=20 > >>initiates an updated offer, it MUST NOT contain a session URL. > >> > >>2) The passive party must remain the passive party. If the=20 > >>passive party=20 > >>initates an updated offer, it MUST contain a session URL.=20 > >>This updated=20 > >>URL may be the same as before, or may be completely different, even=20 > >>pointing to a completely different location. > >> > >>3)If the passive party sends an updated offer with a semantically=20 > >>identical URL as the original, this indicates no change. (I=20 > >>don't know=20 > >>why you would do this, but Paul asked for an example of an=20 > >>update that=20 > >>changes nothing.) Interestingly, the active party _cannot_ send an=20 > >>updated without giving the active party a chance to provide a new=20 > >>session URL. > >=20 > >=20 > > I assume you mean "without giving the passive party a chance...". >=20 > Uhm, yes. Sorry. >=20 > >=20 > > In this case, do you think that 1) will ever happen? Why=20 > can't the active party send an update without first the=20 > passive party providing a new session URL? > >=20 > > Or have I missed your point? >=20 > I think you missed the point. It can send an update without=20 > the passive=20 > party first supplying a new URL. Basically, it works like this: >=20 > Active Passive > new offer (no url)-------> > <-----resp (may have URL)- >=20 > So, when the active party sends an update, without a URL, the passive=20 > party may or may not send a new URL back. The active party cannot=20 > prevent the passive party from doing so. What would the active party do with this URL if it came in the SDP = answer from the passive party? >=20 > It occurs to me their may be a problem here. If the active party is=20 > sending an update because it has detected a connection=20 > failure, it may=20 > need a way to _insist_ on a new URL. If the passive party has not yet=20 > noticed the failure, it cannot tell the difference between a=20 > "no change"=20 > update and a "connection broken" update. The passive party should notice since I would assume the active party is = sending an updated offer with a new m-line. The old m-line port is set = to 0. It is a new MSRP session and therefore needs a new media line. You = cannot use an already existing m-line if it has not bee n perviously = disabled by setting the port to 0. Regards, Hisham >=20 > >=20 > > /Hisham > >=20 > >=20 > >>4) A corrolary of 1) and 2) is that direction=3Dboth would not be=20 > >>permitted for an update. > >> > >>5) Updated offers can occur for both healthy sessions and as=20 > >>a result of=20 > >>connection failures, etc. > >> > >>Thoughts? > >> > >>Ben. > >> > >> > >>_______________________________________________ > >>Simple mailing list > >>Simple@ietf.org > >>https://www1.ietf.org/mailman/listinfo/simple > >> >=20 >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 11:06:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21503 for ; Tue, 16 Dec 2003 11:06:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHi2-0000NA-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:06:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHi1-0000N3-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:06:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHi1-0000N0-00; Tue, 16 Dec 2003 11:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHhx-00006g-GH; Tue, 16 Dec 2003 11:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHh6-00005j-37 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21452 for ; Tue, 16 Dec 2003 11:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHh3-0000Jl-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHh2-0000Je-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:05 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHh2-0000Ja-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:04 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGG4vnG018336; Tue, 16 Dec 2003 10:05:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF2D21.2000305@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:04:49 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: [...]It can send an update without >>the passive >>party first supplying a new URL. Basically, it works like this: >> >>Active Passive >> new offer (no url)-------> >> <-----resp (may have URL)- >> >>So, when the active party sends an update, without a URL, the passive >>party may or may not send a new URL back. The active party cannot >>prevent the passive party from doing so. > > > What would the active party do with this URL if it came in the SDP answer from the passive party? > I think it would visit the new URL. (i.e. resolve the URL, connect, visit, etc.) The interesting question to me is, if it thinks the old connection is still good, does it disconnect from it? And if so, does it need to wait for the new visit to succeed first? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 11:06:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21553 for ; Tue, 16 Dec 2003 11:06:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHiI-0000Cw-1r for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:06:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGG6MTK000788 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHiH-0000Cd-Ur for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:06:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21519 for ; Tue, 16 Dec 2003 11:06:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHi3-0000NL-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:06:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHi2-0000NE-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:06:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHi1-0000N0-00; Tue, 16 Dec 2003 11:06:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHhx-00006g-GH; Tue, 16 Dec 2003 11:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHh6-00005j-37 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:05:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21452 for ; Tue, 16 Dec 2003 11:05:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHh3-0000Jl-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHh2-0000Je-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:05 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHh2-0000Ja-00 for simple@ietf.org; Tue, 16 Dec 2003 11:05:04 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGG4vnG018336; Tue, 16 Dec 2003 10:05:03 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF2D21.2000305@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:04:49 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: [...]It can send an update without >>the passive >>party first supplying a new URL. Basically, it works like this: >> >>Active Passive >> new offer (no url)-------> >> <-----resp (may have URL)- >> >>So, when the active party sends an update, without a URL, the passive >>party may or may not send a new URL back. The active party cannot >>prevent the passive party from doing so. > > > What would the active party do with this URL if it came in the SDP answer from the passive party? > I think it would visit the new URL. (i.e. resolve the URL, connect, visit, etc.) The interesting question to me is, if it thinks the old connection is still good, does it disconnect from it? And if so, does it need to wait for the new visit to succeed first? _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 11:15:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21806 for ; Tue, 16 Dec 2003 11:15:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHqk-0000iz-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:15:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHqj-0000is-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:15:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHqj-0000ip-00; Tue, 16 Dec 2003 11:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHqh-00012E-0e; Tue, 16 Dec 2003 11:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHq5-00011G-64 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:14:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21789 for ; Tue, 16 Dec 2003 11:14:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHq4-0000hX-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHq3-0000hN-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWHq2-0000hA-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:23 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGGELJ24661 for ; Tue, 16 Dec 2003 18:14:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 18:14:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 18:14:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPD7oHqYC6jbFqnT3uYQaSyTXMpTQAALC3g To: Cc: X-OriginalArrivalTime: 16 Dec 2003 16:14:21.0417 (UTC) FILETIME=[AA0E4D90:01C3C3EF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 18:14:21 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 16.December.2003 18:05 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > hisham.khartabil@nokia.com wrote: > [...]It can send an update without > >>the passive=20 > >>party first supplying a new URL. Basically, it works like this: > >> > >>Active Passive > >> new offer (no url)-------> > >> <-----resp (may have URL)- > >> > >>So, when the active party sends an update, without a URL,=20 > the passive=20 > >>party may or may not send a new URL back. The active party cannot=20 > >>prevent the passive party from doing so. > >=20 > >=20 > > What would the active party do with this URL if it came in=20 > the SDP answer from the passive party? > >=20 >=20 > I think it would visit the new URL. (i.e. resolve the URL, connect,=20 > visit, etc.) The interesting question to me is, if it thinks the old=20 > connection is still good, does it disconnect from it? And if=20 > so, does it=20 > need to wait for the new visit to succeed first? As I said in the previous email (I'm not sure if you read down that far = :) The new offer sent by the active party will contain a new media line = (m-line), the old m-line would have the port set to 0 disabling it. This = is how the passive party knows that it needs to disconnect from the old = one. /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 11:15:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21829 for ; Tue, 16 Dec 2003 11:15:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHqm-00014E-P1 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:15:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGF8Dw004096 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHqm-00013z-La for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21822 for ; Tue, 16 Dec 2003 11:15:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHql-0000jA-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHqk-0000j3-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:15:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHqj-0000ip-00; Tue, 16 Dec 2003 11:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHqh-00012E-0e; Tue, 16 Dec 2003 11:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHq5-00011G-64 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:14:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21789 for ; Tue, 16 Dec 2003 11:14:22 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHq4-0000hX-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHq3-0000hN-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:23 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWHq2-0000hA-00 for simple@ietf.org; Tue, 16 Dec 2003 11:14:23 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGGELJ24661 for ; Tue, 16 Dec 2003 18:14:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 18:14:21 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 18:14:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPD7oHqYC6jbFqnT3uYQaSyTXMpTQAALC3g To: Cc: X-OriginalArrivalTime: 16 Dec 2003 16:14:21.0417 (UTC) FILETIME=[AA0E4D90:01C3C3EF] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 18:14:21 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 16.December.2003 18:05 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 > hisham.khartabil@nokia.com wrote: > [...]It can send an update without > >>the passive=20 > >>party first supplying a new URL. Basically, it works like this: > >> > >>Active Passive > >> new offer (no url)-------> > >> <-----resp (may have URL)- > >> > >>So, when the active party sends an update, without a URL,=20 > the passive=20 > >>party may or may not send a new URL back. The active party cannot=20 > >>prevent the passive party from doing so. > >=20 > >=20 > > What would the active party do with this URL if it came in=20 > the SDP answer from the passive party? > >=20 >=20 > I think it would visit the new URL. (i.e. resolve the URL, connect,=20 > visit, etc.) The interesting question to me is, if it thinks the old=20 > connection is still good, does it disconnect from it? And if=20 > so, does it=20 > need to wait for the new visit to succeed first? As I said in the previous email (I'm not sure if you read down that far = :) The new offer sent by the active party will contain a new media line = (m-line), the old m-line would have the port set to 0 disabling it. This = is how the passive party knows that it needs to disconnect from the old = one. /Hisham >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 11:20:11 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21947 for ; Tue, 16 Dec 2003 11:20:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHvg-0000sM-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:20:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHve-0000sD-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:20:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHve-0000sA-00; Tue, 16 Dec 2003 11:20:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHvX-0001KA-1J; Tue, 16 Dec 2003 11:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHv0-0001DY-77 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:19:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21920 for ; Tue, 16 Dec 2003 11:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHuz-0000rF-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHuy-0000r7-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:28 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHux-0000r4-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:27 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGGJKnG019483; Tue, 16 Dec 2003 10:19:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF307B.2060904@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:19:07 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 16.December.2003 18:05 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP: Some thoughts on session updates >> >> >>hisham.khartabil@nokia.com wrote: >>[...]It can send an update without >> >>>>the passive >>>>party first supplying a new URL. Basically, it works like this: >>>> >>>>Active Passive >>>> new offer (no url)-------> >>>> <-----resp (may have URL)- >>>> >>>>So, when the active party sends an update, without a URL, >> >>the passive >> >>>>party may or may not send a new URL back. The active party cannot >>>>prevent the passive party from doing so. >>> >>> >>>What would the active party do with this URL if it came in >> >>the SDP answer from the passive party? >> >>I think it would visit the new URL. (i.e. resolve the URL, connect, >>visit, etc.) The interesting question to me is, if it thinks the old >>connection is still good, does it disconnect from it? And if >>so, does it >>need to wait for the new visit to succeed first? > > > As I said in the previous email (I'm not sure if you read down that far :) The new offer sent by the active party will contain a new media line (m-line), the old m-line would have the port set to 0 disabling it. This is how the passive party knows that it needs to disconnect from the old one. Oops, sorry. My mail reader (thunderbird) seems to forget to put in the vertical scroll bar sometimes. And even when it does, sometimes I forget to notice :-) > > /Hisham > > >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 11:20:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21999 for ; Tue, 16 Dec 2003 11:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHvk-0001Og-DE for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:20:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGKG6h005367 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHvj-0001OS-21 for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:20:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21970 for ; Tue, 16 Dec 2003 11:20:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHvh-0000sc-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:20:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHvg-0000sV-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:20:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWHve-0000sA-00; Tue, 16 Dec 2003 11:20:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHvX-0001KA-1J; Tue, 16 Dec 2003 11:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWHv0-0001DY-77 for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:19:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21920 for ; Tue, 16 Dec 2003 11:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWHuz-0000rF-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWHuy-0000r7-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:28 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWHux-0000r4-00 for simple@ietf.org; Tue, 16 Dec 2003 11:19:27 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBGGJKnG019483; Tue, 16 Dec 2003 10:19:26 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FDF307B.2060904@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797531@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:19:07 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>-----Original Message----- >>From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] >>Sent: 16.December.2003 18:05 >>To: Khartabil Hisham (NMP-MSW/Helsinki) >>Cc: simple@ietf.org >>Subject: Re: [Simple] MSRP: Some thoughts on session updates >> >> >>hisham.khartabil@nokia.com wrote: >>[...]It can send an update without >> >>>>the passive >>>>party first supplying a new URL. Basically, it works like this: >>>> >>>>Active Passive >>>> new offer (no url)-------> >>>> <-----resp (may have URL)- >>>> >>>>So, when the active party sends an update, without a URL, >> >>the passive >> >>>>party may or may not send a new URL back. The active party cannot >>>>prevent the passive party from doing so. >>> >>> >>>What would the active party do with this URL if it came in >> >>the SDP answer from the passive party? >> >>I think it would visit the new URL. (i.e. resolve the URL, connect, >>visit, etc.) The interesting question to me is, if it thinks the old >>connection is still good, does it disconnect from it? And if >>so, does it >>need to wait for the new visit to succeed first? > > > As I said in the previous email (I'm not sure if you read down that far :) The new offer sent by the active party will contain a new media line (m-line), the old m-line would have the port set to 0 disabling it. This is how the passive party knows that it needs to disconnect from the old one. Oops, sorry. My mail reader (thunderbird) seems to forget to put in the vertical scroll bar sometimes. And even when it does, sometimes I forget to notice :-) > > /Hisham > > >> _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 11:39:01 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22784 for ; Tue, 16 Dec 2003 11:39:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIDv-0001fV-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:39:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIDt-0001fJ-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 11:39:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIDt-0001fG-00; Tue, 16 Dec 2003 11:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIDs-0002QZ-AX; Tue, 16 Dec 2003 11:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWID2-0002L7-Dr for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22719 for ; Tue, 16 Dec 2003 11:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWID1-0001cG-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWID0-0001c9-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:06 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AWICx-0001ab-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hBGGbNd25986 for ; Tue, 16 Dec 2003 10:37:23 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1071592642.976.21.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] IETF58 SIMPLE proceedings materials Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:37:22 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I've placed the materials that have been submitted to the proceedings at http://www.softarmor.com/simple/meets/ietf58/proceedings/ RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 11:39:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22815 for ; Tue, 16 Dec 2003 11:39:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIDx-0002Sg-Kf for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:39:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGGd5Dv009456 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 11:39:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIDx-0002SR-Fv for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 11:39:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22800 for ; Tue, 16 Dec 2003 11:39:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWIDw-0001fo-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:39:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWIDv-0001fZ-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 11:39:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWIDt-0001fG-00; Tue, 16 Dec 2003 11:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWIDs-0002QZ-AX; Tue, 16 Dec 2003 11:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWID2-0002L7-Dr for simple@optimus.ietf.org; Tue, 16 Dec 2003 11:38:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22719 for ; Tue, 16 Dec 2003 11:38:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWID1-0001cG-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWID0-0001c9-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:06 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AWICx-0001ab-00 for simple@ietf.org; Tue, 16 Dec 2003 11:38:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hBGGbNd25986 for ; Tue, 16 Dec 2003 10:37:23 -0600 From: Robert Sparks To: simple@ietf.org Content-Type: text/plain Message-Id: <1071592642.976.21.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] IETF58 SIMPLE proceedings materials Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:37:22 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I've placed the materials that have been submitted to the proceedings at http://www.softarmor.com/simple/meets/ietf58/proceedings/ RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 14:48:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29191 for ; Tue, 16 Dec 2003 14:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLAt-0007lz-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 14:48:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLAs-0007ls-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 14:48:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWLAs-0007lo-00; Tue, 16 Dec 2003 14:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLAm-0001mT-Tl; Tue, 16 Dec 2003 14:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWL9u-0001lD-NL for simple@optimus.ietf.org; Tue, 16 Dec 2003 14:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29162 for ; Tue, 16 Dec 2003 14:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWL9r-0007kx-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWL9q-0007kq-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:03 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AWL9q-0007k2-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:02 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBGJkDA3000459; Tue, 16 Dec 2003 13:46:18 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 13:46:13 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866F4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 13:46:06 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Joe: I think the fundamental disconnect here between what I was trying to say and what you are hearing is this: - the JID "adam@dynamicsoft.com" is NOT necessarily the same resource as "im:adam@dynamicsoft.com" - the JID "adam@dynamicsoft.com" is NOT necessarily the same resource as "sip:adam@dynamicsoft.com" - The resource "im:adam@dynamicsoft.com" is NOT necessarily the same resource as "sip:adam@dynamicsoft.com" So, for any solution to work, the SENDER must have the ability to select a *scheme* -- otherwise, there will be resources that the sender cannot contact. /a=20 > -----Original Message----- > From: Joe Hildebrand [mailto:JHildebrand@jabber.com] > Sent: Monday, December 15, 2003 17:33 > To: xmppwg@jabber.org; 'simple@ietf.org' > Subject: [xmppwg] RE: Action Item: character mappings for > interoperability >=20 >=20 > Hm. I guess I need to show more of my work. I had assumed=20 > that on the XMPP > side, the system entity that does server-to-server delivery=20 > would do either > something like draft-daigle-napstr-03.txt, or something even=20 > simpler, like > draft-ietf-impp-srv-04.txt, except with the "hard" DNS stuff=20 > moved to the > server. >=20 > 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) > 2) No? Ok, SRV: do you support SIMPLE? If so, where?=20 > (protocol transcode, > resend using SIMPLE) > 3) No? Ok, SRV: do you support Wireless Villiage? If so,=20 > where? (protocol > transcode, resend using the WV S2S protocol)=20 > 4) No? Ok, maybe you're an older or less sophisticated XMPP=20 > implementation. > I'll look up your A record, and connect on 5269/tcp. (resend=20 > using XMPP > S2S) >=20 > >=20 > And something similar on the SIMPLE side. More-or-less=20 > obviously, the order > of the above should be a policy decision on the part of an=20 > admin. Given > that, I'm not sure that allowing a user to explicitly go around the > site-wide policy is a good thing.=20 >=20 > Really, the only question I had was on step 2) above. If I=20 > determine that > the other side would rather talk SIMPLE than XMPP, what=20 > address do I put on > the message? sips: or im:? >=20 > --=20 > Joe Hildebrand >=20 > =20 >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > > Sent: Monday, December 15, 2003 2:52 PM > > To: Adam Roach > > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > > mappings for interoperability > >=20 > > Is the context of this thread IM only, or do we also care=20 > > about presence? I am not sure the issues are always exactly=20 > > the same, since IM addresses may be delivered as part of presence. > >=20 > > I wonder (vaguely) if draft-daigle-napstr-03.txt is=20 > applicable here.=20 > > Also, if I recall we _do_ have guidance on how to map an im:=20 > > url to a concrete service using SRV, don't we? It seems to me=20 > > that if I am a SIP user, the only real hope I have of=20 > > cross-protocol interoperability is to advertise a PRES or IM=20 > > URI. Other systems may be able to reach SIP URIs on an ad-hoc=20 > > basis, but the abstract schema provide a more general approach. > >=20 > > More inline: > >=20 > > Adam Roach wrote: > >=20 > > > I'm cross posting this to SIMPLE to help cross-pollinate=20 > some ideas=20 > > > here. > > >=20 > > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > > >=20 > > > [huge snip] > > >=20 > > >=20 > > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > > >>im:jos%c3%a9&b%c3%b3b@jabber.com > > >>(note for the MIME-impaired: that's jose' and bo'b) > > >> > > >>Actually, it's not clear to me from RFC 3428 whether I=20 > > should map into=20 > > >>sip:, sips: or im:; I could use some guidance here from=20 > the SIMPLE=20 > > >>folk. > > >=20 > > >=20 > > > Well, they're all (potentially) different namespaces. In=20 > > particular,=20 > > > there's nothing (other than a possible site-local policy)=20 > > that would=20 > > > ensure that "im:adam@dynamicsoft.com" would map to the=20 > same user as=20 > > > "sip:adam@dynamicsoft.com" -- so, you need to have some=20 > > mechanism by=20 > > > which a distinction is performed. I'll get to that in a second. > > >=20 > > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > > user: > > >=20 > > > Any resource described by a SIP URI can be > > > "upgraded" to a SIPS URI by just changing the scheme, if it is > > > desired to communicate with that resource securely. > > >=20 > > > So, when you get to a gateway that is going from XMPP to=20 > > SIP, I would=20 > > > posit that selection of "sip:" would be appropriate when=20 > SASL isn't=20 > > > being used on the XMPP side, and that "sips:" > > > would be appropriate when it is. > > >=20 > > > Now, for the issue I deferred: when a message arrives for a=20 > > jid, how=20 > > > do you know what to do with it? Let's imagine that I send=20 > > an IM (from=20 > > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > > understanding is correct, this *must* end up being routed to the=20 > > > server indicated by the xmpp-server SRV record for=20 > > "jabber.com." So...=20 > > > does that server attempt to deliver it to an XMPP account called=20 > > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > > "sip:JHildebrand@jabber.com"? > > >=20 > > > One answer would be "selection amongst those destinations=20 > > is going to=20 > > > be based on local configuration at the jabber.com XMPP=20 > > server, since=20 > > > it 'owns' the jabber.com namespace." And that would work,=20 > > sort of, and=20 > > > be consistent and simple. > > >=20 > > > But it's a very incomplete solution. > > >=20 > > > On a grander scale, we need to ask: if you are sitting at an XMPP = > > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > > "sip:adam@dynamicsoft.com", how do you do that? Can we=20 > assume that=20 > > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can=20 > > we assume=20 > > > that jabber.com is? Should this be able to work if the XMPP=20 > > to SIMPLE=20 > > > gateway is owned by yet a third domain? > > >=20 > > > I think all three solutions need to be possible. > > >=20 > > > We've already discussed how the first would work; that's easy. > > > The scheme to use in translation is a matter of the=20 > > destination server=20 > > > configuration, potentially selected on a user-by-user basis. > >=20 > > I'm not sure I agree on this. As you mention above, even if=20 > > dynamicsoft.com maintains an xmpp to simple gateway, there is=20 > > no reason to expect that you can infer an identifier that=20 > > makes sense to the xmpp side of the gateway from a SIP URI.=20 > > If dynamicsoft maintains such a gateway, then it would make=20 > > more sense to advertise an xmpp identity in addition to the=20 > > SIP identity, or perhaps an im: URI for both. > >=20 > > It seems to me that an xmpp device, presented with a SIP URI,=20 > > can do nothing intelligent with it beyond submitting it to=20 > > some xmpp-sip gateway that it _already_ knows about, and it=20 > > cannot use the SIP URI to discover that gateway. > > >=20 > > > The second would require some indication from your client to your = > > > server (the host indicated by the xmpp-client SRV record for > > > jabber.com) that you want to break out to a SIP network. > > > I don't know enough about the formatting of jids to propose=20 > > something=20 > > > ideal, but I would think that using some sort of=20 > locally-configured=20 > > > prefix would provide that sort of indication (e.g.=20 > sending an IM to=20 > > > "sip#x3A;adam@dynamicsoft.com" would indicate to your=20 > > server, by the=20 > > > presence of "sip#x3A;", that it should gateway to=20 > > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality = > > > instead of finding the XMPP server for dynamicsoft.com). In=20 > > this case,=20 > > > the proper scheme to use is explicitly indicated by the user. > > >=20 > > > The third case will require using a jid that explicitly=20 > > routes to the=20 > > > third-party gateway; for example,=20 > > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > > ugliness would be hidden behind some sort of user interface=20 > > construct=20 > > > that allows users to configure their default SIMPLE=20 > > gateway). For this=20 > > > case, the scheme is decided by the gateway itself, and will=20 > > typically=20 > > > be specific to the protocol mapping provided by that=20 > > gateway (i.e. a=20 > > > gateway that translates to SIMPLE will always use sip: or=20 > sips:, as=20 > > > appropriate). > > >=20 > > > At least, that's my two cents on the topic. > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > _______________________________________________ > xmppwg mailing list > xmppwg@jabber.org > https://jabberstudio.org/mailman/listinfo/xmppwg >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 14:48:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29216 for ; Tue, 16 Dec 2003 14:48:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLAz-0001nH-0U for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 14:48:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGJmCqX006891 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 14:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLAy-0001n4-T1 for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 14:48:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29197 for ; Tue, 16 Dec 2003 14:48:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLAw-0007mA-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 14:48:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLAu-0007m3-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 14:48:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWLAs-0007lo-00; Tue, 16 Dec 2003 14:48:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLAm-0001mT-Tl; Tue, 16 Dec 2003 14:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWL9u-0001lD-NL for simple@optimus.ietf.org; Tue, 16 Dec 2003 14:47:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29162 for ; Tue, 16 Dec 2003 14:47:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWL9r-0007kx-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWL9q-0007kq-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:03 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AWL9q-0007k2-00 for simple@ietf.org; Tue, 16 Dec 2003 14:47:02 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBGJkDA3000459; Tue, 16 Dec 2003 13:46:18 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 13:46:13 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866F4@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , xmppwg@jabber.org, "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 13:46:06 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Joe: I think the fundamental disconnect here between what I was trying to say and what you are hearing is this: - the JID "adam@dynamicsoft.com" is NOT necessarily the same resource as "im:adam@dynamicsoft.com" - the JID "adam@dynamicsoft.com" is NOT necessarily the same resource as "sip:adam@dynamicsoft.com" - The resource "im:adam@dynamicsoft.com" is NOT necessarily the same resource as "sip:adam@dynamicsoft.com" So, for any solution to work, the SENDER must have the ability to select a *scheme* -- otherwise, there will be resources that the sender cannot contact. /a=20 > -----Original Message----- > From: Joe Hildebrand [mailto:JHildebrand@jabber.com] > Sent: Monday, December 15, 2003 17:33 > To: xmppwg@jabber.org; 'simple@ietf.org' > Subject: [xmppwg] RE: Action Item: character mappings for > interoperability >=20 >=20 > Hm. I guess I need to show more of my work. I had assumed=20 > that on the XMPP > side, the system entity that does server-to-server delivery=20 > would do either > something like draft-daigle-napstr-03.txt, or something even=20 > simpler, like > draft-ietf-impp-srv-04.txt, except with the "hard" DNS stuff=20 > moved to the > server. >=20 > 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) > 2) No? Ok, SRV: do you support SIMPLE? If so, where?=20 > (protocol transcode, > resend using SIMPLE) > 3) No? Ok, SRV: do you support Wireless Villiage? If so,=20 > where? (protocol > transcode, resend using the WV S2S protocol)=20 > 4) No? Ok, maybe you're an older or less sophisticated XMPP=20 > implementation. > I'll look up your A record, and connect on 5269/tcp. (resend=20 > using XMPP > S2S) >=20 > >=20 > And something similar on the SIMPLE side. More-or-less=20 > obviously, the order > of the above should be a policy decision on the part of an=20 > admin. Given > that, I'm not sure that allowing a user to explicitly go around the > site-wide policy is a good thing.=20 >=20 > Really, the only question I had was on step 2) above. If I=20 > determine that > the other side would rather talk SIMPLE than XMPP, what=20 > address do I put on > the message? sips: or im:? >=20 > --=20 > Joe Hildebrand >=20 > =20 >=20 > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com]=20 > > Sent: Monday, December 15, 2003 2:52 PM > > To: Adam Roach > > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > > mappings for interoperability > >=20 > > Is the context of this thread IM only, or do we also care=20 > > about presence? I am not sure the issues are always exactly=20 > > the same, since IM addresses may be delivered as part of presence. > >=20 > > I wonder (vaguely) if draft-daigle-napstr-03.txt is=20 > applicable here.=20 > > Also, if I recall we _do_ have guidance on how to map an im:=20 > > url to a concrete service using SRV, don't we? It seems to me=20 > > that if I am a SIP user, the only real hope I have of=20 > > cross-protocol interoperability is to advertise a PRES or IM=20 > > URI. Other systems may be able to reach SIP URIs on an ad-hoc=20 > > basis, but the abstract schema provide a more general approach. > >=20 > > More inline: > >=20 > > Adam Roach wrote: > >=20 > > > I'm cross posting this to SIMPLE to help cross-pollinate=20 > some ideas=20 > > > here. > > >=20 > > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > > >=20 > > > [huge snip] > > >=20 > > >=20 > > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > > >>im:jos%c3%a9&b%c3%b3b@jabber.com > > >>(note for the MIME-impaired: that's jose' and bo'b) > > >> > > >>Actually, it's not clear to me from RFC 3428 whether I=20 > > should map into=20 > > >>sip:, sips: or im:; I could use some guidance here from=20 > the SIMPLE=20 > > >>folk. > > >=20 > > >=20 > > > Well, they're all (potentially) different namespaces. In=20 > > particular,=20 > > > there's nothing (other than a possible site-local policy)=20 > > that would=20 > > > ensure that "im:adam@dynamicsoft.com" would map to the=20 > same user as=20 > > > "sip:adam@dynamicsoft.com" -- so, you need to have some=20 > > mechanism by=20 > > > which a distinction is performed. I'll get to that in a second. > > >=20 > > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > > user: > > >=20 > > > Any resource described by a SIP URI can be > > > "upgraded" to a SIPS URI by just changing the scheme, if it is > > > desired to communicate with that resource securely. > > >=20 > > > So, when you get to a gateway that is going from XMPP to=20 > > SIP, I would=20 > > > posit that selection of "sip:" would be appropriate when=20 > SASL isn't=20 > > > being used on the XMPP side, and that "sips:" > > > would be appropriate when it is. > > >=20 > > > Now, for the issue I deferred: when a message arrives for a=20 > > jid, how=20 > > > do you know what to do with it? Let's imagine that I send=20 > > an IM (from=20 > > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > > understanding is correct, this *must* end up being routed to the=20 > > > server indicated by the xmpp-server SRV record for=20 > > "jabber.com." So...=20 > > > does that server attempt to deliver it to an XMPP account called=20 > > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > > "sip:JHildebrand@jabber.com"? > > >=20 > > > One answer would be "selection amongst those destinations=20 > > is going to=20 > > > be based on local configuration at the jabber.com XMPP=20 > > server, since=20 > > > it 'owns' the jabber.com namespace." And that would work,=20 > > sort of, and=20 > > > be consistent and simple. > > >=20 > > > But it's a very incomplete solution. > > >=20 > > > On a grander scale, we need to ask: if you are sitting at an XMPP = > > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > > "sip:adam@dynamicsoft.com", how do you do that? Can we=20 > assume that=20 > > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can=20 > > we assume=20 > > > that jabber.com is? Should this be able to work if the XMPP=20 > > to SIMPLE=20 > > > gateway is owned by yet a third domain? > > >=20 > > > I think all three solutions need to be possible. > > >=20 > > > We've already discussed how the first would work; that's easy. > > > The scheme to use in translation is a matter of the=20 > > destination server=20 > > > configuration, potentially selected on a user-by-user basis. > >=20 > > I'm not sure I agree on this. As you mention above, even if=20 > > dynamicsoft.com maintains an xmpp to simple gateway, there is=20 > > no reason to expect that you can infer an identifier that=20 > > makes sense to the xmpp side of the gateway from a SIP URI.=20 > > If dynamicsoft maintains such a gateway, then it would make=20 > > more sense to advertise an xmpp identity in addition to the=20 > > SIP identity, or perhaps an im: URI for both. > >=20 > > It seems to me that an xmpp device, presented with a SIP URI,=20 > > can do nothing intelligent with it beyond submitting it to=20 > > some xmpp-sip gateway that it _already_ knows about, and it=20 > > cannot use the SIP URI to discover that gateway. > > >=20 > > > The second would require some indication from your client to your = > > > server (the host indicated by the xmpp-client SRV record for > > > jabber.com) that you want to break out to a SIP network. > > > I don't know enough about the formatting of jids to propose=20 > > something=20 > > > ideal, but I would think that using some sort of=20 > locally-configured=20 > > > prefix would provide that sort of indication (e.g.=20 > sending an IM to=20 > > > "sip#x3A;adam@dynamicsoft.com" would indicate to your=20 > > server, by the=20 > > > presence of "sip#x3A;", that it should gateway to=20 > > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway functionality = > > > instead of finding the XMPP server for dynamicsoft.com). In=20 > > this case,=20 > > > the proper scheme to use is explicitly indicated by the user. > > >=20 > > > The third case will require using a jid that explicitly=20 > > routes to the=20 > > > third-party gateway; for example,=20 > > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > > ugliness would be hidden behind some sort of user interface=20 > > construct=20 > > > that allows users to configure their default SIMPLE=20 > > gateway). For this=20 > > > case, the scheme is decided by the gateway itself, and will=20 > > typically=20 > > > be specific to the protocol mapping provided by that=20 > > gateway (i.e. a=20 > > > gateway that translates to SIMPLE will always use sip: or=20 > sips:, as=20 > > > appropriate). > > >=20 > > > At least, that's my two cents on the topic. > > >=20 > > > /a > > >=20 > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > >=20 > >=20 > _______________________________________________ > xmppwg mailing list > xmppwg@jabber.org > https://jabberstudio.org/mailman/listinfo/xmppwg >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 15:53:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03322 for ; Tue, 16 Dec 2003 15:53:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMBo-000238-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 15:53:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMBm-000230-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 15:53:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMBm-00022w-00; Tue, 16 Dec 2003 15:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBh-0004b3-Fy; Tue, 16 Dec 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBG-0004Zc-6A for simple@optimus.ietf.org; Tue, 16 Dec 2003 15:52:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03274 for ; Tue, 16 Dec 2003 15:52:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMBE-00020H-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMBC-000209-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:32 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AWMBC-0001zB-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:30 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 13:49:12 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> From: Joe Hildebrand To: "'xmppwg@jabber.org'" , "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA03275 Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 13:49:11 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable You're right, that's our disconnect. I hadn't even considered that. Can you give me a concrete use case where I might want sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to differen= t entities? I can see the messages and presences addressed to the two following different paths, perhaps using different protocols, but I can't imagine a non-contrived reason for them going to completely different endpoints, or being for completely different system entities. In other words, it might be nice for completeness, but if it adds mad complexity, and no one will ever use it, is it worth the effort? --=20 Joe Hildebrand =20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com]=20 > Sent: Tuesday, December 16, 2003 12:46 PM > To: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > Subject: RE: [xmppwg] RE: Action Item: character mappings for=20 > interoperabi lity >=20 > Joe: >=20 > I think the fundamental disconnect here between what I was=20 > trying to say and what you are hearing is this: >=20 > - the JID "adam@dynamicsoft.com" is NOT necessarily > the same resource as "im:adam@dynamicsoft.com" >=20 > - the JID "adam@dynamicsoft.com" is NOT necessarily > the same resource as "sip:adam@dynamicsoft.com" >=20 > - The resource "im:adam@dynamicsoft.com" is NOT > necessarily the same resource as "sip:adam@dynamicsoft.com" >=20 > So, for any solution to work, the SENDER must have the=20 > ability to select a *scheme* -- otherwise, there will be=20 > resources that the sender cannot contact. >=20 > /a=20 >=20 > > -----Original Message----- > > From: Joe Hildebrand [mailto:JHildebrand@jabber.com] > > Sent: Monday, December 15, 2003 17:33 > > To: xmppwg@jabber.org; 'simple@ietf.org' > > Subject: [xmppwg] RE: Action Item: character mappings for=20 > > interoperability > >=20 > >=20 > > Hm. I guess I need to show more of my work. I had assumed that on=20 > > the XMPP side, the system entity that does server-to-server=20 > delivery=20 > > would do either something like draft-daigle-napstr-03.txt, or=20 > > something even simpler, like draft-ietf-impp-srv-04.txt,=20 > except with=20 > > the "hard" DNS stuff moved to the server. > >=20 > > 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) > > 2) No? Ok, SRV: do you support SIMPLE? If so, where?=20 > > (protocol transcode, > > resend using SIMPLE) > > 3) No? Ok, SRV: do you support Wireless Villiage? If so, where?=20 > > (protocol transcode, resend using the WV S2S protocol) > > 4) No? Ok, maybe you're an older or less sophisticated XMPP=20 > > implementation. > > I'll look up your A record, and connect on 5269/tcp. (resend using=20 > > XMPP > > S2S) > >=20 > > > >=20 > > And something similar on the SIMPLE side. More-or-less=20 > obviously, the=20 > > order of the above should be a policy decision on the part of an=20 > > admin. Given that, I'm not sure that allowing a user to=20 > explicitly go=20 > > around the site-wide policy is a good thing. > >=20 > > Really, the only question I had was on step 2) above. If I=20 > determine=20 > > that the other side would rather talk SIMPLE than XMPP,=20 > what address=20 > > do I put on the message? sips: or im:? > >=20 > > -- > > Joe Hildebrand > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: Monday, December 15, 2003 2:52 PM > > > To: Adam Roach > > > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > > > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > mappings=20 > > > for interoperability > > >=20 > > > Is the context of this thread IM only, or do we also care about=20 > > > presence? I am not sure the issues are always exactly the same,=20 > > > since IM addresses may be delivered as part of presence. > > >=20 > > > I wonder (vaguely) if draft-daigle-napstr-03.txt is > > applicable here.=20 > > > Also, if I recall we _do_ have guidance on how to map an im:=20 > > > url to a concrete service using SRV, don't we? It seems=20 > to me that=20 > > > if I am a SIP user, the only real hope I have of cross-protocol=20 > > > interoperability is to advertise a PRES or IM URI. Other=20 > systems may=20 > > > be able to reach SIP URIs on an ad-hoc basis, but the abstract=20 > > > schema provide a more general approach. > > >=20 > > > More inline: > > >=20 > > > Adam Roach wrote: > > >=20 > > > > I'm cross posting this to SIMPLE to help cross-pollinate > > some ideas > > > > here. > > > >=20 > > > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > > > >=20 > > > > [huge snip] > > > >=20 > > > >=20 > > > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > > > >>im:jos%c3%a9&b%c3%b3b@jabber.com > > > >>(note for the MIME-impaired: that's jose' and bo'b) > > > >> > > > >>Actually, it's not clear to me from RFC 3428 whether I > > > should map into > > > >>sip:, sips: or im:; I could use some guidance here from > > the SIMPLE > > > >>folk. > > > >=20 > > > >=20 > > > > Well, they're all (potentially) different namespaces. In > > > particular, > > > > there's nothing (other than a possible site-local policy) > > > that would > > > > ensure that "im:adam@dynamicsoft.com" would map to the > > same user as > > > > "sip:adam@dynamicsoft.com" -- so, you need to have some > > > mechanism by > > > > which a distinction is performed. I'll get to that in a second. > > > >=20 > > > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > > > user: > > > >=20 > > > > Any resource described by a SIP URI can be > > > > "upgraded" to a SIPS URI by just changing the=20 > scheme, if it is > > > > desired to communicate with that resource securely. > > > >=20 > > > > So, when you get to a gateway that is going from XMPP to > > > SIP, I would > > > > posit that selection of "sip:" would be appropriate when > > SASL isn't > > > > being used on the XMPP side, and that "sips:" > > > > would be appropriate when it is. > > > >=20 > > > > Now, for the issue I deferred: when a message arrives for a > > > jid, how > > > > do you know what to do with it? Let's imagine that I send > > > an IM (from > > > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > > > understanding is correct, this *must* end up being=20 > routed to the=20 > > > > server indicated by the xmpp-server SRV record for > > > "jabber.com." So...=20 > > > > does that server attempt to deliver it to an XMPP=20 > account called=20 > > > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > > > "sip:JHildebrand@jabber.com"? > > > >=20 > > > > One answer would be "selection amongst those destinations > > > is going to > > > > be based on local configuration at the jabber.com XMPP > > > server, since > > > > it 'owns' the jabber.com namespace." And that would work, > > > sort of, and > > > > be consistent and simple. > > > >=20 > > > > But it's a very incomplete solution. > > > >=20 > > > > On a grander scale, we need to ask: if you are sitting=20 > at an XMPP=20 > > > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > > > "sip:adam@dynamicsoft.com", how do you do that? Can we > > assume that > > > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can > > > we assume > > > > that jabber.com is? Should this be able to work if the XMPP > > > to SIMPLE > > > > gateway is owned by yet a third domain? > > > >=20 > > > > I think all three solutions need to be possible. > > > >=20 > > > > We've already discussed how the first would work; that's easy. > > > > The scheme to use in translation is a matter of the > > > destination server > > > > configuration, potentially selected on a user-by-user basis. > > >=20 > > > I'm not sure I agree on this. As you mention above, even if=20 > > > dynamicsoft.com maintains an xmpp to simple gateway, there is no=20 > > > reason to expect that you can infer an identifier that=20 > makes sense=20 > > > to the xmpp side of the gateway from a SIP URI. > > > If dynamicsoft maintains such a gateway, then it would make more=20 > > > sense to advertise an xmpp identity in addition to the=20 > SIP identity,=20 > > > or perhaps an im: URI for both. > > >=20 > > > It seems to me that an xmpp device, presented with a SIP=20 > URI, can do=20 > > > nothing intelligent with it beyond submitting it to some xmpp-sip=20 > > > gateway that it _already_ knows about, and it cannot use=20 > the SIP URI=20 > > > to discover that gateway. > > > >=20 > > > > The second would require some indication from your=20 > client to your=20 > > > > server (the host indicated by the xmpp-client SRV record for > > > > jabber.com) that you want to break out to a SIP network. > > > > I don't know enough about the formatting of jids to propose > > > something > > > > ideal, but I would think that using some sort of > > locally-configured > > > > prefix would provide that sort of indication (e.g.=20 > > sending an IM to > > > > "sip#x3A;adam@dynamicsoft.com" would indicate to your > > > server, by the > > > > presence of "sip#x3A;", that it should gateway to=20 > > > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway=20 > functionality=20 > > > > instead of finding the XMPP server for dynamicsoft.com). In > > > this case, > > > > the proper scheme to use is explicitly indicated by the user. > > > >=20 > > > > The third case will require using a jid that explicitly > > > routes to the > > > > third-party gateway; for example,=20 > > > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > > > ugliness would be hidden behind some sort of user interface > > > construct > > > > that allows users to configure their default SIMPLE > > > gateway). For this > > > > case, the scheme is decided by the gateway itself, and will > > > typically > > > > be specific to the protocol mapping provided by that > > > gateway (i.e. a > > > > gateway that translates to SIMPLE will always use sip: or > > sips:, as > > > > appropriate). > > > >=20 > > > > At least, that's my two cents on the topic. > > > >=20 > > > > /a > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > _______________________________________________ > > xmppwg mailing list > > xmppwg@jabber.org > > https://jabberstudio.org/mailman/listinfo/xmppwg > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 15:53:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03422 for ; Tue, 16 Dec 2003 15:53:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBt-0004ef-Qi for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 15:53:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGKrD2m017889 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 15:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBt-0004eS-HE for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 15:53:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03395 for ; Tue, 16 Dec 2003 15:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMBr-00023W-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 15:53:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMBo-00023D-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 15:53:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMBm-00022w-00; Tue, 16 Dec 2003 15:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBh-0004b3-Fy; Tue, 16 Dec 2003 15:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMBG-0004Zc-6A for simple@optimus.ietf.org; Tue, 16 Dec 2003 15:52:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03274 for ; Tue, 16 Dec 2003 15:52:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMBE-00020H-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMBC-000209-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:32 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AWMBC-0001zB-00 for simple@ietf.org; Tue, 16 Dec 2003 15:52:30 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Dec 2003 13:49:12 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> From: Joe Hildebrand To: "'xmppwg@jabber.org'" , "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA03275 Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 13:49:11 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You're right, that's our disconnect. I hadn't even considered that. Can you give me a concrete use case where I might want sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to differen= t entities? I can see the messages and presences addressed to the two following different paths, perhaps using different protocols, but I can't imagine a non-contrived reason for them going to completely different endpoints, or being for completely different system entities. In other words, it might be nice for completeness, but if it adds mad complexity, and no one will ever use it, is it worth the effort? --=20 Joe Hildebrand =20 > -----Original Message----- > From: Adam Roach [mailto:adam@dynamicsoft.com]=20 > Sent: Tuesday, December 16, 2003 12:46 PM > To: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > Subject: RE: [xmppwg] RE: Action Item: character mappings for=20 > interoperabi lity >=20 > Joe: >=20 > I think the fundamental disconnect here between what I was=20 > trying to say and what you are hearing is this: >=20 > - the JID "adam@dynamicsoft.com" is NOT necessarily > the same resource as "im:adam@dynamicsoft.com" >=20 > - the JID "adam@dynamicsoft.com" is NOT necessarily > the same resource as "sip:adam@dynamicsoft.com" >=20 > - The resource "im:adam@dynamicsoft.com" is NOT > necessarily the same resource as "sip:adam@dynamicsoft.com" >=20 > So, for any solution to work, the SENDER must have the=20 > ability to select a *scheme* -- otherwise, there will be=20 > resources that the sender cannot contact. >=20 > /a=20 >=20 > > -----Original Message----- > > From: Joe Hildebrand [mailto:JHildebrand@jabber.com] > > Sent: Monday, December 15, 2003 17:33 > > To: xmppwg@jabber.org; 'simple@ietf.org' > > Subject: [xmppwg] RE: Action Item: character mappings for=20 > > interoperability > >=20 > >=20 > > Hm. I guess I need to show more of my work. I had assumed that on=20 > > the XMPP side, the system entity that does server-to-server=20 > delivery=20 > > would do either something like draft-daigle-napstr-03.txt, or=20 > > something even simpler, like draft-ietf-impp-srv-04.txt,=20 > except with=20 > > the "hard" DNS stuff moved to the server. > >=20 > > 1) SRV: do you support XMPP? If so where? (resend using XMPP S2S) > > 2) No? Ok, SRV: do you support SIMPLE? If so, where?=20 > > (protocol transcode, > > resend using SIMPLE) > > 3) No? Ok, SRV: do you support Wireless Villiage? If so, where?=20 > > (protocol transcode, resend using the WV S2S protocol) > > 4) No? Ok, maybe you're an older or less sophisticated XMPP=20 > > implementation. > > I'll look up your A record, and connect on 5269/tcp. (resend using=20 > > XMPP > > S2S) > >=20 > > > >=20 > > And something similar on the SIMPLE side. More-or-less=20 > obviously, the=20 > > order of the above should be a policy decision on the part of an=20 > > admin. Given that, I'm not sure that allowing a user to=20 > explicitly go=20 > > around the site-wide policy is a good thing. > >=20 > > Really, the only question I had was on step 2) above. If I=20 > determine=20 > > that the other side would rather talk SIMPLE than XMPP,=20 > what address=20 > > do I put on the message? sips: or im:? > >=20 > > -- > > Joe Hildebrand > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > > Sent: Monday, December 15, 2003 2:52 PM > > > To: Adam Roach > > > Cc: 'Joe Hildebrand'; xmppwg@jabber.org; 'simple@ietf.org' > > > Subject: Re: [Simple] RE: [xmppwg] Action Item: character=20 > mappings=20 > > > for interoperability > > >=20 > > > Is the context of this thread IM only, or do we also care about=20 > > > presence? I am not sure the issues are always exactly the same,=20 > > > since IM addresses may be delivered as part of presence. > > >=20 > > > I wonder (vaguely) if draft-daigle-napstr-03.txt is > > applicable here.=20 > > > Also, if I recall we _do_ have guidance on how to map an im:=20 > > > url to a concrete service using SRV, don't we? It seems=20 > to me that=20 > > > if I am a SIP user, the only real hope I have of cross-protocol=20 > > > interoperability is to advertise a PRES or IM URI. Other=20 > systems may=20 > > > be able to reach SIP URIs on an ad-hoc basis, but the abstract=20 > > > schema provide a more general approach. > > >=20 > > > More inline: > > >=20 > > > Adam Roach wrote: > > >=20 > > > > I'm cross posting this to SIMPLE to help cross-pollinate > > some ideas > > > > here. > > > >=20 > > > > Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > > > >=20 > > > > [huge snip] > > > >=20 > > > >=20 > > > >>Example: jos=E9#26;b=F3b@jabber.com becomes=20 > > > >>im:jos%c3%a9&b%c3%b3b@jabber.com > > > >>(note for the MIME-impaired: that's jose' and bo'b) > > > >> > > > >>Actually, it's not clear to me from RFC 3428 whether I > > > should map into > > > >>sip:, sips: or im:; I could use some guidance here from > > the SIMPLE > > > >>folk. > > > >=20 > > > >=20 > > > > Well, they're all (potentially) different namespaces. In > > > particular, > > > > there's nothing (other than a possible site-local policy) > > > that would > > > > ensure that "im:adam@dynamicsoft.com" would map to the > > same user as > > > > "sip:adam@dynamicsoft.com" -- so, you need to have some > > > mechanism by > > > > which a distinction is performed. I'll get to that in a second. > > > >=20 > > > > By contrast, "sip:adam@dynamicsoft.com" and=20 > > > > "sips:adam@dynamicsoft.com" *will* always refer to the same > > > > user: > > > >=20 > > > > Any resource described by a SIP URI can be > > > > "upgraded" to a SIPS URI by just changing the=20 > scheme, if it is > > > > desired to communicate with that resource securely. > > > >=20 > > > > So, when you get to a gateway that is going from XMPP to > > > SIP, I would > > > > posit that selection of "sip:" would be appropriate when > > SASL isn't > > > > being used on the XMPP side, and that "sips:" > > > > would be appropriate when it is. > > > >=20 > > > > Now, for the issue I deferred: when a message arrives for a > > > jid, how > > > > do you know what to do with it? Let's imagine that I send > > > an IM (from > > > > an XMPP client) to the jid "JHildebrand@jabber.com". If my=20 > > > > understanding is correct, this *must* end up being=20 > routed to the=20 > > > > server indicated by the xmpp-server SRV record for > > > "jabber.com." So...=20 > > > > does that server attempt to deliver it to an XMPP=20 > account called=20 > > > > "JHildebrand@jabber.com"? Does it gateway it to=20 > > > > "im:JHildebrand@jabber.com"? Does it gateway it to=20 > > > > "sip:JHildebrand@jabber.com"? > > > >=20 > > > > One answer would be "selection amongst those destinations > > > is going to > > > > be based on local configuration at the jabber.com XMPP > > > server, since > > > > it 'owns' the jabber.com namespace." And that would work, > > > sort of, and > > > > be consistent and simple. > > > >=20 > > > > But it's a very incomplete solution. > > > >=20 > > > > On a grander scale, we need to ask: if you are sitting=20 > at an XMPP=20 > > > > client as "JHildebrand@jabber.com", and want to send an IM to=20 > > > > "sip:adam@dynamicsoft.com", how do you do that? Can we > > assume that > > > > "dynamicsoft.com" is running an XMPP to SIMPLE gateway? Can > > > we assume > > > > that jabber.com is? Should this be able to work if the XMPP > > > to SIMPLE > > > > gateway is owned by yet a third domain? > > > >=20 > > > > I think all three solutions need to be possible. > > > >=20 > > > > We've already discussed how the first would work; that's easy. > > > > The scheme to use in translation is a matter of the > > > destination server > > > > configuration, potentially selected on a user-by-user basis. > > >=20 > > > I'm not sure I agree on this. As you mention above, even if=20 > > > dynamicsoft.com maintains an xmpp to simple gateway, there is no=20 > > > reason to expect that you can infer an identifier that=20 > makes sense=20 > > > to the xmpp side of the gateway from a SIP URI. > > > If dynamicsoft maintains such a gateway, then it would make more=20 > > > sense to advertise an xmpp identity in addition to the=20 > SIP identity,=20 > > > or perhaps an im: URI for both. > > >=20 > > > It seems to me that an xmpp device, presented with a SIP=20 > URI, can do=20 > > > nothing intelligent with it beyond submitting it to some xmpp-sip=20 > > > gateway that it _already_ knows about, and it cannot use=20 > the SIP URI=20 > > > to discover that gateway. > > > >=20 > > > > The second would require some indication from your=20 > client to your=20 > > > > server (the host indicated by the xmpp-client SRV record for > > > > jabber.com) that you want to break out to a SIP network. > > > > I don't know enough about the formatting of jids to propose > > > something > > > > ideal, but I would think that using some sort of > > locally-configured > > > > prefix would provide that sort of indication (e.g.=20 > > sending an IM to > > > > "sip#x3A;adam@dynamicsoft.com" would indicate to your > > > server, by the > > > > presence of "sip#x3A;", that it should gateway to=20 > > > > "sip:adam@dynamicsoft.com" using its SIMPLE gateway=20 > functionality=20 > > > > instead of finding the XMPP server for dynamicsoft.com). In > > > this case, > > > > the proper scheme to use is explicitly indicated by the user. > > > >=20 > > > > The third case will require using a jid that explicitly > > > routes to the > > > > third-party gateway; for example,=20 > > > > "adam#40;dynamicsoft.com@simple.im-gateway.org". (Ideally, this=20 > > > > ugliness would be hidden behind some sort of user interface > > > construct > > > > that allows users to configure their default SIMPLE > > > gateway). For this > > > > case, the scheme is decided by the gateway itself, and will > > > typically > > > > be specific to the protocol mapping provided by that > > > gateway (i.e. a > > > > gateway that translates to SIMPLE will always use sip: or > > sips:, as > > > > appropriate). > > > >=20 > > > > At least, that's my two cents on the topic. > > > >=20 > > > > /a > > > >=20 > > > > _______________________________________________ > > > > Simple mailing list > > > > Simple@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/simple > > >=20 > > >=20 > > _______________________________________________ > > xmppwg mailing list > > xmppwg@jabber.org > > https://jabberstudio.org/mailman/listinfo/xmppwg > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 16 16:09:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05059 for ; Tue, 16 Dec 2003 16:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMRF-0002y7-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 16:09:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMRE-0002xy-00 for simple-archive@ietf.org; Tue, 16 Dec 2003 16:09:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMRE-0002xv-00; Tue, 16 Dec 2003 16:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMRB-0006M5-9T; Tue, 16 Dec 2003 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMQu-0006Jw-TT for simple@optimus.ietf.org; Tue, 16 Dec 2003 16:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04992 for ; Tue, 16 Dec 2003 16:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMQt-0002wj-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMQr-0002wc-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWMQr-0002q0-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBGL8Txg015241; Tue, 16 Dec 2003 16:08:29 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AES16662; Tue, 16 Dec 2003 16:08:28 -0500 (EST) Message-ID: <3FDF744C.3020604@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" References: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 16:08:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Joe, Having them be the same thing implies a degree of coordination that may not exist in all organizations. The different schemes may map to separate servers that are administered by separate organizations. If they had their act together they might use the same names, but you can never be sure. For instance, the people administering XMPP might assign the id of jsmith to John A Smit, but the people administering sip might give that id to John B Smith. Paul Joe Hildebrand wrote: > You're right, that's our disconnect. I hadn't even considered that. > > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to different > entities? I can see the messages and presences addressed to the two > following different paths, perhaps using different protocols, but I can't > imagine a non-contrived reason for them going to completely different > endpoints, or being for completely different system entities. > > In other words, it might be nice for completeness, but if it adds mad > complexity, and no one will ever use it, is it worth the effort? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 16 16:09:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05140 for ; Tue, 16 Dec 2003 16:09:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMRI-0006ND-Ej for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 16:09:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGL98CS024493 for simple-archive@odin.ietf.org; Tue, 16 Dec 2003 16:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMRI-0006My-B7 for simple-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:09:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05061 for ; Tue, 16 Dec 2003 16:09:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMRG-0002yJ-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 16:09:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMRF-0002yA-00 for simple-web-archive@ietf.org; Tue, 16 Dec 2003 16:09:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMRE-0002xv-00; Tue, 16 Dec 2003 16:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMRB-0006M5-9T; Tue, 16 Dec 2003 16:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMQu-0006Jw-TT for simple@optimus.ietf.org; Tue, 16 Dec 2003 16:08:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04992 for ; Tue, 16 Dec 2003 16:08:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMQt-0002wj-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMQr-0002wc-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:42 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWMQr-0002q0-00 for simple@ietf.org; Tue, 16 Dec 2003 16:08:41 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBGL8Txg015241; Tue, 16 Dec 2003 16:08:29 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AES16662; Tue, 16 Dec 2003 16:08:28 -0500 (EST) Message-ID: <3FDF744C.3020604@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" References: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Dec 2003 16:08:28 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe, Having them be the same thing implies a degree of coordination that may not exist in all organizations. The different schemes may map to separate servers that are administered by separate organizations. If they had their act together they might use the same names, but you can never be sure. For instance, the people administering XMPP might assign the id of jsmith to John A Smit, but the people administering sip might give that id to John B Smith. Paul Joe Hildebrand wrote: > You're right, that's our disconnect. I hadn't even considered that. > > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to different > entities? I can see the messages and presences addressed to the two > following different paths, perhaps using different protocols, but I can't > imagine a non-contrived reason for them going to completely different > endpoints, or being for completely different system entities. > > In other words, it might be nice for completeness, but if it adds mad > complexity, and no one will ever use it, is it worth the effort? > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 12:22:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21173 for ; Wed, 17 Dec 2003 12:22:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfNC-0007ON-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 12:22:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfNB-0007OF-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 12:22:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWfNB-0007OC-00; Wed, 17 Dec 2003 12:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfN2-0005Dd-Nu; Wed, 17 Dec 2003 12:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfM5-0005CV-4f for simple@optimus.ietf.org; Wed, 17 Dec 2003 12:21:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21142 for ; Wed, 17 Dec 2003 12:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfM3-0007Nd-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfM2-0007NW-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:59 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AWfM2-0007MX-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:58 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBHHKEA3020561; Wed, 17 Dec 2003 11:20:14 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 11:20:13 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866FC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , "'xmppwg@jabber.org'" , "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 11:20:12 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point > to different entities? I can see the messages and presences > addressed to the two following different paths, perhaps > using different protocols, but I can't imagine a non-contrived > reason for them going to completely different endpoints, or > being for completely different system entities. Paul did a fairly good job of explaining how this sort of thing happens. I just wanted to make two additional points. To give a concrete example that may make more sense to you, the statements that I made are essentially the same as saying: - the JID "JHildebrand@corp.jabber.com" is NOT necessarily the same resource as "mailto:JHildebrand@corp.jabber.com" I note that you *tend* to make a distinction between the JID "JHildebrand@corp.jabber.com" and the URI "mailto:JHildebrand@jabber.com" when you write JEPs (cf. JEP-0115). The second point I wanted to make is: > The people administering the IM systems are typically going to be the same -- or at least, the same kind of -- people who administer the DNS. If you can't get them to do something as obviously necessary as installing DNS records to find the IM systems themselves, how on earth do you expect to compel them to do something that is less obviously necessary, like keeping user IDs aligned across all of their systems? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 12:22:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21234 for ; Wed, 17 Dec 2003 12:22:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfNF-0005Es-Gm for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 12:22:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHHMDD7020138 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 12:22:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfNF-0005Ej-Bx for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 12:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21189 for ; Wed, 17 Dec 2003 12:22:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfND-0007Og-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 12:22:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfNC-0007OS-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 12:22:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWfNB-0007OC-00; Wed, 17 Dec 2003 12:22:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfN2-0005Dd-Nu; Wed, 17 Dec 2003 12:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWfM5-0005CV-4f for simple@optimus.ietf.org; Wed, 17 Dec 2003 12:21:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21142 for ; Wed, 17 Dec 2003 12:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWfM3-0007Nd-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWfM2-0007NW-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:59 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AWfM2-0007MX-00 for simple@ietf.org; Wed, 17 Dec 2003 12:20:58 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hBHHKEA3020561; Wed, 17 Dec 2003 11:20:14 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 11:20:13 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E866FC@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Joe Hildebrand'" , "'xmppwg@jabber.org'" , "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 11:20:12 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Joe Hildebrand [mailto:JHildebrand@jabber.com] wrote: > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point > to different entities? I can see the messages and presences > addressed to the two following different paths, perhaps > using different protocols, but I can't imagine a non-contrived > reason for them going to completely different endpoints, or > being for completely different system entities. Paul did a fairly good job of explaining how this sort of thing happens. I just wanted to make two additional points. To give a concrete example that may make more sense to you, the statements that I made are essentially the same as saying: - the JID "JHildebrand@corp.jabber.com" is NOT necessarily the same resource as "mailto:JHildebrand@corp.jabber.com" I note that you *tend* to make a distinction between the JID "JHildebrand@corp.jabber.com" and the URI "mailto:JHildebrand@jabber.com" when you write JEPs (cf. JEP-0115). The second point I wanted to make is: > The people administering the IM systems are typically going to be the same -- or at least, the same kind of -- people who administer the DNS. If you can't get them to do something as obviously necessary as installing DNS records to find the IM systems themselves, how on earth do you expect to compel them to do something that is less obviously necessary, like keeping user IDs aligned across all of their systems? /a _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 14:04:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26710 for ; Wed, 17 Dec 2003 14:04:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgxs-00047w-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 14:04:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgxr-00047p-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 14:04:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgxr-00047m-00; Wed, 17 Dec 2003 14:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxl-0001uU-Ro; Wed, 17 Dec 2003 14:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxY-0001tQ-Rp for simple@optimus.ietf.org; Wed, 17 Dec 2003 14:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26703 for ; Wed, 17 Dec 2003 14:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgxW-00047U-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgxV-00047N-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWgxV-00047K-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBHJ3SnG042976; Wed, 17 Dec 2003 13:03:39 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE0A875.8070107@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 13:03:17 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > You're right, that's our disconnect. I hadn't even considered that. > > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to different > entities? I can see the messages and presences addressed to the two > following different paths, perhaps using different protocols, but I can't > imagine a non-contrived reason for them going to completely different > endpoints, or being for completely different system entities. > > In other words, it might be nice for completeness, but if it adds mad > complexity, and no one will ever use it, is it worth the effort? > Let me take another angle at this. JIDs and and the "sip:" scheme designate two different name spaces, even if they are resolved at the same domain. One domain _might_ choose to synchronize them. But another domain might have two completely distinct user sets between the two namespaces. There is no requirement the two services be related in any way. For example, an ISP might have some SIP users and some XMPP users, where the sets are not identical. Furthermore, the same user part could exist in both sets, but refer to different people. For example, HypotheticalISP.com might let its users sign up for an xmpp service and/or a simple service. Furthermore, it might let those users choose their user id for that service on a first come first serve basis. So, I might sign up for the jid of ben.campbell@HypotheticalISP.com. I later sign up for simple, and find out some other person with the same name already has "sip:ben.campbell@HypotheticalISP.com" So, instead, I get "sip:bcampbell@HypotheticalISP.com" I don't think the standards can assume that services are synchronized. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 14:04:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26755 for ; Wed, 17 Dec 2003 14:04:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxw-0001vg-AE for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 14:04:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHJ4C6j007415 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 14:04:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxw-0001vW-6X for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 14:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26726 for ; Wed, 17 Dec 2003 14:04:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgxt-000487-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 14:04:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgxs-000480-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 14:04:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgxr-00047m-00; Wed, 17 Dec 2003 14:04:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxl-0001uU-Ro; Wed, 17 Dec 2003 14:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgxY-0001tQ-Rp for simple@optimus.ietf.org; Wed, 17 Dec 2003 14:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26703 for ; Wed, 17 Dec 2003 14:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgxW-00047U-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgxV-00047N-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:46 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWgxV-00047K-00 for simple@ietf.org; Wed, 17 Dec 2003 14:03:45 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBHJ3SnG042976; Wed, 17 Dec 2003 13:03:39 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE0A875.8070107@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C148007DADC3B@corp.webb.net> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 13:03:17 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > You're right, that's our disconnect. I hadn't even considered that. > > Can you give me a concrete use case where I might want > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to different > entities? I can see the messages and presences addressed to the two > following different paths, perhaps using different protocols, but I can't > imagine a non-contrived reason for them going to completely different > endpoints, or being for completely different system entities. > > In other words, it might be nice for completeness, but if it adds mad > complexity, and no one will ever use it, is it worth the effort? > Let me take another angle at this. JIDs and and the "sip:" scheme designate two different name spaces, even if they are resolved at the same domain. One domain _might_ choose to synchronize them. But another domain might have two completely distinct user sets between the two namespaces. There is no requirement the two services be related in any way. For example, an ISP might have some SIP users and some XMPP users, where the sets are not identical. Furthermore, the same user part could exist in both sets, but refer to different people. For example, HypotheticalISP.com might let its users sign up for an xmpp service and/or a simple service. Furthermore, it might let those users choose their user id for that service on a first come first serve basis. So, I might sign up for the jid of ben.campbell@HypotheticalISP.com. I later sign up for simple, and find out some other person with the same name already has "sip:ben.campbell@HypotheticalISP.com" So, instead, I get "sip:bcampbell@HypotheticalISP.com" I don't think the standards can assume that services are synchronized. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 14:26:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27424 for ; Wed, 17 Dec 2003 14:26:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhJ2-0004m6-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 14:26:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhIc-0004lv-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 14:25:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWhIc-0004lT-00; Wed, 17 Dec 2003 14:25:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhI5-0002mU-Hq; Wed, 17 Dec 2003 14:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhH7-0002lv-5S for simple@optimus.ietf.org; Wed, 17 Dec 2003 14:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27397 for ; Wed, 17 Dec 2003 14:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhH1-0004kO-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhH0-0004kH-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:55 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AWhH0-0004jZ-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:54 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 12:20:33 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> From: Joe Hildebrand To: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 12:20:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Do you feel the same way about im: as sip:? -- Joe Hildebrand > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, December 17, 2003 12:03 PM > To: Joe Hildebrand > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character > mappings for interoperabi lity > > Joe Hildebrand wrote: > > > You're right, that's our disconnect. I hadn't even considered that. > > > > Can you give me a concrete use case where I might want > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to > > different entities? I can see the messages and presences > addressed to > > the two following different paths, perhaps using different > protocols, > > but I can't imagine a non-contrived reason for them going to > > completely different endpoints, or being for completely > different system entities. > > > > In other words, it might be nice for completeness, but if > it adds mad > > complexity, and no one will ever use it, is it worth the effort? > > > > Let me take another angle at this. JIDs and and the "sip:" > scheme designate two different name spaces, even if they are > resolved at the same domain. One domain _might_ choose to > synchronize them. But another domain might have two > completely distinct user sets between the two namespaces. > There is no requirement the two services be related in any > way. For example, an ISP might have some SIP users and some > XMPP users, where the sets are not identical. Furthermore, > the same user part could exist in both sets, but refer to > different people. > > For example, HypotheticalISP.com might let its users sign up > for an xmpp service and/or a simple service. Furthermore, it > might let those users choose their user id for that service > on a first come first serve basis. > So, I might sign up for the jid of > ben.campbell@HypotheticalISP.com. I later sign up for simple, > and find out some other person with the same name already has > "sip:ben.campbell@HypotheticalISP.com" So, instead, I get > "sip:bcampbell@HypotheticalISP.com" > > I don't think the standards can assume that services are synchronized. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 14:27:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27481 for ; Wed, 17 Dec 2003 14:27:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhJa-0002s7-D1 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 14:26:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHJQYTP011039 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 14:26:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhJa-0002ry-9g for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 14:26:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27456 for ; Wed, 17 Dec 2003 14:26:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhJS-0004mj-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 14:26:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhJ2-0004mX-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 14:26:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWhIc-0004lT-00; Wed, 17 Dec 2003 14:25:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhI5-0002mU-Hq; Wed, 17 Dec 2003 14:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhH7-0002lv-5S for simple@optimus.ietf.org; Wed, 17 Dec 2003 14:24:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27397 for ; Wed, 17 Dec 2003 14:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhH1-0004kO-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhH0-0004kH-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:55 -0500 Received: from exchange.webb.net ([207.182.164.133] helo=ossex1.ossinc.net) by ietf-mx with esmtp (Exim 4.12) id 1AWhH0-0004jZ-00 for simple@ietf.org; Wed, 17 Dec 2003 14:23:54 -0500 Received: by corp.webb.net with Internet Mail Service (5.5.2653.19) id ; Wed, 17 Dec 2003 12:20:33 -0700 Message-ID: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> From: Joe Hildebrand To: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 12:20:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Do you feel the same way about im: as sip:? -- Joe Hildebrand > -----Original Message----- > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: Wednesday, December 17, 2003 12:03 PM > To: Joe Hildebrand > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character > mappings for interoperabi lity > > Joe Hildebrand wrote: > > > You're right, that's our disconnect. I hadn't even considered that. > > > > Can you give me a concrete use case where I might want > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to > > different entities? I can see the messages and presences > addressed to > > the two following different paths, perhaps using different > protocols, > > but I can't imagine a non-contrived reason for them going to > > completely different endpoints, or being for completely > different system entities. > > > > In other words, it might be nice for completeness, but if > it adds mad > > complexity, and no one will ever use it, is it worth the effort? > > > > Let me take another angle at this. JIDs and and the "sip:" > scheme designate two different name spaces, even if they are > resolved at the same domain. One domain _might_ choose to > synchronize them. But another domain might have two > completely distinct user sets between the two namespaces. > There is no requirement the two services be related in any > way. For example, an ISP might have some SIP users and some > XMPP users, where the sets are not identical. Furthermore, > the same user part could exist in both sets, but refer to > different people. > > For example, HypotheticalISP.com might let its users sign up > for an xmpp service and/or a simple service. Furthermore, it > might let those users choose their user id for that service > on a first come first serve basis. > So, I might sign up for the jid of > ben.campbell@HypotheticalISP.com. I later sign up for simple, > and find out some other person with the same name already has > "sip:ben.campbell@HypotheticalISP.com" So, instead, I get > "sip:bcampbell@HypotheticalISP.com" > > I don't think the standards can assume that services are synchronized. > > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 15:03:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29116 for ; Wed, 17 Dec 2003 15:03:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhsu-00063n-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:03:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhst-00063g-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:03:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWhst-00063d-00; Wed, 17 Dec 2003 15:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhsq-0004X0-Rf; Wed, 17 Dec 2003 15:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhru-0004W1-VL for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29084 for ; Wed, 17 Dec 2003 15:01:59 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhrs-00061z-00 for simple@ietf.org; Wed, 17 Dec 2003 15:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhrq-00061s-00 for simple@ietf.org; Wed, 17 Dec 2003 15:01:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWhrq-00061p-00 for simple@ietf.org; Wed, 17 Dec 2003 15:01:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHK1v609448 for ; Wed, 17 Dec 2003 22:01:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 22:01:51 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 22:01:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] SIMPLE implementations Message-ID: Thread-Topic: SIMPLE implementations Thread-Index: AcPDK7xG8wzO4nTQR2SzpVJoXV5McwAzVcng To: , X-OriginalArrivalTime: 17 Dec 2003 20:01:51.0591 (UTC) FILETIME=[9C9B4F70:01C3C4D8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 22:01:32 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Toni, I think one reason is that SIMPLE currently does not offer a good enough = interoperable feature set as completed standarsds (RFCs). For instance = Nokia has implemented IM & presence in some of its phones based on = Wireless Village technology, and that includes features such as = private/block list settings for presence, sending IMs to multiple = recipients etc. At the moment you can't do this kind of things with = SIMPLE, unless you have proprietary parts in place for some of the core = functionality. SIMPLE is however working on most of these fronts: XCAP to take care of = list and authorization policy maintenance, MSRP for sending = messages/files within a session etc. (Even presence publishing is still = unfinished but currently belongs to SIP WG). One important thing to fix = also is more clear semantics for presence documents. With the current = SIMPLE/IMPP specs good interoperability cannot be guaranteed. Once these issues have been solved - which will still take at least 6 = months - it is probable that more products will be switching to = SIP/SIMPLE based protocols. The main reason is probably not that SIP is = better than the others in IM & presence area, but that it can combine = even other methods of communication, such as voice and video, to the = service mix. The discussions ongoing on this list on how cumbersome it = is to map user IDs from one protocol to another provide yet another = reason why VoIP with SIP + IM/Presence with SIP is nicer than VoIP with = SIP + IM/Presence with WV, XMPP etc. Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Toni Heinonen > Sent: 15 December, 2003 18:52 > To: simple@ietf.org > Subject: [Simple] SIMPLE implementations >=20 >=20 > Hello, >=20 > I saw a nice listing of general SIP implementations at=20 > http://www.sipcenter.com/vsts/vsts_clientsoft.html. However,=20 > I did not see any free instant messaging clients like ICQ or=20 > ms messenger. Can anyone point me to any PC desktop instant=20 > messaging software that uses SIMPLE or uses a proprietary=20 > protocol but is moving to SIMPLE? Preferably open source, but=20 > commercial products would be nice too. >=20 > Can anyone shed the light on why all the instant messaging=20 > clients are still using their own proprietary protocols=20 > instead of SIMPLE? >=20 > Regards, >=20 > --=20 > Toni Heinonen > Teleware Oy > toni.heinonen@teleware.fi > +358 40 836 1815 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Wed Dec 17 15:03:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29167 for ; Wed, 17 Dec 2003 15:03:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhsz-0004a1-H6 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:03:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHK39ae017604 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhsz-0004Zr-Du for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:03:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29134 for ; Wed, 17 Dec 2003 15:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhsw-00063y-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:03:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhsv-00063r-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:03:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWhst-00063d-00; Wed, 17 Dec 2003 15:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhsq-0004X0-Rf; Wed, 17 Dec 2003 15:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWhru-0004W1-VL for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29084 for ; Wed, 17 Dec 2003 15:01:59 -0500 (EST) From: Markus.Isomaki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWhrs-00061z-00 for simple@ietf.org; Wed, 17 Dec 2003 15:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWhrq-00061s-00 for simple@ietf.org; Wed, 17 Dec 2003 15:01:59 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWhrq-00061p-00 for simple@ietf.org; Wed, 17 Dec 2003 15:01:58 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHK1v609448 for ; Wed, 17 Dec 2003 22:01:57 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 17 Dec 2003 22:01:51 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 22:01:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] SIMPLE implementations Message-ID: Thread-Topic: SIMPLE implementations Thread-Index: AcPDK7xG8wzO4nTQR2SzpVJoXV5McwAzVcng To: , X-OriginalArrivalTime: 17 Dec 2003 20:01:51.0591 (UTC) FILETIME=[9C9B4F70:01C3C4D8] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 22:01:32 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Toni, I think one reason is that SIMPLE currently does not offer a good enough = interoperable feature set as completed standarsds (RFCs). For instance = Nokia has implemented IM & presence in some of its phones based on = Wireless Village technology, and that includes features such as = private/block list settings for presence, sending IMs to multiple = recipients etc. At the moment you can't do this kind of things with = SIMPLE, unless you have proprietary parts in place for some of the core = functionality. SIMPLE is however working on most of these fronts: XCAP to take care of = list and authorization policy maintenance, MSRP for sending = messages/files within a session etc. (Even presence publishing is still = unfinished but currently belongs to SIP WG). One important thing to fix = also is more clear semantics for presence documents. With the current = SIMPLE/IMPP specs good interoperability cannot be guaranteed. Once these issues have been solved - which will still take at least 6 = months - it is probable that more products will be switching to = SIP/SIMPLE based protocols. The main reason is probably not that SIP is = better than the others in IM & presence area, but that it can combine = even other methods of communication, such as voice and video, to the = service mix. The discussions ongoing on this list on how cumbersome it = is to map user IDs from one protocol to another provide yet another = reason why VoIP with SIP + IM/Presence with SIP is nicer than VoIP with = SIP + IM/Presence with WV, XMPP etc. Markus=20 > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Toni Heinonen > Sent: 15 December, 2003 18:52 > To: simple@ietf.org > Subject: [Simple] SIMPLE implementations >=20 >=20 > Hello, >=20 > I saw a nice listing of general SIP implementations at=20 > http://www.sipcenter.com/vsts/vsts_clientsoft.html. However,=20 > I did not see any free instant messaging clients like ICQ or=20 > ms messenger. Can anyone point me to any PC desktop instant=20 > messaging software that uses SIMPLE or uses a proprietary=20 > protocol but is moving to SIMPLE? Preferably open source, but=20 > commercial products would be nice too. >=20 > Can anyone shed the light on why all the instant messaging=20 > clients are still using their own proprietary protocols=20 > instead of SIMPLE? >=20 > Regards, >=20 > --=20 > Toni Heinonen > Teleware Oy > toni.heinonen@teleware.fi > +358 40 836 1815 >=20 > _______________________________________________ > 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-admin@ietf.org Wed Dec 17 15:11:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00066 for ; Wed, 17 Dec 2003 15:11:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0h-0006O9-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:11:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi0f-0006Nv-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:11:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWi0f-0006Ns-00; Wed, 17 Dec 2003 15:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0c-0005Az-3G; Wed, 17 Dec 2003 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0R-0005AU-Ox for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:10:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00032 for ; Wed, 17 Dec 2003 15:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0O-0006NX-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi0N-0006NQ-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0N-0006MN-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBHKA8DO022428; Wed, 17 Dec 2003 15:10:10 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AES92788; Wed, 17 Dec 2003 15:10:07 -0500 (EST) Message-ID: <3FE0B81F.5020006@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 15:10:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>It occurs to me their may be a problem here. If the active party is >>sending an update because it has detected a connection >>failure, it may >>need a way to _insist_ on a new URL. If the passive party has not yet >>noticed the failure, it cannot tell the difference between a >>"no change" >>update and a "connection broken" update. > > > The passive party should notice since I would assume the active party is sending an updated offer with a new m-line. The old m-line port is set to 0. > > It is a new MSRP session and therefore needs a new media line. You cannot use an already existing m-line if it has not bee n perviously disabled by setting the port to 0. If it was done this way, how could the recipient know that the new MSRP session is intended to *replace* the old one, rather than just dropping the old one and creating a new one that is intended to be logically distinct? As long as we reuse the same m-line it is clear that we are dealing with the same media session. Otherwise I think we would need to resort to FID to tie different ones together. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 15:11:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00134 for ; Wed, 17 Dec 2003 15:11:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0l-0005EA-UV for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:11:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKBBX9020088 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:11:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0l-0005Dv-Qc for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:11:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00088 for ; Wed, 17 Dec 2003 15:11:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0i-0006OQ-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:11:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi0h-0006OG-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:11:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWi0f-0006Ns-00; Wed, 17 Dec 2003 15:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0c-0005Az-3G; Wed, 17 Dec 2003 15:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi0R-0005AU-Ox for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:10:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00032 for ; Wed, 17 Dec 2003 15:10:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0O-0006NX-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi0N-0006NQ-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:48 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWi0N-0006MN-00 for simple@ietf.org; Wed, 17 Dec 2003 15:10:47 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBHKA8DO022428; Wed, 17 Dec 2003 15:10:10 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AES92788; Wed, 17 Dec 2003 15:10:07 -0500 (EST) Message-ID: <3FE0B81F.5020006@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 15:10:07 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > >>It occurs to me their may be a problem here. If the active party is >>sending an update because it has detected a connection >>failure, it may >>need a way to _insist_ on a new URL. If the passive party has not yet >>noticed the failure, it cannot tell the difference between a >>"no change" >>update and a "connection broken" update. > > > The passive party should notice since I would assume the active party is sending an updated offer with a new m-line. The old m-line port is set to 0. > > It is a new MSRP session and therefore needs a new media line. You cannot use an already existing m-line if it has not bee n perviously disabled by setting the port to 0. If it was done this way, how could the recipient know that the new MSRP session is intended to *replace* the old one, rather than just dropping the old one and creating a new one that is intended to be logically distinct? As long as we reuse the same m-line it is clear that we are dealing with the same media session. Otherwise I think we would need to resort to FID to tie different ones together. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 15:28:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01919 for ; Wed, 17 Dec 2003 15:28:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiHC-0007TT-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:28:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiHB-0007TM-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 15:28:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWiHB-0007TJ-00; Wed, 17 Dec 2003 15:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiH3-0005cU-1j; Wed, 17 Dec 2003 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiGP-0005c3-9P for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01874 for ; Wed, 17 Dec 2003 15:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiGN-0007Rn-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiGH-0007RW-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:14 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWiGH-0007RM-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:13 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBHKPunG049645; Wed, 17 Dec 2003 14:26:06 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE0BBC8.8040607@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> <3FE0B81F.5020006@cisco.com> In-Reply-To: <3FE0B81F.5020006@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 14:25:44 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: > >> >>> It occurs to me their may be a problem here. If the active party is >>> sending an update because it has detected a connection failure, it >>> may need a way to _insist_ on a new URL. If the passive party has not >>> yet noticed the failure, it cannot tell the difference between a "no >>> change" update and a "connection broken" update. >> >> >> >> The passive party should notice since I would assume the active party >> is sending an updated offer with a new m-line. The old m-line port is >> set to 0. >> >> It is a new MSRP session and therefore needs a new media line. You >> cannot use an already existing m-line if it has not bee n perviously >> disabled by setting the port to 0. > > > If it was done this way, how could the recipient know that the new MSRP > session is intended to *replace* the old one, rather than just dropping > the old one and creating a new one that is intended to be logically > distinct? > > As long as we reuse the same m-line it is clear that we are dealing with > the same media session. Otherwise I think we would need to resort to FID > to tie different ones together. Would the "a=reconnect" attribute described in COMDEDIA be useful here? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 15:28:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01958 for ; Wed, 17 Dec 2003 15:28:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiHF-0005gU-G8 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:28:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKSDKJ021849 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 15:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiHF-0005gK-99 for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:28:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01935 for ; Wed, 17 Dec 2003 15:28:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiHD-0007Te-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:28:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiHC-0007TX-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 15:28:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWiHB-0007TJ-00; Wed, 17 Dec 2003 15:28:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiH3-0005cU-1j; Wed, 17 Dec 2003 15:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiGP-0005c3-9P for simple@optimus.ietf.org; Wed, 17 Dec 2003 15:27:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01874 for ; Wed, 17 Dec 2003 15:27:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiGN-0007Rn-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiGH-0007RW-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:14 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AWiGH-0007RM-00 for simple@ietf.org; Wed, 17 Dec 2003 15:27:13 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBHKPunG049645; Wed, 17 Dec 2003 14:26:06 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE0BBC8.8040607@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> <3FE0B81F.5020006@cisco.com> In-Reply-To: <3FE0B81F.5020006@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 14:25:44 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: > >> >>> It occurs to me their may be a problem here. If the active party is >>> sending an update because it has detected a connection failure, it >>> may need a way to _insist_ on a new URL. If the passive party has not >>> yet noticed the failure, it cannot tell the difference between a "no >>> change" update and a "connection broken" update. >> >> >> >> The passive party should notice since I would assume the active party >> is sending an updated offer with a new m-line. The old m-line port is >> set to 0. >> >> It is a new MSRP session and therefore needs a new media line. You >> cannot use an already existing m-line if it has not bee n perviously >> disabled by setting the port to 0. > > > If it was done this way, how could the recipient know that the new MSRP > session is intended to *replace* the old one, rather than just dropping > the old one and creating a new one that is intended to be logically > distinct? > > As long as we reuse the same m-line it is clear that we are dealing with > the same media session. Otherwise I think we would need to resort to FID > to tie different ones together. Would the "a=reconnect" attribute described in COMDEDIA be useful here? > > Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 17:16:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08805 for ; Wed, 17 Dec 2003 17:16:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxb-0004zc-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 17:16:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjxa-0004zV-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 17:16:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjxa-0004zS-00; Wed, 17 Dec 2003 17:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxa-0002E0-0f; Wed, 17 Dec 2003 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxL-0002Cx-Pv for simple@optimus.ietf.org; Wed, 17 Dec 2003 17:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08789 for ; Wed, 17 Dec 2003 17:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxJ-0004yT-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjxI-0004yM-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxI-0004xj-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:44 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 17 Dec 2003 22:15:33 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBHMFBxg022034; Wed, 17 Dec 2003 17:15:11 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET06413; Wed, 17 Dec 2003 17:15:10 -0500 (EST) Message-ID: <3FE0D56D.600@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> <3FE0B81F.5020006@cisco.com> <3FE0BBC8.8040607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 17:15:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Would the "a=reconnect" attribute described in COMDEDIA be useful here? I need to go reread what ended up getting written in there. If it ended up so you had to do something special when you want to reconnect (as it sounds) then yes. I fussed about how that worked for awhile, but finally lost interest in it when it became apparent that it wasn't going to work for IM. Whats bad is if you have to do something special in order to achieve a noop condition. Sending the same sdp as the last time when in a steady state condition should continue in a steady state condition. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 17 17:16:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08867 for ; Wed, 17 Dec 2003 17:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxf-0002Ex-4M for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 17:16:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHMG7AE008611 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 17:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxf-0002Eo-1Z for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 17:16:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08821 for ; Wed, 17 Dec 2003 17:16:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxc-0004zn-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 17:16:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjxb-0004zg-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 17:16:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjxa-0004zS-00; Wed, 17 Dec 2003 17:16:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxa-0002E0-0f; Wed, 17 Dec 2003 17:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjxL-0002Cx-Pv for simple@optimus.ietf.org; Wed, 17 Dec 2003 17:15:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08789 for ; Wed, 17 Dec 2003 17:15:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxJ-0004yT-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjxI-0004yM-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AWjxI-0004xj-00 for simple@ietf.org; Wed, 17 Dec 2003 17:15:44 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 17 Dec 2003 22:15:33 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBHMFBxg022034; Wed, 17 Dec 2003 17:15:11 -0500 (EST) Received: from cisco.com (dhcp-10-86-164-191.cisco.com [10.86.164.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET06413; Wed, 17 Dec 2003 17:15:10 -0500 (EST) Message-ID: <3FE0D56D.600@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB70118B153@esebe019.ntc.nokia.com> <3FE0B81F.5020006@cisco.com> <3FE0BBC8.8040607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 17:15:09 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Ben Campbell wrote: > > Would the "a=reconnect" attribute described in COMDEDIA be useful here? I need to go reread what ended up getting written in there. If it ended up so you had to do something special when you want to reconnect (as it sounds) then yes. I fussed about how that worked for awhile, but finally lost interest in it when it became apparent that it wasn't going to work for IM. Whats bad is if you have to do something special in order to achieve a noop condition. Sending the same sdp as the last time when in a steady state condition should continue in a steady state condition. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 17 19:59:14 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16648 for ; Wed, 17 Dec 2003 19:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmVT-0002zE-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 19:59:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmVS-0002z7-00 for simple-archive@ietf.org; Wed, 17 Dec 2003 19:59:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWmVS-0002z4-00; Wed, 17 Dec 2003 19:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmVI-0007XG-T8; Wed, 17 Dec 2003 19:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmUJ-0007VU-BQ for simple@optimus.ietf.org; Wed, 17 Dec 2003 19:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16604 for ; Wed, 17 Dec 2003 19:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmUH-0002xS-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmUG-0002xL-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:57 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmUG-0002x6-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:56 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HQ200FEEFH484@firewall.mci.com> for simple@ietf.org; Thu, 18 Dec 2003 00:46:16 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HQ200G01FH42Q@pmismtp02.wcomnet.com>; Thu, 18 Dec 2003 00:46:16 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.112.28]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HQ200F6HFH140@pmismtp02.wcomnet.com>; Thu, 18 Dec 2003 00:46:15 +0000 (GMT) From: Alan Johnston Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity In-reply-to: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> X-Sender: Alan.Johnston@pop.mcit.com To: Joe Hildebrand , "'xmppwg@jabber.org'" , "'simple@ietf.org'" Message-id: <5.2.1.1.0.20031217183949.02e94008@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 18:46:12 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 12:20 PM 12/17/2003 -0700, Joe Hildebrand wrote: >Do you feel the same way about im: as sip:? Of course - they are different URI schemes. This is why SIP uses URIs and why even H.323 has moved towards the use of URIs instead of just identifiers. As a result, the interworking of SIP and H.323 is quite straightforward - a SIP request can be sent with an H.323 URI as the target - a proxy receiving such a request would locate a SIP/H.323 interworking function and forward. The same thing in the H.323 domain - if the resource was a SIP URI, the gatekeeper would attempt to locate a suitable gateway. SIP also has responses to indicate that a particular URI scheme is not understood, allowing extensibility in the definition of new URI schemes in the future. Most Internet protocols use URIs for these reasons. Completely avoids all the ugly issues of namespace/character mappings and conventions. Thanks, Alan Johnston MCI sip:alan@sipstation.com >-- >Joe Hildebrand > > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Wednesday, December 17, 2003 12:03 PM > > To: Joe Hildebrand > > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character > > mappings for interoperabi lity > > > > Joe Hildebrand wrote: > > > > > You're right, that's our disconnect. I hadn't even considered that. > > > > > > Can you give me a concrete use case where I might want > > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to > > > different entities? I can see the messages and presences > > addressed to > > > the two following different paths, perhaps using different > > protocols, > > > but I can't imagine a non-contrived reason for them going to > > > completely different endpoints, or being for completely > > different system entities. > > > > > > In other words, it might be nice for completeness, but if > > it adds mad > > > complexity, and no one will ever use it, is it worth the effort? > > > > > > > Let me take another angle at this. JIDs and and the "sip:" > > scheme designate two different name spaces, even if they are > > resolved at the same domain. One domain _might_ choose to > > synchronize them. But another domain might have two > > completely distinct user sets between the two namespaces. > > There is no requirement the two services be related in any > > way. For example, an ISP might have some SIP users and some > > XMPP users, where the sets are not identical. Furthermore, > > the same user part could exist in both sets, but refer to > > different people. > > > > For example, HypotheticalISP.com might let its users sign up > > for an xmpp service and/or a simple service. Furthermore, it > > might let those users choose their user id for that service > > on a first come first serve basis. > > So, I might sign up for the jid of > > ben.campbell@HypotheticalISP.com. I later sign up for simple, > > and find out some other person with the same name already has > > "sip:ben.campbell@HypotheticalISP.com" So, instead, I get > > "sip:bcampbell@HypotheticalISP.com" > > > > I don't think the standards can assume that services are synchronized. > > > > > > > >_______________________________________________ >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 exim@www1.ietf.org Wed Dec 17 19:59:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16671 for ; Wed, 17 Dec 2003 19:59:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmVX-0007Yu-1k for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 19:59:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI0xFnp029064 for simple-archive@odin.ietf.org; Wed, 17 Dec 2003 19:59:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmVW-0007Yh-Tw for simple-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 19:59:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16650 for ; Wed, 17 Dec 2003 19:59:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmVU-0002zQ-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 19:59:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmVT-0002zI-00 for simple-web-archive@ietf.org; Wed, 17 Dec 2003 19:59:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWmVS-0002z4-00; Wed, 17 Dec 2003 19:59:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmVI-0007XG-T8; Wed, 17 Dec 2003 19:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmUJ-0007VU-BQ for simple@optimus.ietf.org; Wed, 17 Dec 2003 19:58:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16604 for ; Wed, 17 Dec 2003 19:57:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmUH-0002xS-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmUG-0002xL-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:57 -0500 Received: from pmesmtp01.wcom.com ([199.249.20.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmUG-0002x6-00 for simple@ietf.org; Wed, 17 Dec 2003 19:57:56 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0HQ200FEEFH484@firewall.mci.com> for simple@ietf.org; Thu, 18 Dec 2003 00:46:16 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HQ200G01FH42Q@pmismtp02.wcomnet.com>; Thu, 18 Dec 2003 00:46:16 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.112.28]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HQ200F6HFH140@pmismtp02.wcomnet.com>; Thu, 18 Dec 2003 00:46:15 +0000 (GMT) From: Alan Johnston Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity In-reply-to: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> X-Sender: Alan.Johnston@pop.mcit.com To: Joe Hildebrand , "'xmppwg@jabber.org'" , "'simple@ietf.org'" Message-id: <5.2.1.1.0.20031217183949.02e94008@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Dec 2003 18:46:12 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 At 12:20 PM 12/17/2003 -0700, Joe Hildebrand wrote: >Do you feel the same way about im: as sip:? Of course - they are different URI schemes. This is why SIP uses URIs and why even H.323 has moved towards the use of URIs instead of just identifiers. As a result, the interworking of SIP and H.323 is quite straightforward - a SIP request can be sent with an H.323 URI as the target - a proxy receiving such a request would locate a SIP/H.323 interworking function and forward. The same thing in the H.323 domain - if the resource was a SIP URI, the gatekeeper would attempt to locate a suitable gateway. SIP also has responses to indicate that a particular URI scheme is not understood, allowing extensibility in the definition of new URI schemes in the future. Most Internet protocols use URIs for these reasons. Completely avoids all the ugly issues of namespace/character mappings and conventions. Thanks, Alan Johnston MCI sip:alan@sipstation.com >-- >Joe Hildebrand > > > > > -----Original Message----- > > From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] > > Sent: Wednesday, December 17, 2003 12:03 PM > > To: Joe Hildebrand > > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character > > mappings for interoperabi lity > > > > Joe Hildebrand wrote: > > > > > You're right, that's our disconnect. I hadn't even considered that. > > > > > > Can you give me a concrete use case where I might want > > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to point to > > > different entities? I can see the messages and presences > > addressed to > > > the two following different paths, perhaps using different > > protocols, > > > but I can't imagine a non-contrived reason for them going to > > > completely different endpoints, or being for completely > > different system entities. > > > > > > In other words, it might be nice for completeness, but if > > it adds mad > > > complexity, and no one will ever use it, is it worth the effort? > > > > > > > Let me take another angle at this. JIDs and and the "sip:" > > scheme designate two different name spaces, even if they are > > resolved at the same domain. One domain _might_ choose to > > synchronize them. But another domain might have two > > completely distinct user sets between the two namespaces. > > There is no requirement the two services be related in any > > way. For example, an ISP might have some SIP users and some > > XMPP users, where the sets are not identical. Furthermore, > > the same user part could exist in both sets, but refer to > > different people. > > > > For example, HypotheticalISP.com might let its users sign up > > for an xmpp service and/or a simple service. Furthermore, it > > might let those users choose their user id for that service > > on a first come first serve basis. > > So, I might sign up for the jid of > > ben.campbell@HypotheticalISP.com. I later sign up for simple, > > and find out some other person with the same name already has > > "sip:ben.campbell@HypotheticalISP.com" So, instead, I get > > "sip:bcampbell@HypotheticalISP.com" > > > > I don't think the standards can assume that services are synchronized. > > > > > > > >_______________________________________________ >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-admin@ietf.org Thu Dec 18 03:36:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11313 for ; Thu, 18 Dec 2003 03:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtda-0005xE-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 03:36:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtdZ-0005x7-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 03:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtdY-0005x4-00; Thu, 18 Dec 2003 03:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtdY-0006Qi-5T; Thu, 18 Dec 2003 03:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtcq-0006P5-AJ for simple@optimus.ietf.org; Thu, 18 Dec 2003 03:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11304 for ; Thu, 18 Dec 2003 03:35:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtcn-0005wA-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtcn-0005w3-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWtcm-0005w0-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:12 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8ZC627876 for ; Thu, 18 Dec 2003 10:35:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:35:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPE2cobmD2WIyiQSm6lCBg/pJLHtQAZ8SJg To: Cc: , X-OriginalArrivalTime: 18 Dec 2003 08:35:12.0105 (UTC) FILETIME=[DA366590:01C3C541] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 10:35:11 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17.December.2003 22:10 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>It occurs to me their may be a problem here. If the active party is=20 > >>sending an update because it has detected a connection=20 > >>failure, it may=20 > >>need a way to _insist_ on a new URL. If the passive party=20 > has not yet=20 > >>noticed the failure, it cannot tell the difference between a=20 > >>"no change"=20 > >>update and a "connection broken" update. > >=20 > >=20 > > The passive party should notice since I would assume the=20 > active party is sending an updated offer with a new m-line.=20 > The old m-line port is set to 0. > >=20 > > It is a new MSRP session and therefore needs a new media=20 > line. You cannot use an already existing m-line if it has not=20 > bee n perviously disabled by setting the port to 0. >=20 > If it was done this way, how could the recipient know that=20 > the new MSRP=20 > session is intended to *replace* the old one, rather than=20 > just dropping=20 > the old one and creating a new one that is intended to be logically=20 > distinct? What are the use cases where an end point would end an old IM session = only to start a new one, where the new one is not *replacing* the old = one? /Hisham >=20 > As long as we reuse the same m-line it is clear that we are=20 > dealing with=20 > the same media session. Otherwise I think we would need to=20 > resort to FID=20 > to tie different ones together. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 03:36:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11338 for ; Thu, 18 Dec 2003 03:36:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtde-0006S3-5f for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 03:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8a6c7024798 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 03:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtdd-0006Rt-H9 for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 03:36:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11329 for ; Thu, 18 Dec 2003 03:36:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtdb-0005xP-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 03:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtda-0005xI-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 03:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtdY-0005x4-00; Thu, 18 Dec 2003 03:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtdY-0006Qi-5T; Thu, 18 Dec 2003 03:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtcq-0006P5-AJ for simple@optimus.ietf.org; Thu, 18 Dec 2003 03:35:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11304 for ; Thu, 18 Dec 2003 03:35:14 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtcn-0005wA-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtcn-0005w3-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWtcm-0005w0-00 for simple@ietf.org; Thu, 18 Dec 2003 03:35:12 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8ZC627876 for ; Thu, 18 Dec 2003 10:35:12 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:35:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> Thread-Topic: [Simple] MSRP: Some thoughts on session updates Thread-Index: AcPE2cobmD2WIyiQSm6lCBg/pJLHtQAZ8SJg To: Cc: , X-OriginalArrivalTime: 18 Dec 2003 08:35:12.0105 (UTC) FILETIME=[DA366590:01C3C541] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 10:35:11 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 17.December.2003 22:10 > To: Khartabil Hisham (NMP-MSW/Helsinki) > Cc: bcampbell@dynamicsoft.com; simple@ietf.org > Subject: Re: [Simple] MSRP: Some thoughts on session updates >=20 >=20 >=20 >=20 > hisham.khartabil@nokia.com wrote: > >=20 > >>It occurs to me their may be a problem here. If the active party is=20 > >>sending an update because it has detected a connection=20 > >>failure, it may=20 > >>need a way to _insist_ on a new URL. If the passive party=20 > has not yet=20 > >>noticed the failure, it cannot tell the difference between a=20 > >>"no change"=20 > >>update and a "connection broken" update. > >=20 > >=20 > > The passive party should notice since I would assume the=20 > active party is sending an updated offer with a new m-line.=20 > The old m-line port is set to 0. > >=20 > > It is a new MSRP session and therefore needs a new media=20 > line. You cannot use an already existing m-line if it has not=20 > bee n perviously disabled by setting the port to 0. >=20 > If it was done this way, how could the recipient know that=20 > the new MSRP=20 > session is intended to *replace* the old one, rather than=20 > just dropping=20 > the old one and creating a new one that is intended to be logically=20 > distinct? What are the use cases where an end point would end an old IM session = only to start a new one, where the new one is not *replacing* the old = one? /Hisham >=20 > As long as we reuse the same m-line it is clear that we are=20 > dealing with=20 > the same media session. Otherwise I think we would need to=20 > resort to FID=20 > to tie different ones together. >=20 > Paul >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 18 03:56:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11707 for ; Thu, 18 Dec 2003 03:56:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtx3-0006MG-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 03:56:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtx2-0006M2-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 03:56:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtx1-0006Lv-00; Thu, 18 Dec 2003 03:56:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtwx-0007Ea-E5; Thu, 18 Dec 2003 03:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtwQ-0007Dj-RN for simple@optimus.ietf.org; Thu, 18 Dec 2003 03:55:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11698 for ; Thu, 18 Dec 2003 03:55:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtwO-0006Kx-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtwN-0006Kq-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:27 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWtwM-0006Kn-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:26 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8tR626576 for ; Thu, 18 Dec 2003 10:55:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:54:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:54:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Thread-Index: AcPE0JUN1nFkpoB2RSCNijNI/MivigAchf7w To: , Cc: , X-OriginalArrivalTime: 18 Dec 2003 08:54:38.0128 (UTC) FILETIME=[91376300:01C3C544] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 10:54:38 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Although I agree with Adam and others, I would like to point out that = people usually try to make guesses about other people's sip addresses = using their email addresses. So, if my email is = hisham.khartabil@nokia.com, people using SIP would assume that my sip = address is the same hisham.khartabil@nokia.com. People using XMPP would = assume that my JID looks the same, and so on. Therefore I think it is in the service providers' interest that they = don't allow different people to have the same URI but with different = scheme. I see some security and confidentiality concenrs here. Some one = might wronly assume that I have a JID that looks the same as my sip = address and end up sending someone else a message that says "Nokia is = planning on ...". So, having said that, is it really worth spending the time on trying to = get this working when it will not be used? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 17.December.2003 21:03 > To: Joe Hildebrand > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings > for interoperabi lity >=20 >=20 > Joe Hildebrand wrote: >=20 > > You're right, that's our disconnect. I hadn't even considered that. > >=20 > > Can you give me a concrete use case where I might want > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to=20 > point to different > > entities? I can see the messages and presences addressed to the two > > following different paths, perhaps using different=20 > protocols, but I can't > > imagine a non-contrived reason for them going to completely=20 > different > > endpoints, or being for completely different system entities. > >=20 > > In other words, it might be nice for completeness, but if=20 > it adds mad > > complexity, and no one will ever use it, is it worth the effort? > >=20 >=20 > Let me take another angle at this. JIDs and and the "sip:" scheme=20 > designate two different name spaces, even if they are=20 > resolved at the=20 > same domain. One domain _might_ choose to synchronize them.=20 > But another=20 > domain might have two completely distinct user sets between the two=20 > namespaces. There is no requirement the two services be=20 > related in any=20 > way. For example, an ISP might have some SIP users and some=20 > XMPP users,=20 > where the sets are not identical. Furthermore, the same user=20 > part could=20 > exist in both sets, but refer to different people. >=20 > For example, HypotheticalISP.com might let its users sign up=20 > for an xmpp=20 > service and/or a simple service. Furthermore, it might let=20 > those users=20 > choose their user id for that service on a first come first=20 > serve basis.=20 > So, I might sign up for the jid of=20 > ben.campbell@HypotheticalISP.com. I=20 > later sign up for simple, and find out some other person with=20 > the same=20 > name already has "sip:ben.campbell@HypotheticalISP.com" So,=20 > instead, I=20 > get "sip:bcampbell@HypotheticalISP.com" >=20 > I don't think the standards can assume that services are synchronized. >=20 >=20 >=20 >=20 > _______________________________________________ > 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 exim@www1.ietf.org Thu Dec 18 03:56:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11729 for ; Thu, 18 Dec 2003 03:56:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtx8-0007Ga-HO for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 03:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8uEIH027933 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 03:56:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtx8-0007GA-0V for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 03:56:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11723 for ; Thu, 18 Dec 2003 03:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtx5-0006MR-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 03:56:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtx4-0006MK-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 03:56:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtx1-0006Lv-00; Thu, 18 Dec 2003 03:56:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtwx-0007Ea-E5; Thu, 18 Dec 2003 03:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtwQ-0007Dj-RN for simple@optimus.ietf.org; Thu, 18 Dec 2003 03:55:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11698 for ; Thu, 18 Dec 2003 03:55:28 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtwO-0006Kx-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtwN-0006Kq-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:27 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWtwM-0006Kn-00 for simple@ietf.org; Thu, 18 Dec 2003 03:55:26 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8tR626576 for ; Thu, 18 Dec 2003 10:55:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:54:38 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:54:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> Thread-Topic: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity Thread-Index: AcPE0JUN1nFkpoB2RSCNijNI/MivigAchf7w To: , Cc: , X-OriginalArrivalTime: 18 Dec 2003 08:54:38.0128 (UTC) FILETIME=[91376300:01C3C544] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 10:54:38 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Although I agree with Adam and others, I would like to point out that = people usually try to make guesses about other people's sip addresses = using their email addresses. So, if my email is = hisham.khartabil@nokia.com, people using SIP would assume that my sip = address is the same hisham.khartabil@nokia.com. People using XMPP would = assume that my JID looks the same, and so on. Therefore I think it is in the service providers' interest that they = don't allow different people to have the same URI but with different = scheme. I see some security and confidentiality concenrs here. Some one = might wronly assume that I have a JID that looks the same as my sip = address and end up sending someone else a message that says "Nokia is = planning on ...". So, having said that, is it really worth spending the time on trying to = get this working when it will not be used? Regards, Hisham > -----Original Message----- > From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of > ext Ben Campbell > Sent: 17.December.2003 21:03 > To: Joe Hildebrand > Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' > Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings > for interoperabi lity >=20 >=20 > Joe Hildebrand wrote: >=20 > > You're right, that's our disconnect. I hadn't even considered that. > >=20 > > Can you give me a concrete use case where I might want > > sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to=20 > point to different > > entities? I can see the messages and presences addressed to the two > > following different paths, perhaps using different=20 > protocols, but I can't > > imagine a non-contrived reason for them going to completely=20 > different > > endpoints, or being for completely different system entities. > >=20 > > In other words, it might be nice for completeness, but if=20 > it adds mad > > complexity, and no one will ever use it, is it worth the effort? > >=20 >=20 > Let me take another angle at this. JIDs and and the "sip:" scheme=20 > designate two different name spaces, even if they are=20 > resolved at the=20 > same domain. One domain _might_ choose to synchronize them.=20 > But another=20 > domain might have two completely distinct user sets between the two=20 > namespaces. There is no requirement the two services be=20 > related in any=20 > way. For example, an ISP might have some SIP users and some=20 > XMPP users,=20 > where the sets are not identical. Furthermore, the same user=20 > part could=20 > exist in both sets, but refer to different people. >=20 > For example, HypotheticalISP.com might let its users sign up=20 > for an xmpp=20 > service and/or a simple service. Furthermore, it might let=20 > those users=20 > choose their user id for that service on a first come first=20 > serve basis.=20 > So, I might sign up for the jid of=20 > ben.campbell@HypotheticalISP.com. I=20 > later sign up for simple, and find out some other person with=20 > the same=20 > name already has "sip:ben.campbell@HypotheticalISP.com" So,=20 > instead, I=20 > get "sip:bcampbell@HypotheticalISP.com" >=20 > I don't think the standards can assume that services are synchronized. >=20 >=20 >=20 >=20 > _______________________________________________ > 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-admin@ietf.org Thu Dec 18 10:53:04 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00189 for ; Thu, 18 Dec 2003 10:53:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0SX-0002Zs-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 10:53:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0SW-0002Zk-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 10:53:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0SW-0002Zh-00; Thu, 18 Dec 2003 10:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0SS-0000qT-Oo; Thu, 18 Dec 2003 10:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0SB-0000q5-Og for simple@optimus.ietf.org; Thu, 18 Dec 2003 10:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00179 for ; Thu, 18 Dec 2003 10:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0S9-0002ZP-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0S8-0002ZI-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AX0S7-0002ZF-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBIFqPnG037957; Thu, 18 Dec 2003 09:52:36 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE1CD2D.8040700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: JHildebrand@jabber.com, xmppwg@jabber.org, simple@ietf.org Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 09:52:13 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Although I agree with Adam and others, I would like to point out that people usually try to make guesses about other people's sip addresses using their email addresses. So, if my email is hisham.khartabil@nokia.com, people using SIP would assume that my sip address is the same hisham.khartabil@nokia.com. People using XMPP would assume that my JID looks the same, and so on. > > Therefore I think it is in the service providers' interest that they don't allow different people to have the same URI but with different scheme. I see some security and confidentiality concenrs here. Some one might wronly assume that I have a JID that looks the same as my sip address and end up sending someone else a message that says "Nokia is planning on ...". > > So, having said that, is it really worth spending the time on trying to get this working when it will not be used? It is not our place to specify provider namespace policy. At best, one might have a bcp for this sort of thing, but _never_ a standard. And if we were to make such namespace assumption, where do you stop? Would we also want to say that if I have a JID of bcampbell@dynamicsoft.com, and a SIP URI of sip:bcampbell@dynamicsoft.com I must also have a web page at HTTP://www.dynamicsoft.com/~bcampbell? So, we have a mechanism to map from an abstract scheme (pres: or im:) to a concrete one. I think we need to either further specify how two interoperable concrete systems should use the abstract schema, or we need to specify how to map between the two concrete systems, without making assumptions about synchronized identifiers. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 17.December.2003 21:03 >>To: Joe Hildebrand >>Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' >>Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings >>for interoperabi lity >> >> >>Joe Hildebrand wrote: >> >> >>>You're right, that's our disconnect. I hadn't even considered that. >>> >>>Can you give me a concrete use case where I might want >>>sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to >> >>point to different >> >>>entities? I can see the messages and presences addressed to the two >>>following different paths, perhaps using different >> >>protocols, but I can't >> >>>imagine a non-contrived reason for them going to completely >> >>different >> >>>endpoints, or being for completely different system entities. >>> >>>In other words, it might be nice for completeness, but if >> >>it adds mad >> >>>complexity, and no one will ever use it, is it worth the effort? >>> >> >>Let me take another angle at this. JIDs and and the "sip:" scheme >>designate two different name spaces, even if they are >>resolved at the >>same domain. One domain _might_ choose to synchronize them. >>But another >>domain might have two completely distinct user sets between the two >>namespaces. There is no requirement the two services be >>related in any >>way. For example, an ISP might have some SIP users and some >>XMPP users, >>where the sets are not identical. Furthermore, the same user >>part could >>exist in both sets, but refer to different people. >> >>For example, HypotheticalISP.com might let its users sign up >>for an xmpp >>service and/or a simple service. Furthermore, it might let >>those users >>choose their user id for that service on a first come first >>serve basis. >>So, I might sign up for the jid of >>ben.campbell@HypotheticalISP.com. I >>later sign up for simple, and find out some other person with >>the same >>name already has "sip:ben.campbell@HypotheticalISP.com" So, >>instead, I >>get "sip:bcampbell@HypotheticalISP.com" >> >>I don't think the standards can assume that services are synchronized. >> >> >> >> >>_______________________________________________ >>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 exim@www1.ietf.org Thu Dec 18 10:53:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00244 for ; Thu, 18 Dec 2003 10:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Sb-0000sK-UW for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 10:53:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIFr9En003363 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 10:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0Sb-0000sA-Qp for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 10:53:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00208 for ; Thu, 18 Dec 2003 10:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0SY-0002a3-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 10:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0SX-0002Zw-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 10:53:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX0SW-0002Zh-00; Thu, 18 Dec 2003 10:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0SS-0000qT-Oo; Thu, 18 Dec 2003 10:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX0SB-0000q5-Og for simple@optimus.ietf.org; Thu, 18 Dec 2003 10:52:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00179 for ; Thu, 18 Dec 2003 10:52:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX0S9-0002ZP-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX0S8-0002ZI-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:41 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AX0S7-0002ZF-00 for simple@ietf.org; Thu, 18 Dec 2003 10:52:39 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBIFqPnG037957; Thu, 18 Dec 2003 09:52:36 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE1CD2D.8040700@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: JHildebrand@jabber.com, xmppwg@jabber.org, simple@ietf.org Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 09:52:13 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > Although I agree with Adam and others, I would like to point out that people usually try to make guesses about other people's sip addresses using their email addresses. So, if my email is hisham.khartabil@nokia.com, people using SIP would assume that my sip address is the same hisham.khartabil@nokia.com. People using XMPP would assume that my JID looks the same, and so on. > > Therefore I think it is in the service providers' interest that they don't allow different people to have the same URI but with different scheme. I see some security and confidentiality concenrs here. Some one might wronly assume that I have a JID that looks the same as my sip address and end up sending someone else a message that says "Nokia is planning on ...". > > So, having said that, is it really worth spending the time on trying to get this working when it will not be used? It is not our place to specify provider namespace policy. At best, one might have a bcp for this sort of thing, but _never_ a standard. And if we were to make such namespace assumption, where do you stop? Would we also want to say that if I have a JID of bcampbell@dynamicsoft.com, and a SIP URI of sip:bcampbell@dynamicsoft.com I must also have a web page at HTTP://www.dynamicsoft.com/~bcampbell? So, we have a mechanism to map from an abstract scheme (pres: or im:) to a concrete one. I think we need to either further specify how two interoperable concrete systems should use the abstract schema, or we need to specify how to map between the two concrete systems, without making assumptions about synchronized identifiers. > > Regards, > Hisham > > >>-----Original Message----- >>From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of >>ext Ben Campbell >>Sent: 17.December.2003 21:03 >>To: Joe Hildebrand >>Cc: 'xmppwg@jabber.org'; 'simple@ietf.org' >>Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings >>for interoperabi lity >> >> >>Joe Hildebrand wrote: >> >> >>>You're right, that's our disconnect. I hadn't even considered that. >>> >>>Can you give me a concrete use case where I might want >>>sip:adam@dynamicsoft.com and im:adam@dynamicsoft.com to >> >>point to different >> >>>entities? I can see the messages and presences addressed to the two >>>following different paths, perhaps using different >> >>protocols, but I can't >> >>>imagine a non-contrived reason for them going to completely >> >>different >> >>>endpoints, or being for completely different system entities. >>> >>>In other words, it might be nice for completeness, but if >> >>it adds mad >> >>>complexity, and no one will ever use it, is it worth the effort? >>> >> >>Let me take another angle at this. JIDs and and the "sip:" scheme >>designate two different name spaces, even if they are >>resolved at the >>same domain. One domain _might_ choose to synchronize them. >>But another >>domain might have two completely distinct user sets between the two >>namespaces. There is no requirement the two services be >>related in any >>way. For example, an ISP might have some SIP users and some >>XMPP users, >>where the sets are not identical. Furthermore, the same user >>part could >>exist in both sets, but refer to different people. >> >>For example, HypotheticalISP.com might let its users sign up >>for an xmpp >>service and/or a simple service. Furthermore, it might let >>those users >>choose their user id for that service on a first come first >>serve basis. >>So, I might sign up for the jid of >>ben.campbell@HypotheticalISP.com. I >>later sign up for simple, and find out some other person with >>the same >>name already has "sip:ben.campbell@HypotheticalISP.com" So, >>instead, I >>get "sip:bcampbell@HypotheticalISP.com" >> >>I don't think the standards can assume that services are synchronized. >> >> >> >> >>_______________________________________________ >>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-admin@ietf.org Thu Dec 18 13:56:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08271 for ; Thu, 18 Dec 2003 13:56:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3Jd-0001Pr-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 13:56:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3Jc-0001Pk-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 13:56:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3Jc-0001Ph-00; Thu, 18 Dec 2003 13:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3JZ-0001UL-J5; Thu, 18 Dec 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3JD-0001Tk-9X for simple@optimus.ietf.org; Thu, 18 Dec 2003 13:55:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08244 for ; Thu, 18 Dec 2003 13:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3JB-0001P8-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3JA-0001P1-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AX3J9-0001Ow-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBIItRnG054160; Thu, 18 Dec 2003 12:55:34 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE1F813.4050304@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 12:55:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Do you feel the same way about im: as sip:? > If the question is, do I think that the im: scheme and the JID space are separate namespaces, where you cannot assume a simple string mapping between them, then yes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 13:56:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08290 for ; Thu, 18 Dec 2003 13:56:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3Jh-0001VJ-67 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 13:56:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIIu9nG005775 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 13:56:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3Jh-0001V4-1O for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 13:56:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08287 for ; Thu, 18 Dec 2003 13:56:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3Je-0001Q2-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 13:56:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3Jd-0001Pu-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 13:56:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3Jc-0001Ph-00; Thu, 18 Dec 2003 13:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3JZ-0001UL-J5; Thu, 18 Dec 2003 13:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3JD-0001Tk-9X for simple@optimus.ietf.org; Thu, 18 Dec 2003 13:55:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08244 for ; Thu, 18 Dec 2003 13:55:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3JB-0001P8-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3JA-0001P1-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:36 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AX3J9-0001Ow-00 for simple@ietf.org; Thu, 18 Dec 2003 13:55:35 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBIItRnG054160; Thu, 18 Dec 2003 12:55:34 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE1F813.4050304@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Hildebrand CC: "'xmppwg@jabber.org'" , "'simple@ietf.org'" Subject: Re: [Simple] RE: [xmppwg] RE: Action Item: character mappings for interoperabi lity References: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> In-Reply-To: <8D96EDA0AC04D31197B400A0C96C148007DADC44@corp.webb.net> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 12:55:15 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe Hildebrand wrote: > Do you feel the same way about im: as sip:? > If the question is, do I think that the im: scheme and the JID space are separate namespaces, where you cannot assume a simple string mapping between them, then yes. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 18 14:15:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09607 for ; Thu, 18 Dec 2003 14:15:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3c4-0002WX-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 14:15:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3c3-0002WQ-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 14:15:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3c3-0002WN-00; Thu, 18 Dec 2003 14:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3bz-0002dH-AA; Thu, 18 Dec 2003 14:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3bB-0002cG-OP for simple@optimus.ietf.org; Thu, 18 Dec 2003 14:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09586 for ; Thu, 18 Dec 2003 14:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3b9-0002Ub-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3b7-0002UB-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:10 -0500 Received: from law10-oe30.law10.hotmail.com ([64.4.14.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AX3b7-0002SC-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:09 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Dec 2003 11:13:37 -0800 Received: from 193.49.124.107 by law10-oe30.law10.hotmail.com with DAV; Thu, 18 Dec 2003 19:13:37 +0000 X-Originating-IP: [193.49.124.107] X-Originating-Email: [kissmylife@hotmail.com] X-Sender: kissmylife@hotmail.com Reply-To: "Patrick Park" From: "Patrick Park" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C3C557.51488680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 18 Dec 2003 19:13:37.0800 (UTC) FILETIME=[0A2F9880:01C3C59B] Subject: [Simple] SERVICE method Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 11:08:51 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C3C557.51488680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable N. Deason suggested the SERVICE method in his draft = (draft-deason-sipping-soap-sessions-00.txt), but it seems to be = rejected.=20 Microsoft is still using this SERVICE method between Windows Messenger = and SIP Communications Server that are supposed to follow industry = standard SIP/SIMPLE. Why was this SERVICE method rejected? Patrick Park ------=_NextPart_000_0055_01C3C557.51488680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

N. Deason = suggested the=20 SERVICE method in his draft (draft-deason-sipping-soap-sessions-00.txt), but = it seems=20 to be rejected.

Microsoft is still using this = SERVICE=20 method between Windows Messenger and SIP Communications Server that are = supposed=20 to follow industry standard SIP/SIMPLE.

Why was this SERVICE method=20 rejected?

 

Patrick Park

------=_NextPart_000_0055_01C3C557.51488680-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 14:15:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09633 for ; Thu, 18 Dec 2003 14:15:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3c8-0002eG-EP for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 14:15:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIJFCDf010174 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 14:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3c8-0002e1-AS for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 14:15:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09623 for ; Thu, 18 Dec 2003 14:15:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3c5-0002Wi-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 14:15:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3c4-0002Wb-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 14:15:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX3c3-0002WN-00; Thu, 18 Dec 2003 14:15:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3bz-0002dH-AA; Thu, 18 Dec 2003 14:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX3bB-0002cG-OP for simple@optimus.ietf.org; Thu, 18 Dec 2003 14:14:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09586 for ; Thu, 18 Dec 2003 14:14:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX3b9-0002Ub-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX3b7-0002UB-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:10 -0500 Received: from law10-oe30.law10.hotmail.com ([64.4.14.87] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AX3b7-0002SC-00 for simple@ietf.org; Thu, 18 Dec 2003 14:14:09 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 18 Dec 2003 11:13:37 -0800 Received: from 193.49.124.107 by law10-oe30.law10.hotmail.com with DAV; Thu, 18 Dec 2003 19:13:37 +0000 X-Originating-IP: [193.49.124.107] X-Originating-Email: [kissmylife@hotmail.com] X-Sender: kissmylife@hotmail.com Reply-To: "Patrick Park" From: "Patrick Park" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0055_01C3C557.51488680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: X-OriginalArrivalTime: 18 Dec 2003 19:13:37.0800 (UTC) FILETIME=[0A2F9880:01C3C59B] Subject: [Simple] SERVICE method Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 11:08:51 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0055_01C3C557.51488680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable N. Deason suggested the SERVICE method in his draft = (draft-deason-sipping-soap-sessions-00.txt), but it seems to be = rejected.=20 Microsoft is still using this SERVICE method between Windows Messenger = and SIP Communications Server that are supposed to follow industry = standard SIP/SIMPLE. Why was this SERVICE method rejected? Patrick Park ------=_NextPart_000_0055_01C3C557.51488680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

N. Deason = suggested the=20 SERVICE method in his draft (draft-deason-sipping-soap-sessions-00.txt), but = it seems=20 to be rejected.

Microsoft is still using this = SERVICE=20 method between Windows Messenger and SIP Communications Server that are = supposed=20 to follow industry standard SIP/SIMPLE.

Why was this SERVICE method=20 rejected?

 

Patrick Park

------=_NextPart_000_0055_01C3C557.51488680-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 18 16:35:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22149 for ; Thu, 18 Dec 2003 16:35:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5nW-0003hh-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 16:35:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5nV-0003hR-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 16:35:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX5nU-0003hL-00; Thu, 18 Dec 2003 16:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5nR-0001dR-8u; Thu, 18 Dec 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5nC-0001cz-00 for simple@optimus.ietf.org; Thu, 18 Dec 2003 16:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22120 for ; Thu, 18 Dec 2003 16:34:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5n6-0003gk-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5n4-0003gT-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:39 -0500 Received: from [143.209.238.79] (helo=auds955.usa.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1AX5n4-0003ec-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:38 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds955.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hBILXg3V029171; Thu, 18 Dec 2003 15:33:42 -0600 (CST) Message-ID: <3FE21D35.E03774AA@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@ietf.org, schulzrinne@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] location info in rpid Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 15:33:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit I just looked at draft-ietf-simple-rpid-00.txt and I didn't see a status extension, though I see a somewhat related (but not the same) . Is it time to update this draft with status ? Regards, Alex. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 16:35:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22195 for ; Thu, 18 Dec 2003 16:35:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5na-0001ef-Nj for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 16:35:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBILZAk2006355 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 16:35:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5na-0001eQ-JH for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 16:35:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22169 for ; Thu, 18 Dec 2003 16:35:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5nY-0003hx-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 16:35:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5nX-0003hl-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 16:35:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX5nU-0003hL-00; Thu, 18 Dec 2003 16:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5nR-0001dR-8u; Thu, 18 Dec 2003 16:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX5nC-0001cz-00 for simple@optimus.ietf.org; Thu, 18 Dec 2003 16:34:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22120 for ; Thu, 18 Dec 2003 16:34:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX5n6-0003gk-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX5n4-0003gT-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:39 -0500 Received: from [143.209.238.79] (helo=auds955.usa.alcatel.com) by ietf-mx with esmtp (Exim 4.12) id 1AX5n4-0003ec-00 for simple@ietf.org; Thu, 18 Dec 2003 16:34:38 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds955.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hBILXg3V029171; Thu, 18 Dec 2003 15:33:42 -0600 (CST) Message-ID: <3FE21D35.E03774AA@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: simple@ietf.org, schulzrinne@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] location info in rpid Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 15:33:41 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I just looked at draft-ietf-simple-rpid-00.txt and I didn't see a status extension, though I see a somewhat related (but not the same) . Is it time to update this draft with status ? Regards, Alex. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 18 17:02:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24221 for ; Thu, 18 Dec 2003 17:02:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Df-0005QF-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 17:02:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6Dd-0005Q0-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 17:02:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6Dd-0005Px-00; Thu, 18 Dec 2003 17:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Da-00035y-5v; Thu, 18 Dec 2003 17:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Cm-00033F-7i for simple@optimus.ietf.org; Thu, 18 Dec 2003 17:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24129 for ; Thu, 18 Dec 2003 17:01:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Cj-0005MP-00 for simple@ietf.org; Thu, 18 Dec 2003 17:01:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6CZ-0005L6-00 for simple@ietf.org; Thu, 18 Dec 2003 17:01:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AX6CX-0005Kr-00 for simple@ietf.org; Thu, 18 Dec 2003 17:00:57 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hBIM4s2T004377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 18 Dec 2003 16:04:54 -0600 From: "Dean Willis" To: "'Ben Campbell'" , "'Simple WG'" Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <00b501c3c5b2$5352c610$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FDE2594.9010709@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 16:00:17 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit > Although the sense of the room at IETF58 indicated we needed a way to > re-establish TCP connections without resignaling, subsequent list > discussion has indicated consensus that this will not work, > and we will > indeed have to re-signal. I am slightly concerned that many > of those who > favored reconnection without resignaling at the meeting have not > participated in the email thread. I must assume that means > they agree ;-) No, just that I've been busy. We're going to see a truckload of re-signaling. I suppose the user can be shielded from this by a more sophisticated user interface, but the wireless users aren't going to like it much. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 17:02:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24258 for ; Thu, 18 Dec 2003 17:02:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Dj-00037X-2C for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 17:02:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIM2Bxo011995 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 17:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Di-00037O-VH for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 17:02:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24240 for ; Thu, 18 Dec 2003 17:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Dg-0005QW-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 17:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6Df-0005QL-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 17:02:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6Dd-0005Px-00; Thu, 18 Dec 2003 17:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Da-00035y-5v; Thu, 18 Dec 2003 17:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6Cm-00033F-7i for simple@optimus.ietf.org; Thu, 18 Dec 2003 17:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24129 for ; Thu, 18 Dec 2003 17:01:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6Cj-0005MP-00 for simple@ietf.org; Thu, 18 Dec 2003 17:01:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6CZ-0005L6-00 for simple@ietf.org; Thu, 18 Dec 2003 17:01:06 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AX6CX-0005Kr-00 for simple@ietf.org; Thu, 18 Dec 2003 17:00:57 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hBIM4s2T004377 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 18 Dec 2003 16:04:54 -0600 From: "Dean Willis" To: "'Ben Campbell'" , "'Simple WG'" Subject: RE: [Simple] MSRP: Some thoughts on session updates Message-ID: <00b501c3c5b2$5352c610$e1036e3f@txdwillis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3FDE2594.9010709@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 16:00:17 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Although the sense of the room at IETF58 indicated we needed a way to > re-establish TCP connections without resignaling, subsequent list > discussion has indicated consensus that this will not work, > and we will > indeed have to re-signal. I am slightly concerned that many > of those who > favored reconnection without resignaling at the meeting have not > participated in the email thread. I must assume that means > they agree ;-) No, just that I've been busy. We're going to see a truckload of re-signaling. I suppose the user can be shielded from this by a more sophisticated user interface, but the wireless users aren't going to like it much. -- Dean _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Thu Dec 18 17:35:08 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25169 for ; Thu, 18 Dec 2003 17:35:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6jd-0006Ei-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 17:35:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6jc-0006Eb-00 for simple-archive@ietf.org; Thu, 18 Dec 2003 17:35:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6jc-0006EY-00; Thu, 18 Dec 2003 17:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6jW-0004bS-Hx; Thu, 18 Dec 2003 17:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6ih-0004Zd-1Y for simple@optimus.ietf.org; Thu, 18 Dec 2003 17:34:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25134 for ; Thu, 18 Dec 2003 17:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6ie-0006CK-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6id-0006CD-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AX6id-0006C3-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2003 22:34:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBIMXXBN018853; Thu, 18 Dec 2003 14:33:34 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET88332; Thu, 18 Dec 2003 17:33:32 -0500 (EST) Message-ID: <3FE22B3B.3000405@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 17:33:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > What are the use cases where an end point would end an old IM session only to start a new one, where the new one is not *replacing* the old one? I don't offhand have one for the simplest case, though give me some time and I may be able to come up with one. But I do have a slightly more complex one: - start out with call havine one MSRP session. - add a 2nd MSRP session for a file transfer. - lose connectivity on both. - decide to attempt restoration of only one. (perhaps because don't want to retry the file xfer automatically) - with your approach, the two original m-lines would each get a zero port number, and a 3rd m-line would would be used for the recovered session. How does the answerer know which session the new m-line replaces? As soon as there are multiple MSRP sessions the number of scenarios like this multiply. I think there must be some clear way for the endpoints to associate the new session with the old one. Note this is true whether lost messages are to be retransmitted or not. This affects the UI - does the old window, with its history of the conversation, get attached to the new session, or is a new window created? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Thu Dec 18 17:35:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25198 for ; Thu, 18 Dec 2003 17:35:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6jh-0004cO-1V for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 17:35:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIMZDcX017751 for simple-archive@odin.ietf.org; Thu, 18 Dec 2003 17:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6jg-0004cE-Uo for simple-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 17:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25185 for ; Thu, 18 Dec 2003 17:35:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6je-0006Et-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 17:35:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6jd-0006Em-00 for simple-web-archive@ietf.org; Thu, 18 Dec 2003 17:35:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX6jc-0006EY-00; Thu, 18 Dec 2003 17:35:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6jW-0004bS-Hx; Thu, 18 Dec 2003 17:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX6ih-0004Zd-1Y for simple@optimus.ietf.org; Thu, 18 Dec 2003 17:34:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25134 for ; Thu, 18 Dec 2003 17:34:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX6ie-0006CK-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX6id-0006CD-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AX6id-0006C3-00 for simple@ietf.org; Thu, 18 Dec 2003 17:34:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 18 Dec 2003 22:34:09 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBIMXXBN018853; Thu, 18 Dec 2003 14:33:34 -0800 (PST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET88332; Thu, 18 Dec 2003 17:33:32 -0500 (EST) Message-ID: <3FE22B3B.3000405@cisco.com> From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: bcampbell@dynamicsoft.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Dec 2003 17:33:31 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > > What are the use cases where an end point would end an old IM session only to start a new one, where the new one is not *replacing* the old one? I don't offhand have one for the simplest case, though give me some time and I may be able to come up with one. But I do have a slightly more complex one: - start out with call havine one MSRP session. - add a 2nd MSRP session for a file transfer. - lose connectivity on both. - decide to attempt restoration of only one. (perhaps because don't want to retry the file xfer automatically) - with your approach, the two original m-lines would each get a zero port number, and a 3rd m-line would would be used for the recovered session. How does the answerer know which session the new m-line replaces? As soon as there are multiple MSRP sessions the number of scenarios like this multiply. I think there must be some clear way for the endpoints to associate the new session with the old one. Note this is true whether lost messages are to be retransmitted or not. This affects the UI - does the old window, with its history of the conversation, get attached to the new session, or is a new window created? Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 19 07:36:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06872 for ; Fri, 19 Dec 2003 07:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJsB-0001Kg-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 07:36:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJrl-0001KS-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 07:36:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXJrl-0001Jn-00; Fri, 19 Dec 2003 07:36:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrN-0006dm-Be; Fri, 19 Dec 2003 07:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrI-0006ct-G7 for simple@optimus.ietf.org; Fri, 19 Dec 2003 07:35:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06831 for ; Fri, 19 Dec 2003 07:35:55 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJrC-0001JG-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJql-0001Io-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXJql-0001IU-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJCZCU13831 for ; Fri, 19 Dec 2003 14:35:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 19 Dec 2003 14:35:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 14:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C62C.8B92B194" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Thread-Topic: splitting of partial notify draft Thread-Index: AcPGLIuDX6e8OarKS22Rhruj162CKw== To: X-OriginalArrivalTime: 19 Dec 2003 12:35:12.0248 (UTC) FILETIME=[8BC79780:01C3C62C] Subject: [Simple] splitting of partial notify draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 14:35:11 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C62C.8B92B194 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo. So, I would like to know how people feel about this. Please vote for: 1) Split the document 2) Keep it as it is - Mikko =20 ------_=_NextPart_001_01C3C62C.8B92B194 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable splitting of partial notify draft

Hi folks,

Current partial notify draft = (draft-ietf-simple-partial-notify) contains new MIME type definition and = specifies how SUBSCRIBE/NOTIFY in presence event package is used with = that particular MIME type. One think which could be done is to slip the = current draft into two. One part would contain MIME type definition and = other would cover how that particular MIME type is used with presence = event package. This way it would probably be much easier to reuse = partial PIDF MIME type. Similar approach has been taken in = winfo.

So, I would like to know how people = feel about this. Please vote for:

1)
Split the document

2)
Keep it as it is

- Mikko 

------_=_NextPart_001_01C3C62C.8B92B194-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 19 07:37:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06918 for ; Fri, 19 Dec 2003 07:37:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJsa-0006my-O9 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 07:37:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJCbGeJ026087 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 07:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJsa-0006ma-C2 for simple-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 07:37:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06891 for ; Fri, 19 Dec 2003 07:37:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJsZ-0001Lb-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 07:37:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJsB-0001Ky-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 07:36:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXJrl-0001Jn-00; Fri, 19 Dec 2003 07:36:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrN-0006dm-Be; Fri, 19 Dec 2003 07:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrI-0006ct-G7 for simple@optimus.ietf.org; Fri, 19 Dec 2003 07:35:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06831 for ; Fri, 19 Dec 2003 07:35:55 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJrC-0001JG-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJql-0001Io-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:25 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXJql-0001IU-00 for simple@ietf.org; Fri, 19 Dec 2003 07:35:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJCZCU13831 for ; Fri, 19 Dec 2003 14:35:12 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 19 Dec 2003 14:35:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 14:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C62C.8B92B194" Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Thread-Topic: splitting of partial notify draft Thread-Index: AcPGLIuDX6e8OarKS22Rhruj162CKw== To: X-OriginalArrivalTime: 19 Dec 2003 12:35:12.0248 (UTC) FILETIME=[8BC79780:01C3C62C] Subject: [Simple] splitting of partial notify draft Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 14:35:11 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE, NO_REAL_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C62C.8B92B194 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo. So, I would like to know how people feel about this. Please vote for: 1) Split the document 2) Keep it as it is - Mikko =20 ------_=_NextPart_001_01C3C62C.8B92B194 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable splitting of partial notify draft

Hi folks,

Current partial notify draft = (draft-ietf-simple-partial-notify) contains new MIME type definition and = specifies how SUBSCRIBE/NOTIFY in presence event package is used with = that particular MIME type. One think which could be done is to slip the = current draft into two. One part would contain MIME type definition and = other would cover how that particular MIME type is used with presence = event package. This way it would probably be much easier to reuse = partial PIDF MIME type. Similar approach has been taken in = winfo.

So, I would like to know how people = feel about this. Please vote for:

1)
Split the document

2)
Keep it as it is

- Mikko 

------_=_NextPart_001_01C3C62C.8B92B194-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 19 09:46:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10675 for ; Fri, 19 Dec 2003 09:46:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLtC-00059f-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 09:46:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLtB-00059W-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 09:46:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLtB-00059T-00; Fri, 19 Dec 2003 09:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLtB-0003Zd-DZ; Fri, 19 Dec 2003 09:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLsK-0003YJ-W7 for simple@optimus.ietf.org; Fri, 19 Dec 2003 09:45:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10626 for ; Fri, 19 Dec 2003 09:45:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLsJ-00057O-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLsI-00057H-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXLsH-00057E-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJEj4U01847 for ; Fri, 19 Dec 2003 16:45:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 19 Dec 2003 16:45:04 +0200 Received: from nokia.com ([172.21.11.106]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:45:03 +0200 Message-ID: <3FE30EEF.2030609@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext mikko.lonnfors@nokia.com" CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2003 14:45:03.0244 (UTC) FILETIME=[AF933CC0:01C3C63E] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 16:45:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Hi, I think splitting the document is a good idea. Cheers, Aki ext mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 19 09:46:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10704 for ; Fri, 19 Dec 2003 09:46:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLtF-0003af-SF for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 09:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEk5Gs013795 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 09:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLtF-0003aQ-OW for simple-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:46:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10692 for ; Fri, 19 Dec 2003 09:46:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLtD-00059r-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 09:46:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLtC-00059j-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 09:46:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLtB-00059T-00; Fri, 19 Dec 2003 09:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLtB-0003Zd-DZ; Fri, 19 Dec 2003 09:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLsK-0003YJ-W7 for simple@optimus.ietf.org; Fri, 19 Dec 2003 09:45:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10626 for ; Fri, 19 Dec 2003 09:45:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLsJ-00057O-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLsI-00057H-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXLsH-00057E-00 for simple@ietf.org; Fri, 19 Dec 2003 09:45:06 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJEj4U01847 for ; Fri, 19 Dec 2003 16:45:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 19 Dec 2003 16:45:04 +0200 Received: from nokia.com ([172.21.11.106]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:45:03 +0200 Message-ID: <3FE30EEF.2030609@nokia.com> From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext mikko.lonnfors@nokia.com" CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Dec 2003 14:45:03.0244 (UTC) FILETIME=[AF933CC0:01C3C63E] Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 16:45:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I think splitting the document is a good idea. Cheers, Aki ext mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 19 16:24:23 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27684 for ; Fri, 19 Dec 2003 16:24:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS6h-0003KS-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6Z-0003I4-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6Z-0003H5-00; Fri, 19 Dec 2003 16:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6P-0003j6-FE; Fri, 19 Dec 2003 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRPR-0002bS-3Z for simple@optimus.ietf.org; Fri, 19 Dec 2003 15:39:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25517 for ; Fri, 19 Dec 2003 15:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRPP-0001Bq-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRPO-0001Bj-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AXRPO-0001BP-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:38 -0500 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBJKd7mR004074; Fri, 19 Dec 2003 15:39:10 -0500 (EST) Message-ID: <3FE361E5.3070504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 15:39:01 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Split. -Jonathan R. mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 19 16:24:42 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27794 for ; Fri, 19 Dec 2003 16:24:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS71-0003Ot-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6h-0003KL-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6g-0003HL-00; Fri, 19 Dec 2003 16:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6N-0003hl-O0; Fri, 19 Dec 2003 16:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRB9-00026Z-LT for simple@optimus.ietf.org; Fri, 19 Dec 2003 15:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24837 for ; Fri, 19 Dec 2003 15:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRB8-0000ZR-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRB7-0000ZE-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:53 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly05a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AXRB6-0000Z0-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:52 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05a.srv.mailcontrol.com (MailControl) with SMTP id hBJKOGdR014959; Fri, 19 Dec 2003 20:24:17 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Fri, 19 Dec 2003 20:26:50 +0000 Received: from neillatitude ([172.25.1.89]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 20:24:16 +0000 Reply-To: From: "Neil Deason" To: "'Patrick Park'" , Subject: RE: [Simple] SERVICE method Organization: Ubiquity Software Corporation Limited Message-ID: <000301c3c66e$14c91310$6d0119ac@na.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 19 Dec 2003 20:24:17.0132 (UTC) FILETIME=[137012C0:01C3C66E] X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 12:24:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit The main technical concerns raised about this draft were the same as those that lead to the notion that MESSAGE should only be for paging style messaging and not for IM chat sessions. Namely that due to the fact that SIP can be run over UDP there is not the necessary support for the congestion control required to preserve the stability of the Internet if SIP were to be widely used as a transport protocol for messaging. There are also issues due to UDP with the potential fragmentation of large messages. The design goal behind this work was to be able to leverage the combined benefits of SOAP and SIP. The later draft: http://users.rcn.com/neildeason/docs/draft-deason-mmusic-sdp-soap-00.htm l defines a more 'proper', although more complex, way of achieving this. - Neil. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Patrick Park Sent: Thursday, December 18, 2003 11:09 AM To: simple@ietf.org Subject: [Simple] SERVICE method N. Deason suggested the SERVICE method in his draft (draft-deason-sipping-soap-sessions-00.txt), but it seems to be rejected. Microsoft is still using this SERVICE method between Windows Messenger and SIP Communications Server that are supposed to follow industry standard SIP/SIMPLE. Why was this SERVICE method rejected? Patrick Park This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Fri Dec 19 16:24:58 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27907 for ; Fri, 19 Dec 2003 16:24:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS7H-0003Qt-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6r-0003Mx-00 for simple-archive@ietf.org; Fri, 19 Dec 2003 16:24:57 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AXS6p-0003Lg-00; Fri, 19 Dec 2003 16:24:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AXS6g-0003HV-9S; Fri, 19 Dec 2003 16:24:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6Y-0003pN-Cr; Fri, 19 Dec 2003 16:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRvi-0003Vy-5i for simple@optimus.ietf.org; Fri, 19 Dec 2003 16:13:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27348 for ; Fri, 19 Dec 2003 16:13:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRvg-0002oK-00 for simple@ietf.org; Fri, 19 Dec 2003 16:13:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRvf-0002oD-00 for simple@ietf.org; Fri, 19 Dec 2003 16:13:00 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AXRve-0002oA-00 for simple@ietf.org; Fri, 19 Dec 2003 16:12:59 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBJLCXnG071733; Fri, 19 Dec 2003 15:12:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE369B3.6040709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> In-Reply-To: <3FE22B3B.3000405@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 15:12:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: > >> >> What are the use cases where an end point would end an old IM session >> only to start a new one, where the new one is not *replacing* the old >> one? > > > I don't offhand have one for the simplest case, though give me some time > and I may be able to come up with one. > > But I do have a slightly more complex one: > > - start out with call havine one MSRP session. > > - add a 2nd MSRP session for a file transfer. > > - lose connectivity on both. > > - decide to attempt restoration of only one. > (perhaps because don't want to retry the file xfer automatically) > > - with your approach, the two original m-lines would each get a zero > port number, and a 3rd m-line would would be used for the > recovered session. > > How does the answerer know which session the new m-line replaces? > > As soon as there are multiple MSRP sessions the number of scenarios like > this multiply. I think there must be some clear way for the endpoints to > associate the new session with the old one. Note this is true whether > lost messages are to be retransmitted or not. This affects the UI - does > the old window, with its history of the conversation, get attached to > the new session, or is a new window created? So, how would you deal with that if these were RTP session? Back to the original question of how do we tell a "reconnect" offer from a "don't change anything" offer: I just had an offline discussion with Robert, where he points out that, if there is any change, the o line version will change. So it seems like we could say that, if the active sides sends a new offer with the same version number, it means no change. If it has a new version number, it means reconnect. (I note with great embarrassment that the examples in the MSRP draft are missing o lines...) This does not seem to solve Paul's issue of replacing one stream, but not another. It is not clear to me that this is an MSRP issue, though--how would you handle it for RTP? > > Paul > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Dec 19 16:25:14 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27969 for ; Fri, 19 Dec 2003 16:25:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS73-00048K-Mg for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLOjuJ015882 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:24:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS73-00043y-7Z for simple-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:24:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27779 for ; Fri, 19 Dec 2003 16:24:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS6z-0003Ol-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS6j-0003Kq-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:40 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6Z-0003H5-00; Fri, 19 Dec 2003 16:24:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6P-0003j6-FE; Fri, 19 Dec 2003 16:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRPR-0002bS-3Z for simple@optimus.ietf.org; Fri, 19 Dec 2003 15:39:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25517 for ; Fri, 19 Dec 2003 15:39:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRPP-0001Bq-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRPO-0001Bj-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AXRPO-0001BP-00 for simple@ietf.org; Fri, 19 Dec 2003 15:39:38 -0500 Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBJKd7mR004074; Fri, 19 Dec 2003 15:39:10 -0500 (EST) Message-ID: <3FE361E5.3070504@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 15:39:01 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Split. -Jonathan R. mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) contains > new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence > event package is used with that particular MIME type. One think which > could be done is to slip the current draft into two. One part would > contain MIME type definition and other would cover how that particular > MIME type is used with presence event package. This way it would > probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 19 16:25:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28056 for ; Fri, 19 Dec 2003 16:25:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7L-0004EU-Qe for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:25:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLP3PL016241 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7K-0004DZ-6g for simple-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:25:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27930 for ; Fri, 19 Dec 2003 16:24:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS7H-0003R5-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS72-0003PD-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:24:58 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXS6g-0003HL-00; Fri, 19 Dec 2003 16:24:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6N-0003hl-O0; Fri, 19 Dec 2003 16:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRB9-00026Z-LT for simple@optimus.ietf.org; Fri, 19 Dec 2003 15:24:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24837 for ; Fri, 19 Dec 2003 15:24:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRB8-0000ZR-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRB7-0000ZE-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:53 -0500 Received: from cluster-a.mailcontrol.com ([80.69.8.190] helo=rly05a.srv.mailcontrol.com) by ietf-mx with esmtp (Exim 4.12) id 1AXRB6-0000Z0-00 for simple@ietf.org; Fri, 19 Dec 2003 15:24:52 -0500 Received: from gbnewp0186s1.eu.ubiquity.net (news.ubiquity.net [194.202.146.92]) by rly05a.srv.mailcontrol.com (MailControl) with SMTP id hBJKOGdR014959; Fri, 19 Dec 2003 20:24:17 GMT Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for cluster-a.mailcontrol.com [80.69.8.190]) with SMTP; Fri, 19 Dec 2003 20:26:50 +0000 Received: from neillatitude ([172.25.1.89]) by GBNEWP0758M.eu.ubiquity.net with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Dec 2003 20:24:16 +0000 Reply-To: From: "Neil Deason" To: "'Patrick Park'" , Subject: RE: [Simple] SERVICE method Organization: Ubiquity Software Corporation Limited Message-ID: <000301c3c66e$14c91310$6d0119ac@na.ubiquity.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: X-OriginalArrivalTime: 19 Dec 2003 20:24:17.0132 (UTC) FILETIME=[137012C0:01C3C66E] X-Scanned-By: MailControl A-02-00-00 (www.mailcontrol.com) Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 12:24:18 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The main technical concerns raised about this draft were the same as those that lead to the notion that MESSAGE should only be for paging style messaging and not for IM chat sessions. Namely that due to the fact that SIP can be run over UDP there is not the necessary support for the congestion control required to preserve the stability of the Internet if SIP were to be widely used as a transport protocol for messaging. There are also issues due to UDP with the potential fragmentation of large messages. The design goal behind this work was to be able to leverage the combined benefits of SOAP and SIP. The later draft: http://users.rcn.com/neildeason/docs/draft-deason-mmusic-sdp-soap-00.htm l defines a more 'proper', although more complex, way of achieving this. - Neil. -----Original Message----- From: simple-admin@ietf.org [mailto:simple-admin@ietf.org] On Behalf Of Patrick Park Sent: Thursday, December 18, 2003 11:09 AM To: simple@ietf.org Subject: [Simple] SERVICE method N. Deason suggested the SERVICE method in his draft (draft-deason-sipping-soap-sessions-00.txt), but it seems to be rejected. Microsoft is still using this SERVICE method between Windows Messenger and SIP Communications Server that are supposed to follow industry standard SIP/SIMPLE. Why was this SERVICE method rejected? Patrick Park This message has been scanned for viruses by MailControl - www.mailcontrol.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Fri Dec 19 16:25:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28096 for ; Fri, 19 Dec 2003 16:25:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7Q-0004Gb-3D for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:25:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJLP8D0016395 for simple-archive@odin.ietf.org; Fri, 19 Dec 2003 16:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS7P-0004FW-V4 for simple-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 16:25:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27943 for ; Fri, 19 Dec 2003 16:25:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXS7L-0003S2-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:25:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXS7H-0003RB-00 for simple-web-archive@ietf.org; Fri, 19 Dec 2003 16:25:02 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AXS6p-0003Lg-00; Fri, 19 Dec 2003 16:24:31 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AXS6g-0003HV-9S; Fri, 19 Dec 2003 16:24:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXS6Y-0003pN-Cr; Fri, 19 Dec 2003 16:24:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXRvi-0003Vy-5i for simple@optimus.ietf.org; Fri, 19 Dec 2003 16:13:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27348 for ; Fri, 19 Dec 2003 16:13:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXRvg-0002oK-00 for simple@ietf.org; Fri, 19 Dec 2003 16:13:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXRvf-0002oD-00 for simple@ietf.org; Fri, 19 Dec 2003 16:13:00 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AXRve-0002oA-00 for simple@ietf.org; Fri, 19 Dec 2003 16:12:59 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hBJLCXnG071733; Fri, 19 Dec 2003 15:12:46 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FE369B3.6040709@dynamicsoft.com> From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat CC: hisham.khartabil@nokia.com, simple@ietf.org Subject: Re: [Simple] MSRP: Some thoughts on session updates References: <2038BCC78B1AD641891A0D1AE133DBB701797539@esebe019.ntc.nokia.com> <3FE22B3B.3000405@cisco.com> In-Reply-To: <3FE22B3B.3000405@cisco.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 19 Dec 2003 15:12:19 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > hisham.khartabil@nokia.com wrote: > >> >> What are the use cases where an end point would end an old IM session >> only to start a new one, where the new one is not *replacing* the old >> one? > > > I don't offhand have one for the simplest case, though give me some time > and I may be able to come up with one. > > But I do have a slightly more complex one: > > - start out with call havine one MSRP session. > > - add a 2nd MSRP session for a file transfer. > > - lose connectivity on both. > > - decide to attempt restoration of only one. > (perhaps because don't want to retry the file xfer automatically) > > - with your approach, the two original m-lines would each get a zero > port number, and a 3rd m-line would would be used for the > recovered session. > > How does the answerer know which session the new m-line replaces? > > As soon as there are multiple MSRP sessions the number of scenarios like > this multiply. I think there must be some clear way for the endpoints to > associate the new session with the old one. Note this is true whether > lost messages are to be retransmitted or not. This affects the UI - does > the old window, with its history of the conversation, get attached to > the new session, or is a new window created? So, how would you deal with that if these were RTP session? Back to the original question of how do we tell a "reconnect" offer from a "don't change anything" offer: I just had an offline discussion with Robert, where he points out that, if there is any change, the o line version will change. So it seems like we could say that, if the active sides sends a new offer with the same version number, it means no change. If it has a new version number, it means reconnect. (I note with great embarrassment that the examples in the MSRP draft are missing o lines...) This does not seem to solve Paul's issue of replacing one stream, but not another. It is not clear to me that this is an MSRP issue, though--how would you handle it for RTP? > > Paul > > > _______________________________________________ > 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-admin@ietf.org Mon Dec 22 07:56:12 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13260 for ; Mon, 22 Dec 2003 07:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPbZ-0000d6-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 07:56:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPbY-0000cz-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 07:56:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYPbY-0000ct-00; Mon, 22 Dec 2003 07:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPbN-0007n4-Ko; Mon, 22 Dec 2003 07:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPad-0007mL-NJ for simple@optimus.ietf.org; Mon, 22 Dec 2003 07:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13217 for ; Mon, 22 Dec 2003 07:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPac-0000an-00 for simple@ietf.org; Mon, 22 Dec 2003 07:55:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPaK-0000aX-00 for simple@ietf.org; Mon, 22 Dec 2003 07:54:56 -0500 Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1AYPaJ-0000Z5-00 for simple@ietf.org; Mon, 22 Dec 2003 07:54:56 -0500 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id hBMCrtdH013437; Mon, 22 Dec 2003 21:53:55 +0900 (JST) Received: from mip2.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HQA001F5RTVMK@ntt.com>; Mon, 22 Dec 2003 21:53:55 +0900 (JST) From: "Ashir Ahmed" To: hisham.khartabil@nokia.com Cc: simple@ietf.org Message-id: <000901c3c88a$3e14f9f0$9f44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Subject: [Simple] filter attribute question Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 21:50:56 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit what is the difference between "changed-from" and "changed-to" attribute in the element in draft-khartabil-simple-filter-format-00.txt doc? Can someone provide an example? Ashir _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 22 07:56:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13288 for ; Mon, 22 Dec 2003 07:56:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPbb-0007o9-Je for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 07:56:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMCuFvG030007 for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 07:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPbb-0007nu-Ds for simple-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 07:56:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13279 for ; Mon, 22 Dec 2003 07:56:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPba-0000dH-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 07:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPbZ-0000dA-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 07:56:14 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYPbY-0000ct-00; Mon, 22 Dec 2003 07:56:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPbN-0007n4-Ko; Mon, 22 Dec 2003 07:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPad-0007mL-NJ for simple@optimus.ietf.org; Mon, 22 Dec 2003 07:55:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13217 for ; Mon, 22 Dec 2003 07:55:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPac-0000an-00 for simple@ietf.org; Mon, 22 Dec 2003 07:55:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPaK-0000aX-00 for simple@ietf.org; Mon, 22 Dec 2003 07:54:56 -0500 Received: from mgw1.noc.ntt.com ([210.163.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1AYPaJ-0000Z5-00 for simple@ietf.org; Mon, 22 Dec 2003 07:54:56 -0500 Received: from mop2.noc.ntt.com by mgw1.noc.ntt.com (NTT-Com MailSV) with ESMTP id hBMCrtdH013437; Mon, 22 Dec 2003 21:53:55 +0900 (JST) Received: from mip2.noc.ntt.com (mvi3.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HQA001F5RTVMK@ntt.com>; Mon, 22 Dec 2003 21:53:55 +0900 (JST) From: "Ashir Ahmed" To: hisham.khartabil@nokia.com Cc: simple@ietf.org Message-id: <000901c3c88a$3e14f9f0$9f44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> Content-Transfer-Encoding: 7bit Subject: [Simple] filter attribute question Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 21:50:56 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit what is the difference between "changed-from" and "changed-to" attribute in the element in draft-khartabil-simple-filter-format-00.txt doc? Can someone provide an example? Ashir _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 22 08:01:05 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13401 for ; Mon, 22 Dec 2003 08:01:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPgH-0000l9-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 08:01:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPgH-0000l2-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 08:01:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYPgG-0000kz-00; Mon, 22 Dec 2003 08:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPgE-0007w8-2S; Mon, 22 Dec 2003 08:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPfi-0007vF-Dr for simple@optimus.ietf.org; Mon, 22 Dec 2003 08:00:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13390 for ; Mon, 22 Dec 2003 08:00:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPfh-0000kU-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPfg-0000kN-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:29 -0500 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 1AYPfg-0000j3-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:28 -0500 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id hBMCxuv9006840; Mon, 22 Dec 2003 21:59:56 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HQA001HYS3WMK@ntt.com>; Mon, 22 Dec 2003 21:59:56 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] filter attribute question To: "Ashir Ahmed" , hisham.khartabil@nokia.com Cc: simple@ietf.org Message-id: <001101c3c88b$1545a140$9f44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> <000901c3c88a$3e14f9f0$9f44320a@nttu26skyyrabi> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 21:56:57 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sorry the question was: what is the difference between "changed-to" and "changed-by" attribute? ----- Original Message ----- From: "Ashir Ahmed" To: Cc: Sent: Monday, December 22, 2003 9:50 PM Subject: [Simple] filter attribute question > what is the difference between "changed-from" and "changed-to" attribute in > the element in draft-khartabil-simple-filter-format-00.txt doc? > Can someone provide an example? > > Ashir > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 22 08:01:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13430 for ; Mon, 22 Dec 2003 08:01:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPgK-00080T-2i for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 08:01:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMD18kF030771 for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 08:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPgJ-00080E-VT for simple-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 08:01:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13418 for ; Mon, 22 Dec 2003 08:01:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPgJ-0000lK-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 08:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPgI-0000lC-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 08:01:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYPgG-0000kz-00; Mon, 22 Dec 2003 08:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPgE-0007w8-2S; Mon, 22 Dec 2003 08:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYPfi-0007vF-Dr for simple@optimus.ietf.org; Mon, 22 Dec 2003 08:00:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13390 for ; Mon, 22 Dec 2003 08:00:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYPfh-0000kU-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYPfg-0000kN-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:29 -0500 Received: from mgw2.noc.ntt.com ([210.163.32.69]) by ietf-mx with esmtp (Exim 4.12) id 1AYPfg-0000j3-00 for simple@ietf.org; Mon, 22 Dec 2003 08:00:28 -0500 Received: from mop2.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id hBMCxuv9006840; Mon, 22 Dec 2003 21:59:56 +0900 (JST) Received: from mip2.noc.ntt.com (mvi2.noc.ntt.com) by mop2.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0HQA001HYS3WMK@ntt.com>; Mon, 22 Dec 2003 21:59:56 +0900 (JST) Content-return: prohibited From: "Ashir Ahmed" Subject: Re: [Simple] filter attribute question To: "Ashir Ahmed" , hisham.khartabil@nokia.com Cc: simple@ietf.org Message-id: <001101c3c88b$1545a140$9f44320a@nttu26skyyrabi> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <2038BCC78B1AD641891A0D1AE133DBB70179753A@esebe019.ntc.nokia.com> <000901c3c88a$3e14f9f0$9f44320a@nttu26skyyrabi> Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 21:56:57 +0900 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sorry the question was: what is the difference between "changed-to" and "changed-by" attribute? ----- Original Message ----- From: "Ashir Ahmed" To: Cc: Sent: Monday, December 22, 2003 9:50 PM Subject: [Simple] filter attribute question > what is the difference between "changed-from" and "changed-to" attribute in > the element in draft-khartabil-simple-filter-format-00.txt doc? > Can someone provide an example? > > Ashir > > > _______________________________________________ > 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-admin@ietf.org Mon Dec 22 10:13:18 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20283 for ; Mon, 22 Dec 2003 10:13:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRk3-0006AN-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 10:13:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRk2-0006AG-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 10:13:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYRk2-0006AD-00; Mon, 22 Dec 2003 10:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRjx-0004Yz-L8; Mon, 22 Dec 2003 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRjN-0004YU-Ss for simple@optimus.ietf.org; Mon, 22 Dec 2003 10:12:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20182 for ; Mon, 22 Dec 2003 10:12:18 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRjH-0006A4-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRjH-00069x-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AYRjG-00068w-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:18 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBMFCFU27817 for ; Mon, 22 Dec 2003 17:12:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Dec 2003 17:12:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Dec 2003 17:12:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] filter attribute question Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B163@esebe019.ntc.nokia.com> Thread-Topic: [Simple] filter attribute question Thread-Index: AcPIi5U0Tzn9Hlq+TiW3bb8PBu5OjAAEUzJw To: Cc: X-OriginalArrivalTime: 22 Dec 2003 15:12:15.0181 (UTC) FILETIME=[FB864FD0:01C3C89D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 17:12:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable If the element in question is measurable in units (eg: seconds), then = the subscriber can filter using changed-by without needing to know the = previous value. eg: send me a notification if the value of element x has = changed by m. Changed-from and changed-to can also be used for elements whose value is = measurable in units. eg: send me a notification if the value of element = x has changed from m to n. In this case, you are explicitly stating the = value before and after. With changed-by, you are stating the delta. Changed-to is also usable for elements that are not measured in units. = eg: send me notification if the value of element x has changed to xyz = (from abc). Hope this helps. Hisham > -----Original Message----- > From: ext Ashir Ahmed [mailto:a.ahmed@ntt.com] > Sent: 22.December.2003 14:57 > To: Ashir Ahmed; Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] filter attribute question >=20 >=20 > Sorry the question was: > what is the difference between "changed-to" and "changed-by"=20 > attribute? >=20 > ----- Original Message -----=20 > From: "Ashir Ahmed" > To: > Cc: > Sent: Monday, December 22, 2003 9:50 PM > Subject: [Simple] filter attribute question >=20 >=20 > > what is the difference between "changed-from" and=20 > "changed-to" attribute > in > > the element in=20 > draft-khartabil-simple-filter-format-00.txt doc? > > Can someone provide an example? > > > > Ashir > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Mon Dec 22 10:13:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20328 for ; Mon, 22 Dec 2003 10:13:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRk7-0004Zs-2N for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 10:13:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMFDBUh017590 for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 10:13:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRk6-0004Zd-T7 for simple-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 10:13:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20266 for ; Mon, 22 Dec 2003 10:13:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRk4-0006AY-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 10:13:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRk3-0006AR-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 10:13:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYRk2-0006AD-00; Mon, 22 Dec 2003 10:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRjx-0004Yz-L8; Mon, 22 Dec 2003 10:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYRjN-0004YU-Ss for simple@optimus.ietf.org; Mon, 22 Dec 2003 10:12:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20182 for ; Mon, 22 Dec 2003 10:12:18 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYRjH-0006A4-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYRjH-00069x-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AYRjG-00068w-00 for simple@ietf.org; Mon, 22 Dec 2003 10:12:18 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBMFCFU27817 for ; Mon, 22 Dec 2003 17:12:15 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 22 Dec 2003 17:12:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 22 Dec 2003 17:12:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] filter attribute question Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70118B163@esebe019.ntc.nokia.com> Thread-Topic: [Simple] filter attribute question Thread-Index: AcPIi5U0Tzn9Hlq+TiW3bb8PBu5OjAAEUzJw To: Cc: X-OriginalArrivalTime: 22 Dec 2003 15:12:15.0181 (UTC) FILETIME=[FB864FD0:01C3C89D] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 17:12:14 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable If the element in question is measurable in units (eg: seconds), then = the subscriber can filter using changed-by without needing to know the = previous value. eg: send me a notification if the value of element x has = changed by m. Changed-from and changed-to can also be used for elements whose value is = measurable in units. eg: send me a notification if the value of element = x has changed from m to n. In this case, you are explicitly stating the = value before and after. With changed-by, you are stating the delta. Changed-to is also usable for elements that are not measured in units. = eg: send me notification if the value of element x has changed to xyz = (from abc). Hope this helps. Hisham > -----Original Message----- > From: ext Ashir Ahmed [mailto:a.ahmed@ntt.com] > Sent: 22.December.2003 14:57 > To: Ashir Ahmed; Khartabil Hisham (NMP-MSW/Helsinki) > Cc: simple@ietf.org > Subject: Re: [Simple] filter attribute question >=20 >=20 > Sorry the question was: > what is the difference between "changed-to" and "changed-by"=20 > attribute? >=20 > ----- Original Message -----=20 > From: "Ashir Ahmed" > To: > Cc: > Sent: Monday, December 22, 2003 9:50 PM > Subject: [Simple] filter attribute question >=20 >=20 > > what is the difference between "changed-from" and=20 > "changed-to" attribute > in > > the element in=20 > draft-khartabil-simple-filter-format-00.txt doc? > > Can someone provide an example? > > > > Ashir > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Mon Dec 22 10:49:00 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22697 for ; Mon, 22 Dec 2003 10:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSIi-000020-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 10:48:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSII-00001k-00 for simple-archive@ietf.org; Mon, 22 Dec 2003 10:48:31 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYSII-00001H-00; Mon, 22 Dec 2003 10:48:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYSHn-0005ZP-D5; Mon, 22 Dec 2003 10:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSGr-0006AB-HG; Mon, 22 Dec 2003 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSFs-00069U-Mz for simple@optimus.ietf.org; Mon, 22 Dec 2003 10:46:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22656 for ; Mon, 22 Dec 2003 10:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSFl-0007mW-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSFL-0007mL-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:27 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AYSFL-0007ll-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:27 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBMFihe08132 for ; Mon, 22 Dec 2003 09:44:44 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Dec 2003 14:51:54 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF7D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , mikko.lonnfors@nokia.com Cc: simple@ietf.org Subject: RE: [Simple] splitting of partial notify draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 14:51:53 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Split. Keeping it consistent with other document structures and scope is the correct way to go. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 19 December 2003 20:39 > To: mikko.lonnfors@nokia.com > Cc: simple@ietf.org > Subject: Re: [Simple] splitting of partial notify draft > > > Split. > > -Jonathan R. > > mikko.lonnfors@nokia.com wrote: > > > Hi folks, > > > > Current partial notify draft > (draft-ietf-simple-partial-notify) contains > > new MIME type definition and specifies how SUBSCRIBE/NOTIFY > in presence > > event package is used with that particular MIME type. One > think which > > could be done is to slip the current draft into two. One part would > > contain MIME type definition and other would cover how that > particular > > MIME type is used with presence event package. This way it would > > probably be much easier to reuse partial PIDF MIME type. Similar > > approach has been taken in winfo. > > > > So, I would like to know how people feel about this. Please > vote for: > > > > 1) > > Split the document > > > > 2) > > Keep it as it is > > > > - Mikko > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Dec 22 10:49:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22734 for ; Mon, 22 Dec 2003 10:49:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSJG-0006FX-Mo for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 10:49:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMFnUPm024020 for simple-archive@odin.ietf.org; Mon, 22 Dec 2003 10:49:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSJG-0006FL-HQ for simple-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 10:49:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22730 for ; Mon, 22 Dec 2003 10:49:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSJ9-00002p-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 10:49:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSIj-00002c-00 for simple-web-archive@ietf.org; Mon, 22 Dec 2003 10:48:57 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AYSII-00001H-00; Mon, 22 Dec 2003 10:48:30 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AYSHn-0005ZP-D5; Mon, 22 Dec 2003 10:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSGr-0006AB-HG; Mon, 22 Dec 2003 10:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSFs-00069U-Mz for simple@optimus.ietf.org; Mon, 22 Dec 2003 10:46:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22656 for ; Mon, 22 Dec 2003 10:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSFl-0007mW-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSFL-0007mL-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:27 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AYSFL-0007ll-00 for simple@ietf.org; Mon, 22 Dec 2003 10:45:27 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBMFihe08132 for ; Mon, 22 Dec 2003 09:44:44 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 22 Dec 2003 14:51:54 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF7D@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Jonathan Rosenberg'" , mikko.lonnfors@nokia.com Cc: simple@ietf.org Subject: RE: [Simple] splitting of partial notify draft MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Dec 2003 14:51:53 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Split. Keeping it consistent with other document structures and scope is the correct way to go. regards Keith > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 19 December 2003 20:39 > To: mikko.lonnfors@nokia.com > Cc: simple@ietf.org > Subject: Re: [Simple] splitting of partial notify draft > > > Split. > > -Jonathan R. > > mikko.lonnfors@nokia.com wrote: > > > Hi folks, > > > > Current partial notify draft > (draft-ietf-simple-partial-notify) contains > > new MIME type definition and specifies how SUBSCRIBE/NOTIFY > in presence > > event package is used with that particular MIME type. One > think which > > could be done is to slip the current draft into two. One part would > > contain MIME type definition and other would cover how that > particular > > MIME type is used with presence event package. This way it would > > probably be much easier to reuse partial PIDF MIME type. Similar > > approach has been taken in winfo. > > > > So, I would like to know how people feel about this. Please > vote for: > > > > 1) > > Split the document > > > > 2) > > Keep it as it is > > > > - Mikko > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > 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-admin@ietf.org Tue Dec 23 10:50:56 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25232 for ; Tue, 23 Dec 2003 10:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYooE-000377-00 for simple-archive@ietf.org; Tue, 23 Dec 2003 10:50:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYolT-00034q-00 for simple-archive@ietf.org; Tue, 23 Dec 2003 10:48:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYolT-00034l-00; Tue, 23 Dec 2003 10:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYolN-0004fG-IE; Tue, 23 Dec 2003 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYokX-0004eG-Jl for simple@optimus.ietf.org; Tue, 23 Dec 2003 10:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25161 for ; Tue, 23 Dec 2003 10:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYokV-0002zE-00 for simple@ietf.org; Tue, 23 Dec 2003 10:47:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYoco-0002jh-00 for simple@ietf.org; Tue, 23 Dec 2003 10:39:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AYoco-0002f2-00 for simple@ietf.org; Tue, 23 Dec 2003 10:39:10 -0500 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBNFcCmR005166; Tue, 23 Dec 2003 10:38:12 -0500 (EST) Message-ID: <3FE8615E.3070002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: simple@ietf.org, schulzrinne@cs.columbia.edu Subject: Re: [Simple] location info in rpid References: <3FE21D35.E03774AA@alcatel.com> In-Reply-To: <3FE21D35.E03774AA@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Dec 2003 10:38:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Not sure if this was answered. Geolocation information will be conveyed using the geopriv work: http://www.ietf.org/internet-drafts/draft-peterson-geopriv-pidf-lo-02.txt Though it still has an individual filename, my understanding is that this is a working item of geopriv. -Jonathan R. Alex Audu wrote: > I just looked at draft-ietf-simple-rpid-00.txt and I didn't see a > status extension, > though I see a somewhat related (but not the same) . Is it > time to update > this draft with status ? > > Regards, > Alex. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 23 10:51:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25268 for ; Tue, 23 Dec 2003 10:51:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYooG-0004pc-Px for simple-archive@odin.ietf.org; Tue, 23 Dec 2003 10:51:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNFp0ln018568 for simple-archive@odin.ietf.org; Tue, 23 Dec 2003 10:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYooG-0004pP-Ms for simple-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 10:51:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25227 for ; Tue, 23 Dec 2003 10:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYooD-000377-00 for simple-web-archive@ietf.org; Tue, 23 Dec 2003 10:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYolU-00034y-00 for simple-web-archive@ietf.org; Tue, 23 Dec 2003 10:48:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYolT-00034l-00; Tue, 23 Dec 2003 10:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYolN-0004fG-IE; Tue, 23 Dec 2003 10:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYokX-0004eG-Jl for simple@optimus.ietf.org; Tue, 23 Dec 2003 10:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25161 for ; Tue, 23 Dec 2003 10:47:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYokV-0002zE-00 for simple@ietf.org; Tue, 23 Dec 2003 10:47:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYoco-0002jh-00 for simple@ietf.org; Tue, 23 Dec 2003 10:39:11 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AYoco-0002f2-00 for simple@ietf.org; Tue, 23 Dec 2003 10:39:10 -0500 Received: from dynamicsoft.com ([63.113.46.9]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBNFcCmR005166; Tue, 23 Dec 2003 10:38:12 -0500 (EST) Message-ID: <3FE8615E.3070002@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alex.audu@alcatel.com CC: simple@ietf.org, schulzrinne@cs.columbia.edu Subject: Re: [Simple] location info in rpid References: <3FE21D35.E03774AA@alcatel.com> In-Reply-To: <3FE21D35.E03774AA@alcatel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Dec 2003 10:38:06 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Not sure if this was answered. Geolocation information will be conveyed using the geopriv work: http://www.ietf.org/internet-drafts/draft-peterson-geopriv-pidf-lo-02.txt Though it still has an individual filename, my understanding is that this is a working item of geopriv. -Jonathan R. Alex Audu wrote: > I just looked at draft-ietf-simple-rpid-00.txt and I didn't see a > status extension, > though I see a somewhat related (but not the same) . Is it > time to update > this draft with status ? > > Regards, > Alex. > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 23 17:20:06 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15910 for ; Tue, 23 Dec 2003 17:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYusp-0001zv-00 for simple-archive@ietf.org; Tue, 23 Dec 2003 17:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYur3-0001nX-00 for simple-archive@ietf.org; Tue, 23 Dec 2003 17:18:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AYupd-0001fz-01; Tue, 23 Dec 2003 17:16:49 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AYueV-0003s7-F3; Tue, 23 Dec 2003 17:05:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYueG-0003Y7-B4; Tue, 23 Dec 2003 17:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYudP-0003WS-Ux for simple@optimus.ietf.org; Tue, 23 Dec 2003 17:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15527 for ; Tue, 23 Dec 2003 17:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYudL-0001Hl-00 for simple@ietf.org; Tue, 23 Dec 2003 17:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYucF-0001CQ-00 for simple@ietf.org; Tue, 23 Dec 2003 17:03:00 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AYuZy-000119-00 for simple@ietf.org; Tue, 23 Dec 2003 17:00:42 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hBNM01Of004495; Tue, 23 Dec 2003 16:00:01 -0600 (CST) Message-ID: <3FE8BADF.D5E0F319@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: multipart/alternative; boundary="------------9A63C1FC49D97C3F7BE2F540" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Dec 2003 16:00:00 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --------------9A63C1FC49D97C3F7BE2F540 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think I like the document in its current form. Is there a technical or ligistic reason for splitting it? The current form is compact and keeping everything in one place aids readability. Cheers, Alex. mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) > contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY > in presence event package is used with that particular MIME type. One > think which could be done is to slip the current draft into two. One > part would contain MIME type definition and other would cover how that > particular MIME type is used with presence event package. This way it > would probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko --------------9A63C1FC49D97C3F7BE2F540 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I think I like the document in its current form. Is there a technical or ligistic reason for
splitting it? The current form is compact and keeping everything in one place aids
readability.

Cheers,
Alex.

mikko.lonnfors@nokia.com wrote:

Hi folks,

Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo.

So, I would like to know how people feel about this. Please vote for:

1)
Split the document

2)
Keep it as it is

- Mikko

--------------9A63C1FC49D97C3F7BE2F540-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 23 17:20:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16095 for ; Tue, 23 Dec 2003 17:20:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYuss-0004Kk-N9 for simple-archive@odin.ietf.org; Tue, 23 Dec 2003 17:20:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNMKA83016654 for simple-archive@odin.ietf.org; Tue, 23 Dec 2003 17:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYuss-0004KX-Jb for simple-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 17:20:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15913 for ; Tue, 23 Dec 2003 17:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYusq-000201-00 for simple-web-archive@ietf.org; Tue, 23 Dec 2003 17:20:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYur4-0001ne-00 for simple-web-archive@ietf.org; Tue, 23 Dec 2003 17:18:19 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AYupd-0001fz-01; Tue, 23 Dec 2003 17:16:49 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AYueV-0003s7-F3; Tue, 23 Dec 2003 17:05:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYueG-0003Y7-B4; Tue, 23 Dec 2003 17:05:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYudP-0003WS-Ux for simple@optimus.ietf.org; Tue, 23 Dec 2003 17:04:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15527 for ; Tue, 23 Dec 2003 17:04:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYudL-0001Hl-00 for simple@ietf.org; Tue, 23 Dec 2003 17:04:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYucF-0001CQ-00 for simple@ietf.org; Tue, 23 Dec 2003 17:03:00 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1AYuZy-000119-00 for simple@ietf.org; Tue, 23 Dec 2003 17:00:42 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id hBNM01Of004495; Tue, 23 Dec 2003 16:00:01 -0600 (CST) Message-ID: <3FE8BADF.D5E0F319@alcatel.com> From: Alex Audu Reply-To: alex.audu@alcatel.com X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mikko.lonnfors@nokia.com CC: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727B@esebe004.ntc.nokia.com> Content-Type: multipart/alternative; boundary="------------9A63C1FC49D97C3F7BE2F540" Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Dec 2003 16:00:00 -0600 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 --------------9A63C1FC49D97C3F7BE2F540 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I think I like the document in its current form. Is there a technical or ligistic reason for splitting it? The current form is compact and keeping everything in one place aids readability. Cheers, Alex. mikko.lonnfors@nokia.com wrote: > Hi folks, > > Current partial notify draft (draft-ietf-simple-partial-notify) > contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY > in presence event package is used with that particular MIME type. One > think which could be done is to slip the current draft into two. One > part would contain MIME type definition and other would cover how that > particular MIME type is used with presence event package. This way it > would probably be much easier to reuse partial PIDF MIME type. Similar > approach has been taken in winfo. > > So, I would like to know how people feel about this. Please vote for: > > 1) > Split the document > > 2) > Keep it as it is > > - Mikko --------------9A63C1FC49D97C3F7BE2F540 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

I think I like the document in its current form. Is there a technical or ligistic reason for
splitting it? The current form is compact and keeping everything in one place aids
readability.

Cheers,
Alex.

mikko.lonnfors@nokia.com wrote:

Hi folks,

Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo.

So, I would like to know how people feel about this. Please vote for:

1)
Split the document

2)
Keep it as it is

- Mikko

--------------9A63C1FC49D97C3F7BE2F540-- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Sun Dec 28 05:23:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29107 for ; Sun, 28 Dec 2003 05:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaY54-00023R-00 for simple-archive@ietf.org; Sun, 28 Dec 2003 05:23:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaY3A-00021I-00 for simple-archive@ietf.org; Sun, 28 Dec 2003 05:21:33 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AaY1n-0001z8-00; Sun, 28 Dec 2003 05:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY1h-00056W-Fk; Sun, 28 Dec 2003 05:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY1G-00055k-59 for simple@optimus.ietf.org; Sun, 28 Dec 2003 05:19:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29026 for ; Sun, 28 Dec 2003 05:19:30 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaY1C-0001xt-00 for simple@ietf.org; Sun, 28 Dec 2003 05:19:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaXzX-0001vc-00 for simple@ietf.org; Sun, 28 Dec 2003 05:17:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AaXyi-0001qw-00 for simple@ietf.org; Sun, 28 Dec 2003 05:16:56 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBSAGtU20873 for ; Sun, 28 Dec 2003 12:16:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 28 Dec 2003 12:16:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 28 Dec 2003 12:16:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] splitting of partial notify draft Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727C@esebe004.ntc.nokia.com> Thread-Topic: [Simple] splitting of partial notify draft Thread-Index: AcPJoDmlkqKWf/l4QPiByQOdt7BbXQDiffKQ To: Cc: X-OriginalArrivalTime: 28 Dec 2003 10:16:54.0840 (UTC) FILETIME=[B7DB5B80:01C3CD2B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 28 Dec 2003 12:16:54 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi, Main motivation to slip the current document is to improve reusability of the MIME type ('application/pidf-partial+xml'). There are other places than presence event package where this content format may be used. If there wouldn't be any other usages for this then keeping document in its current form would make sense. But if somebody writes a new draft which utilized 'application/pidf-partial+xml' MIME type then it is much more convenient if there is a standalone definition for that. - Mikko =20 -----Original Message----- From: ext Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Wednesday, December 24, 2003 12:00 AM To: Lonnfors Mikko (NRC/Helsinki) Cc: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft Hi,=20 I think I like the document in its current form. Is there a technical or ligistic reason for=20 splitting it? The current form is compact and keeping everything in one place aids=20 readability.=20 Cheers,=20 Alex.=20 mikko.lonnfors@nokia.com wrote:=20 Hi folks,=20 Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo.=20 So, I would like to know how people feel about this. Please vote for:=20 1)=20 Split the document=20 2)=20 Keep it as it is=20 - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Sun Dec 28 05:24:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29149 for ; Sun, 28 Dec 2003 05:24:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY58-0005CY-CV for simple-archive@odin.ietf.org; Sun, 28 Dec 2003 05:23:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBSANYui019991 for simple-archive@odin.ietf.org; Sun, 28 Dec 2003 05:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY58-0005CM-3z for simple-web-archive@optimus.ietf.org; Sun, 28 Dec 2003 05:23:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29113 for ; Sun, 28 Dec 2003 05:23:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaY54-00023W-00 for simple-web-archive@ietf.org; Sun, 28 Dec 2003 05:23:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaY3B-00021P-00 for simple-web-archive@ietf.org; Sun, 28 Dec 2003 05:21:34 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AaY1n-0001z8-00; Sun, 28 Dec 2003 05:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY1h-00056W-Fk; Sun, 28 Dec 2003 05:20:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AaY1G-00055k-59 for simple@optimus.ietf.org; Sun, 28 Dec 2003 05:19:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29026 for ; Sun, 28 Dec 2003 05:19:30 -0500 (EST) From: mikko.lonnfors@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AaY1C-0001xt-00 for simple@ietf.org; Sun, 28 Dec 2003 05:19:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AaXzX-0001vc-00 for simple@ietf.org; Sun, 28 Dec 2003 05:17:48 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AaXyi-0001qw-00 for simple@ietf.org; Sun, 28 Dec 2003 05:16:56 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBSAGtU20873 for ; Sun, 28 Dec 2003 12:16:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 28 Dec 2003 12:16:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Sun, 28 Dec 2003 12:16:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] splitting of partial notify draft Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF01D1727C@esebe004.ntc.nokia.com> Thread-Topic: [Simple] splitting of partial notify draft Thread-Index: AcPJoDmlkqKWf/l4QPiByQOdt7BbXQDiffKQ To: Cc: X-OriginalArrivalTime: 28 Dec 2003 10:16:54.0840 (UTC) FILETIME=[B7DB5B80:01C3CD2B] Content-Transfer-Encoding: quoted-printable Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 28 Dec 2003 12:16:54 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Main motivation to slip the current document is to improve reusability of the MIME type ('application/pidf-partial+xml'). There are other places than presence event package where this content format may be used. If there wouldn't be any other usages for this then keeping document in its current form would make sense. But if somebody writes a new draft which utilized 'application/pidf-partial+xml' MIME type then it is much more convenient if there is a standalone definition for that. - Mikko =20 -----Original Message----- From: ext Alex Audu [mailto:alex.audu@alcatel.com]=20 Sent: Wednesday, December 24, 2003 12:00 AM To: Lonnfors Mikko (NRC/Helsinki) Cc: simple@ietf.org Subject: Re: [Simple] splitting of partial notify draft Hi,=20 I think I like the document in its current form. Is there a technical or ligistic reason for=20 splitting it? The current form is compact and keeping everything in one place aids=20 readability.=20 Cheers,=20 Alex.=20 mikko.lonnfors@nokia.com wrote:=20 Hi folks,=20 Current partial notify draft (draft-ietf-simple-partial-notify) contains new MIME type definition and specifies how SUBSCRIBE/NOTIFY in presence event package is used with that particular MIME type. One think which could be done is to slip the current draft into two. One part would contain MIME type definition and other would cover how that particular MIME type is used with presence event package. This way it would probably be much easier to reuse partial PIDF MIME type. Similar approach has been taken in winfo.=20 So, I would like to know how people feel about this. Please vote for:=20 1)=20 Split the document=20 2)=20 Keep it as it is=20 - Mikko _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Tue Dec 30 06:28:16 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19851 for ; Tue, 30 Dec 2003 06:28:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbI2q-0002Mc-00 for simple-archive@ietf.org; Tue, 30 Dec 2003 06:28:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbI12-0002K9-00 for simple-archive@ietf.org; Tue, 30 Dec 2003 06:26:25 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AbHzo-0002HT-00; Tue, 30 Dec 2003 06:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHzi-0002rp-Tj; Tue, 30 Dec 2003 06:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHz2-0002qo-2z for simple@optimus.ietf.org; Tue, 30 Dec 2003 06:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19777 for ; Tue, 30 Dec 2003 06:24:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbHyy-0002Ft-00 for simple@ietf.org; Tue, 30 Dec 2003 06:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbHx8-0002Du-00 for simple@ietf.org; Tue, 30 Dec 2003 06:22:23 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AbHvz-0002Bm-00 for simple@ietf.org; Tue, 30 Dec 2003 06:21:11 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBUBLPS18444 for ; Tue, 30 Dec 2003 05:21:32 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Dec 2003 11:20:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'jdrosen@dynamicsoft.com'" Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Dec 2003 11:19:56 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Currently reference [9] of this specification is to: [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol (SIP) caller preferences and callee capabilities," internet draft, Internet Engineering Task Force, Nov. 2002. Work in progress. which by matching the title would equate to: draft-ietf-sip-callerprefs-10 As the usage of this reference in the text is UA to UA, rather than UA to proxy, am I right in thinking that the reference is really to the other half of the caller preferences work, which was split off into: draft-ietf-sip-callee-caps-01 Additionally, if the reference is to callee-caps, then clause 7 of this document contains the text: There is overlap in the callee capabilities mechanism with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It is possible that other header fields and feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag. I am not convinced this is consistent with clause 6.11.2 of the presence-10 specification which states: A PA MAY choose to migrate subscriptions at any time, through configuration, or through dynamic means. The REGISTER request provides one dynamic means for a presence server to discover that the function can migrate to a PUA. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD use the caller preferences specification [9] to indicate that it supports the SUBSCRIBE request method and the presence event package. The combination of these two define a PA. as in some cases it is provisions of RFC 3261 and RFC 3265 through the use of the Allow and Allow events header that will define a PA. Maybe the text should be revised to reflect the precedence of those headers. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Tue Dec 30 06:28:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19878 for ; Tue, 30 Dec 2003 06:28:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbI2v-0002yO-5o for simple-archive@odin.ietf.org; Tue, 30 Dec 2003 06:28:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBUBSLXK011424 for simple-archive@odin.ietf.org; Tue, 30 Dec 2003 06:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbI2v-0002yB-25 for simple-web-archive@optimus.ietf.org; Tue, 30 Dec 2003 06:28:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19862 for ; Tue, 30 Dec 2003 06:28:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbI2r-0002Mh-00 for simple-web-archive@ietf.org; Tue, 30 Dec 2003 06:28:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbI13-0002KG-00 for simple-web-archive@ietf.org; Tue, 30 Dec 2003 06:26:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AbHzo-0002HT-00; Tue, 30 Dec 2003 06:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHzi-0002rp-Tj; Tue, 30 Dec 2003 06:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AbHz2-0002qo-2z for simple@optimus.ietf.org; Tue, 30 Dec 2003 06:24:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19777 for ; Tue, 30 Dec 2003 06:24:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AbHyy-0002Ft-00 for simple@ietf.org; Tue, 30 Dec 2003 06:24:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AbHx8-0002Du-00 for simple@ietf.org; Tue, 30 Dec 2003 06:22:23 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AbHvz-0002Bm-00 for simple@ietf.org; Tue, 30 Dec 2003 06:21:11 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBUBLPS18444 for ; Tue, 30 Dec 2003 05:21:32 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 30 Dec 2003 11:20:03 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'jdrosen@dynamicsoft.com'" Cc: "'simple@ietf.org'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [Simple] Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 30 Dec 2003 11:19:56 -0000 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Currently reference [9] of this specification is to: [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol (SIP) caller preferences and callee capabilities," internet draft, Internet Engineering Task Force, Nov. 2002. Work in progress. which by matching the title would equate to: draft-ietf-sip-callerprefs-10 As the usage of this reference in the text is UA to UA, rather than UA to proxy, am I right in thinking that the reference is really to the other half of the caller preferences work, which was split off into: draft-ietf-sip-callee-caps-01 Additionally, if the reference is to callee-caps, then clause 7 of this document contains the text: There is overlap in the callee capabilities mechanism with the Allow, Accept, Accept-Language, and Allow-Events [9] header fields, which can also be used in target refresh requests. Specifically, the Allow header field and "sip.methods" feature tag indicate the same information. The Accept header field and the "type" feature tag indicate the same information. The Accept-Language header field and the "language" feature tag indicate the same information. The Allow-Events header field and the "sip.events" feature tag indicate the same information. It is possible that other header fields and feature tags defined in the future may also overlap. When there exists a feature tag that describes a capability that can also be represented with a SIP header field, a UA MUST use the header field to describe the capability. A UA receiving a message that contains both the header field and the feature tag MUST use the header field, and not the feature tag. I am not convinced this is consistent with clause 6.11.2 of the presence-10 specification which states: A PA MAY choose to migrate subscriptions at any time, through configuration, or through dynamic means. The REGISTER request provides one dynamic means for a presence server to discover that the function can migrate to a PUA. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD use the caller preferences specification [9] to indicate that it supports the SUBSCRIBE request method and the presence event package. The combination of these two define a PA. as in some cases it is provisions of RFC 3261 and RFC 3265 through the use of the Allow and Allow events header that will define a PA. Maybe the text should be revised to reflect the precedence of those headers. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-admin@ietf.org Wed Dec 31 13:54:50 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20687 for ; Wed, 31 Dec 2003 13:54:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AblUY-0007mg-00 for simple-archive@ietf.org; Wed, 31 Dec 2003 13:54:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AblSf-0007ju-00 for simple-archive@ietf.org; Wed, 31 Dec 2003 13:52:54 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AblR0-0007hY-00; Wed, 31 Dec 2003 13:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblQs-00088a-5d; Wed, 31 Dec 2003 13:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblQj-00087v-Nm for simple@optimus.ietf.org; Wed, 31 Dec 2003 13:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20589 for ; Wed, 31 Dec 2003 13:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AblQh-0007gJ-00 for simple@ietf.org; Wed, 31 Dec 2003 13:50:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AblOq-0007dw-00 for simple@ietf.org; Wed, 31 Dec 2003 13:48:56 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AblOC-0007bb-00 for simple@ietf.org; Wed, 31 Dec 2003 13:48:16 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBVIlpmR007869; Wed, 31 Dec 2003 13:47:51 -0500 (EST) Message-ID: <3FF319D2.8040901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'simple@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Dec 2003 13:47:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit inline. Drage, Keith (Keith) wrote: > Currently reference [9] of this specification is to: > > [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol > (SIP) caller preferences and callee capabilities," internet draft, > Internet Engineering Task Force, Nov. 2002. Work in progress. > > which by matching the title would equate to: > > draft-ietf-sip-callerprefs-10 > > As the usage of this reference in the text is UA to UA, rather than > UA to proxy, am I right in thinking that the reference is really to > the other half of the caller preferences work, which was split off > into: > > draft-ietf-sip-callee-caps-01 Yes, you are correct. Indeed, one of the main motivations for splitting up caller prefs was to allow us to proceed callee caps separately (and presumably faster) than caller prefs, since the SIMPLE dependency was really on the capabilities part. Ironically, caller prefs has passed IESG first (callee caps is right behidn it though) so in the end the split did nothign to accelerate giving an RFC number to draft-ietf-simple-presence. > > Additionally, if the reference is to callee-caps, then clause 7 of > this document contains the text: > > There is overlap in the callee capabilities mechanism with the > Allow, Accept, Accept-Language, and Allow-Events [9] header fields, > which can also be used in target refresh requests. Specifically, > the Allow header field and "sip.methods" feature tag indicate the > same information. The Accept header field and the "type" feature > tag indicate the same information. The Accept-Language header field > and the "language" feature tag indicate the same information. The > Allow-Events header field and the "sip.events" feature tag indicate > the same information. It is possible that other header fields and > feature tags defined in the future may also overlap. When there > exists a feature tag that describes a capability that can also be > represented with a SIP header field, a UA MUST use the header field > to describe the capability. A UA receiving a message that contains > both the header field and the feature tag MUST use the header > field, and not the feature tag. > > I am not convinced this is consistent with clause 6.11.2 of the > presence-10 specification which states: > > A PA MAY choose to migrate subscriptions at any time, through > configuration, or through dynamic means. The REGISTER request > provides one dynamic means for a presence server to discover that > the function can migrate to a PUA. Specifically, if a PUA wishes to > indicate support for the PA function, it SHOULD use the caller > preferences specification [9] to indicate that it supports the > SUBSCRIBE request method and the presence event package. The > combination of these two define a PA. > > as in some cases it is provisions of RFC 3261 and RFC 3265 through > the use of the Allow and Allow events header that will define a PA. > Maybe the text should be revised to reflect the precedence of those > headers. Actually, I dont think there is a conflict, but the reason is subtle. If you look at the first sentence in the text from callee caps above, you will note that it is explicitly talking about *target refresh requests*. The presence spec is talking about registrations. The difference is that registrations can contain information about multiple UAs, and therefore the capability information needs to be contact-specific; thus, it is appropriate to use the callee caps parameters. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From exim@www1.ietf.org Wed Dec 31 13:55:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20734 for ; Wed, 31 Dec 2003 13:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblUc-0008ES-0P for simple-archive@odin.ietf.org; Wed, 31 Dec 2003 13:54:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBVIsrXp031640 for simple-archive@odin.ietf.org; Wed, 31 Dec 2003 13:54:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblUb-0008EF-QV for simple-web-archive@optimus.ietf.org; Wed, 31 Dec 2003 13:54:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20708 for ; Wed, 31 Dec 2003 13:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AblUZ-0007mt-00 for simple-web-archive@ietf.org; Wed, 31 Dec 2003 13:54:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AblSg-0007k5-00 for simple-web-archive@ietf.org; Wed, 31 Dec 2003 13:52:55 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AblR0-0007hY-00; Wed, 31 Dec 2003 13:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblQs-00088a-5d; Wed, 31 Dec 2003 13:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AblQj-00087v-Nm for simple@optimus.ietf.org; Wed, 31 Dec 2003 13:50:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20589 for ; Wed, 31 Dec 2003 13:50:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AblQh-0007gJ-00 for simple@ietf.org; Wed, 31 Dec 2003 13:50:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AblOq-0007dw-00 for simple@ietf.org; Wed, 31 Dec 2003 13:48:56 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AblOC-0007bb-00 for simple@ietf.org; Wed, 31 Dec 2003 13:48:16 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hBVIlpmR007869; Wed, 31 Dec 2003 13:47:51 -0500 (EST) Message-ID: <3FF319D2.8040901@dynamicsoft.com> From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" CC: "'simple@ietf.org'" References: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB00439EF86@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Simple] Re: Question on draft-ietf-simple-presence-10 Sender: simple-admin@ietf.org Errors-To: simple-admin@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 31 Dec 2003 13:47:46 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Drage, Keith (Keith) wrote: > Currently reference [9] of this specification is to: > > [9] H. Schulzrinne and J. Rosenberg, "Session initiation protocol > (SIP) caller preferences and callee capabilities," internet draft, > Internet Engineering Task Force, Nov. 2002. Work in progress. > > which by matching the title would equate to: > > draft-ietf-sip-callerprefs-10 > > As the usage of this reference in the text is UA to UA, rather than > UA to proxy, am I right in thinking that the reference is really to > the other half of the caller preferences work, which was split off > into: > > draft-ietf-sip-callee-caps-01 Yes, you are correct. Indeed, one of the main motivations for splitting up caller prefs was to allow us to proceed callee caps separately (and presumably faster) than caller prefs, since the SIMPLE dependency was really on the capabilities part. Ironically, caller prefs has passed IESG first (callee caps is right behidn it though) so in the end the split did nothign to accelerate giving an RFC number to draft-ietf-simple-presence. > > Additionally, if the reference is to callee-caps, then clause 7 of > this document contains the text: > > There is overlap in the callee capabilities mechanism with the > Allow, Accept, Accept-Language, and Allow-Events [9] header fields, > which can also be used in target refresh requests. Specifically, > the Allow header field and "sip.methods" feature tag indicate the > same information. The Accept header field and the "type" feature > tag indicate the same information. The Accept-Language header field > and the "language" feature tag indicate the same information. The > Allow-Events header field and the "sip.events" feature tag indicate > the same information. It is possible that other header fields and > feature tags defined in the future may also overlap. When there > exists a feature tag that describes a capability that can also be > represented with a SIP header field, a UA MUST use the header field > to describe the capability. A UA receiving a message that contains > both the header field and the feature tag MUST use the header > field, and not the feature tag. > > I am not convinced this is consistent with clause 6.11.2 of the > presence-10 specification which states: > > A PA MAY choose to migrate subscriptions at any time, through > configuration, or through dynamic means. The REGISTER request > provides one dynamic means for a presence server to discover that > the function can migrate to a PUA. Specifically, if a PUA wishes to > indicate support for the PA function, it SHOULD use the caller > preferences specification [9] to indicate that it supports the > SUBSCRIBE request method and the presence event package. The > combination of these two define a PA. > > as in some cases it is provisions of RFC 3261 and RFC 3265 through > the use of the Allow and Allow events header that will define a PA. > Maybe the text should be revised to reflect the precedence of those > headers. Actually, I dont think there is a conflict, but the reason is subtle. If you look at the first sentence in the text from callee caps above, you will note that it is explicitly talking about *target refresh requests*. The presence spec is talking about registrations. The difference is that registrations can contain information about multiple UAs, and therefore the capability information needs to be contact-specific; thus, it is appropriate to use the callee caps parameters. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple