From Myles@dbzmail.com Fri Apr 1 00:09:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21256; Fri, 1 Apr 2005 00:09:48 -0500 (EST) Message-Id: <200504010509.AAA21256@ietf.org> Received: from [221.161.164.252] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHEX0-00014E-GO; Fri, 01 Apr 2005 00:17:21 -0500 Received: from [168.246.34.160] by implement%DIGITS.optimal.221.161.164.252 via HTTP; Thu, 31 Mar 2005 21:12:36 -0800 Reply-To: "awemail.com" From: "awemail.com" To: Subject: Astounding Loans with options. Date: Thu, 31 Mar 2005 21:12:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9133950566xrpu4567" X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----9133950566xrpu4567 Content-Type: text/plain; charset="iso-%DIGITS%LCVALUES%DIGITS%DIGITS%LCVALUES" Content-Transfer-Encoding: quoted-printable Attention Home owners! Learn how to save big by re-financ-ing Current Rate is at all times low of 3.6% ACT TODAY: http://www.today-mrg-now.net/st.asp No other way to so quickly and easily lower your monthly bill payments while putting cash now in your pocket! ----9133950566xrpu4567-- From brandy@abaforum.es Fri Apr 1 02:28:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21630 for ; Fri, 1 Apr 2005 02:28:20 -0500 (EST) Received: from atm91-1-82-227-0-122.fbx.proxad.net ([82.227.0.122]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHGh5-0005kH-ED for simple-archive@ietf.org; Fri, 01 Apr 2005 02:35:53 -0500 Message-ID: <0d8201c5368a$cb39a22c$992b4067@abaforum.es> From: "Paul A. Davis" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?VmlhZ3JhIC0gNzUlIE9GRg==?= Date: Fri, 01 Apr 2005 07:12:30 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_40B0BCDB.570AD1DB" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 9.4 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_40B0BCDB.570AD1DB Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E058BA99.B6D5653B" ------=_NextPart_001_0001_E058BA99.B6D5653B Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Full & stable erections Long-lasting effects No prescription needed Give it a try! Cialis - http://www.lovemedication.biz/sv/ Viagra - http://www.lovemedication.biz/vt/ Select the manufacturer you can trust! _________________________________________________________________________ To be taken off future campaigns, go here: http://www.lovemedication.biz/uns.htm _________________________________________________________________________ ------=_NextPart_001_0001_E058BA99.B6D5653B Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit

Hard & full erections
Long lasting effects
No prescription needed

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.lovemedication.biz/sv/
VIAGRA - http://www.lovemedication.biz/vt/

Directly from the manufacturer!


_________________________________________________________________________
To change your mail details, go here: http://www.lovemedication.biz/uns.htm
_________________________________________________________________________

------=_NextPart_001_0001_E058BA99.B6D5653B-- ------=_NextPart_000_0000_40B0BCDB.570AD1DB-- From simple-bounces@ietf.org Fri Apr 1 04:52:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07130; Fri, 1 Apr 2005 04:52:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIwB-0002YI-Kc; Fri, 01 Apr 2005 04:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIoP-0001Dp-7t; Fri, 01 Apr 2005 04:51:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHIld-00012F-BB for simple@megatron.ietf.org; Fri, 01 Apr 2005 04:48:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06929 for ; Fri, 1 Apr 2005 04:48:38 -0500 (EST) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHIst-0002Qt-Na for simple@ietf.org; Fri, 01 Apr 2005 04:56:13 -0500 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j319mEdr004737 for ; Fri, 1 Apr 2005 11:48:14 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j319m8Dm001713 for ; Fri, 1 Apr 2005 11:48:08 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Apr 2005 11:48:09 +0200 Message-ID: From: Boehmer Bernhard Com Berlin To: "'simple@ietf.org'" Date: Fri, 1 Apr 2005 11:48:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Subject: [Simple] reachibility information for services in current presence data mo del X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Hi, the current presence data model discusses nicely reachability information. Maximum openess concerning the definition of a service is maintained. However, in the actual definition=20 of the - being the legacy of pidf - reachability information is restricted to one entry, the element. Thus, within one element the possibility that a service may be reachable via different, e.g., addresses cannot be reflected. The only way I see currently is to send two elements with basically the same information but the /reachability information. >From my perspective this introduces quite some redundancy in the = presence doc (a point which is especially relevant for mobile networks) and=20 is furthermore asymmetric to possibility to introduce several device = ids into one element (the latter, however, not being made explicit by the XML schema). So, my question is: Have you once considered to add more than one piece of reachability information and you have rejected this possibility or do you share the view that this means should be introduced? Regards Bernhard ___________________________ Dr. Bernhard B=F6hmer Systems Engineering Siemens AG Communications, Mobile Networks AS BD C Siemensdamm 50, Berlin Fon: +49-30-386-22756 Mobile: +49-178-7700119 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 1 06:03:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11983; Fri, 1 Apr 2005 06:03:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHK32-0004zL-Fa; Fri, 01 Apr 2005 06:10:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHJug-0001bu-LY; Fri, 01 Apr 2005 06:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHJuS-0001a1-2G for simple@megatron.ietf.org; Fri, 01 Apr 2005 06:01:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11904 for ; Fri, 1 Apr 2005 06:01:48 -0500 (EST) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHK1j-0004u4-BQ for simple@ietf.org; Fri, 01 Apr 2005 06:09:24 -0500 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j31B1Vdr005200 for ; Fri, 1 Apr 2005 13:01:31 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j31B1PDn003517 for ; Fri, 1 Apr 2005 13:01:25 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Fri, 1 Apr 2005 13:01:25 +0200 Message-ID: From: Boehmer Bernhard Com Berlin To: "'simple@ietf.org'" Date: Fri, 1 Apr 2005 13:01:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Subject: [Simple] Some XML Schema issues in RPID-05 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Hi, I found some issues/bugs in the XML schemas defined with RPID-05 I would like to share/discuss with you. 1) schema rpid-status: the tokenlist type is no more defined, seems have to been lost since RPID-03. Since it's also used in rpid-person I solved it ad-hoc including a schema defining the type. Possibly there's a better way... 2) schema rpid-person:=20 - same with tokenlist as above. - substitutionGroup "activity-value" has been used but no head for this substitutionGroup has been defined. I added ad-hoc the = head "" with type "any" to resolve the issue. Possibly there's a better way... - element didn't work. Don't know yet how to deal with = it. - following issue arose for but this may apply to other = elements, too: if shall appear under person:status as defined in = the presence data model, the definition of sphere must be a member of the substitutionGroup "personStatus". This means that sphere must be an extension of the type "personStatusAbstractType". One = possible way to so is: 3) schema rpid-device: Eventually I missed something but why is the element needed if the presence data model defines = already ? Is the more general type "string" needed here? The definition via substitutionGroup given in rpid-device doesn't work and seems to be in contrast to the = definition in the presence data model where deviceID is not under = "deviceCharacteristic". =09 Regards Bernhard P.S: I haven't used/checked all elements defined in RPID.=20 =20 ___________________________ Dr. Bernhard B=F6hmer Systems Engineering Siemens AG Communications, Mobile Networks AS BD C Siemensdamm 50, Berlin Fon: +49-30-386-22756 Mobile: +49-178-7700119 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 1 06:54:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16101; Fri, 1 Apr 2005 06:54:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKqn-0006oc-11; Fri, 01 Apr 2005 07:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKh8-0007uY-Ax; Fri, 01 Apr 2005 06:52:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHKh7-0007uT-JG for simple@megatron.ietf.org; Fri, 01 Apr 2005 06:52:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16028 for ; Fri, 1 Apr 2005 06:52:06 -0500 (EST) From: Antti.K.Laurila@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHKoQ-0006ig-8a for simple@ietf.org; Fri, 01 Apr 2005 06:59:43 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31Bq6Z08011 for ; Fri, 1 Apr 2005 14:52:06 +0300 (EET DST) X-Scanned: Fri, 1 Apr 2005 15:08:34 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j31C8YXb014082 for ; Fri, 1 Apr 2005 15:08:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 007lQPj1; Fri, 01 Apr 2005 15:08:30 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j31BpCU17041 for ; Fri, 1 Apr 2005 14:51:12 +0300 (EET DST) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Apr 2005 14:50:49 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 1 Apr 2005 14:50:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Apr 2005 14:50:49 +0300 Message-ID: <3D581AAC3824744CBA321327B00529B9116280@trebe101.NOE.Nokia.com> Thread-Topic: =?utf-8?B?Rlc6IExpc8OkaW5mb2EgSWRlbnRpdHkgb25nZWxtYQ==?= Thread-Index: AcUruTtdsEndmYiNSUSJqSQiYBcSTgK2AENQ To: X-OriginalArrivalTime: 01 Apr 2005 11:50:49.0660 (UTC) FILETIME=[0C7DA7C0:01C536B1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Simple] Implementation problem with XCAP / Common-Policy X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507287486==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 --===============1507287486== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkR1cmluZyBpbXBsZW1lbnRhdGlvbiB3ZSBoYXZlIGZvdW5kIGZvbGxvd2luZyBwcm9i bGVtIHdpdGggDQpYQ0FQIC8gQ29tbW9uLVBvbGljeS4gTGV0J3MgYXNzdW1lIHRoYXQgd2UgaGF2 ZSBmb2xsb3dpbmcgbGlzdDoNCg0KPGlkZW50aXR5Pg0KIDxpZD51c2VyMTwvaWQ+DQogPGlkPnVz ZXIyPC9pZD4NCiA8aWQ+dXNlcjM8L2lkPg0KPC9pZGVudGl0eT4NCiANCiMgSWYgd2Ugd2FudCB0 byBhZGQgb25lIG5ldyBtZW1iZXIgdG8gdGhhdCBsaXN0Lg0KDQpQVVQgLi4uL2lkZW50aXR5DQo8 aWQ+dXNlcjQ8L2lkPg0KDQojIERvbid0IHdvcmsgYmVjYXVzZSB1c2VyNCB3aWxsIHJlcGxhY2Ug d2hvbGUgbGlzdC4gDQojIFdob2xlIGxpc3QgbmVlZHMgdG8gYmUgd3JpdHRlbiBhZ2FpbiB0b2dl dGhlciB3aXRoIA0KIyBhZGRlZCB1c2VyLCB3aGljaCBpcyBub3QgZWZmaWNpZW50Lg0KDQpQVVQg Li4uL2lkZW50aXR5L2lkDQo8aWQ+dXNlcjQ8L2lkPg0KDQojIE1ldGhvZCBpcyBub3QgYWxsb3dl ZCBpbiBYQ0FQIGFzIHdlIGNhbm5vdCByZWZlciB0byBqdXN0IA0KIyBvbmUgc3BlY2lmaWMgZWxl bWVudCBpbiB0aGUgaGVhZGVyIA0KDQpJZi1Ob25lLU1hdGNoOiAqDQpQVVQgLi4uL2lkZW50aXR5 L2lkWzRdDQo8aWQ+dXNlcjQ8L2lkPg0KDQojIEFzIHRoZXJlIGFyZSAzIGlkJ3MgYWxyZWFkeSBp biB0aGUgbGlzdCwgeW91DQojIGNhbiBjdXJyZW50bHkgYWRkIHRoaXMgbmV3ICg0dGgpIGVudHJ5 IGFzIGEgcG9zaXRpb25hbCANCiMgY29uc3RyYWludA0KDQpCZWxvdyBhcmUgZGVzY3JpYmVkIHR3 byBwb3NzaWJsZSBwcm9wb3NhbHMgdG8gZml4IHRoaXMgcHJvYmxlbToNCg0KMSkgQ2hhbmdlIHRv IFhDQVA6IA0KDQpJZi1Ob25lLU1hdGNoOiAqDQpQVVQgLi4uL2lkZW50aXR5L2lkWy49InVzZXI0 Il0NCjxpZD51c2VyNDwvaWQ+DQogDQojIFJlZmVyIHRvIHZhbHVlIG9mIHRoZSBlbGVtZW50LiBD dXJyZW50bHkgc3VwcG9ydGVkIGJ5IFhQYXRoLCANCiMgYnV0IG5vdCBieSBYQ0FQLiANCg0KMikg Q2hhbmdlIHRvIENvbW1vbi1Qb2xpY3k6DQogDQpJZi1Ob25lLU1hdGNoOiAqDQpQVVQgLi4uL2lk ZW50aXR5L2VudHJ5W0BpZD0idXNlcjQiXQ0KPGVudHJ5IGlkPSJ1c2VyNCIvPg0KDQojIFdpdGgg dGhpcyB3YXkgb25lIGlkIGNhbiBiZSBhZGRlZCB0byB0aGUgbGlzdCBpZiBhbHNvIGZvbGxvd2lu ZyANCiMgY2hhbmdlIGlzIGRvbmUgdG8gdGhlIGRlZmluaXRpb24gb2YgaWRlbnRpdHkgLWVsZW1l bnQNCg0KIyBDdXJyZW50IGRlZmluaXRpb24NCjxpZGVudGl5Pg0KIDxpZD51c2VyMTwvaWQ+DQog PGlkPnVzZXIyPC9pZD4NCiA8aWQ+dXNlcjM8L2lkPg0KPC9pZGVudGl0eT4NCiANCiMgTmV3ICJ3 b3JraW5nIiBkZWZpbml0aW9uDQo8aWRlbnRpdHk+DQogPGVudHJ5IGlkPSJ1c2VyMSIvPg0KIDxl bnRyeSBpZD0idXNlcjIiLz4NCiA8ZW50cnkgaWQ9InVzZXIzIi8+IA0KPC9pZGVudGl0eT4NCg0K DQpBbnkgY29tbWVudHM/DQoNCkJSLCBBbnR0aQ0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkFudHRpIExhdXJpbGEgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQpTeXN0ZW0gU3BlY2lhbGlzdA0KTm9raWEgTmV0d29y a3MNClRlbC4gKzM1ODQwIDU4NCA5MjgwDQpFbWFpbDogYW50dGkuay5sYXVyaWxhQG5va2lhLmNv bQ0KaHR0cDovL3d3dy5ub2tpYS5jb20vb3Blbm5lc3MNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --===============1507287486== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1507287486==-- From simple-bounces@ietf.org Fri Apr 1 08:36:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24979; Fri, 1 Apr 2005 08:36:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMRC-0002LI-Ic; Fri, 01 Apr 2005 08:43:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMHL-0003cm-RO; Fri, 01 Apr 2005 08:33:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMHJ-0003cK-U1 for simple@megatron.ietf.org; Fri, 01 Apr 2005 08:33:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24701 for ; Fri, 1 Apr 2005 08:33:34 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMOd-0002Dm-34 for simple@ietf.org; Fri, 01 Apr 2005 08:41:12 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j31DXLh3000670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 08:33:32 -0500 (EST) Message-ID: <424D4D9C.7040007@cs.columbia.edu> Date: Fri, 01 Apr 2005 08:33:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Boehmer Bernhard Com Berlin Subject: Re: [Simple] Some XML Schema issues in RPID-05 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by opus.cs.columbia.edu id j31DXLh3000670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Thank you for the feedback. Please be advised that a design team is in=20 the process of completely re-doing the schemas, in particular to align=20 the various SIMPLE schemas with the data model and each other, both in=20 style and content. Thus, I would suggest you hold off on detailed=20 comments until that revision appears, hopefully within the next few weeks. Boehmer Bernhard Com Berlin wrote: > Hi, > I found some issues/bugs in the XML schemas defined > with RPID-05 I would like to share/discuss with you. >=20 > 1) schema rpid-status: the tokenlist type is no more defined, > seems have to been lost since RPID-03. Since it's also used > in rpid-person I solved it ad-hoc including a schema defining > the type. Possibly there's a better way... > 2) schema rpid-person:=20 > - same with tokenlist as above. > - substitutionGroup "activity-value" has been used but no head > for this substitutionGroup has been defined. I added ad-hoc the hea= d > "" with type "any" to resolve > the issue. Possibly there's a better way... > - element didn't work. Don't know yet how to deal with = it. > - following issue arose for but this may apply to other ele= ments, > too: if shall appear under person:status as defined in th= e > presence data model, the definition of sphere must be a member of > the substitutionGroup "personStatus". This means that sphere must > be an extension of the type "personStatusAbstractType". One possib= le > way to so is: > > > > > > > > > >=20 > 3) schema rpid-device: Eventually I missed something but why is the > element needed if the presence data model defines alread= y > ? Is the more general type "string" needed here? > The definition via substitutionGroup > given in rpid-device doesn't work and seems to be in contrast to the= definition > in the presence data model where deviceID is not under "deviceCharac= teristic". > =09 > Regards Bernhard >=20 > P.S: I haven't used/checked all elements defined in RPID.=20 > =20 >=20 > ___________________________ > Dr. Bernhard B=F6hmer > Systems Engineering > Siemens AG Communications, > Mobile Networks AS BD C > Siemensdamm 50, Berlin > Fon: +49-30-386-22756 > Mobile: +49-178-7700119 >=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-bounces@ietf.org Fri Apr 1 08:39:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25339; Fri, 1 Apr 2005 08:39:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMUR-0002UT-JQ; Fri, 01 Apr 2005 08:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMJP-0003pp-2I; Fri, 01 Apr 2005 08:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHMJN-0003pJ-Uo for simple@megatron.ietf.org; Fri, 01 Apr 2005 08:35:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24906 for ; Fri, 1 Apr 2005 08:35:42 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHMQh-0002KW-5j for simple@ietf.org; Fri, 01 Apr 2005 08:43:21 -0500 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j31DZdh3000756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 08:35:40 -0500 (EST) Message-ID: <424D4E26.8080904@cs.columbia.edu> Date: Fri, 01 Apr 2005 08:35:34 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Boehmer Bernhard Com Berlin Subject: Re: [Simple] reachibility information for services in current presence data mo del References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by opus.cs.columbia.edu id j31DZdh3000756 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable I doubt that anybody has the desire at this point to change PIDF in a=20 non-backward-compatible way. Can you spell out what kind of information=20 you see as being duplicated unnecessarily across several =20 elements? In the cases I can picture, things like prescaps would likely=20 differ for each contact. Boehmer Bernhard Com Berlin wrote: > Hi, > the current presence data model discusses nicely reachability > information. Maximum openess concerning the definition of > a service is maintained. However, in the actual definition=20 > of the - being the legacy of pidf - reachability information > is restricted to one entry, the element. Thus, within > one element the possibility that a service may be reachable > via different, e.g., addresses cannot be reflected. The only way I > see currently is to send two elements with basically the same > information but the /reachability information. >=20 >>From my perspective this introduces quite some redundancy in the presen= ce > doc (a point which is especially relevant for mobile networks) and=20 > is furthermore asymmetric to possibility to introduce several device id= s > into one element (the latter, however, not being made explicit > by the XML schema). >=20 > So, my question is: Have you once considered to add more than one piece > of reachability information and you have rejected this possibility or > do you share the view that this means should be introduced? > Regards Bernhard >=20 > ___________________________ > Dr. Bernhard B=F6hmer > Systems Engineering > Siemens AG Communications, > Mobile Networks AS BD C > Siemensdamm 50, Berlin > Fon: +49-30-386-22756 > Mobile: +49-178-7700119 >=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-bounces@ietf.org Fri Apr 1 19:32:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06813; Fri, 1 Apr 2005 19:32:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWgY-0006Ct-60; Fri, 01 Apr 2005 19:40:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWYx-0008BY-MX; Fri, 01 Apr 2005 19:32:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHWYv-0008BO-Oc for simple@megatron.ietf.org; Fri, 01 Apr 2005 19:32:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06781 for ; Fri, 1 Apr 2005 19:32:26 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHWgL-0006CA-PP for simple@ietf.org; Fri, 01 Apr 2005 19:40:10 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 1 Apr 2005 16:32:25 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Fri, 1 Apr 2005 16:29:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C5371A.F72E09F8" Date: Fri, 1 Apr 2005 16:29:00 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: New WG charter topic: draft-aoki-feel-00.txt ? Thread-Index: AcU3GX5piLyzfIrrQIGQ6mXeZEdc6gAATppg From: "Orit Levin" To: "Simple WG" X-OriginalArrivalTime: 02 Apr 2005 00:29:49.0361 (UTC) FILETIME=[14449210:01C5371B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a50b6fe619b8c4df89c7095cedd22e37 Subject: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08582f3b796126054df71137d5cb69f8 This is a multi-part message in MIME format. ------_=_NextPart_001_01C5371A.F72E09F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Guys, We know that SIMPLE is overloaded with work, but lately we came across a new topic that seems to be crucial for standardization - especially for the benefit of the growing IM communications. We wrote a draft that highlights the problem and introduces some solutions. These are initial thoughts only. You will see that many areas (such as the security considerations) need to be thought through in more details. Before we invest more efforts and submit the draft to the IETF, we wanted to share our thoughts and get your feedback regarding the validity of this direction in general. Thanks a lot, The authors. ------_=_NextPart_001_01C5371A.F72E09F8 Content-Type: text/plain; name="draft-aoki-feel-00.txt" Content-Description: draft-aoki-feel-00.txt Content-Disposition: attachment; filename="draft-aoki-feel-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KDQpOZXR3b3JrIFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEUuIEFva2kNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBBbWVyaWNhIE9ubGluZSwgSW5jLg0KRXhwaXJlczogT2N0b2Jl ciAzLCAyMDA1ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE8uIExldmlu DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFQuIFJhbmcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBNLiBUcm9tbXNkb3JmZg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTWljcm9zb2Z0IENvcnBvcmF0aW9uDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEFwcmlsIDIwMDUNCg0KDQogICAgICAgICBGRUVMIC0gVGhlIEZlZGVyYXRlZCBFbW90aWNvbiBh bmQgRXhwcmVzc2lvbiBMYW5ndWFnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQt YW9raS1mZWVsLTAwDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBkb2N1bWVudCBp cyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgc3ViamVjdCB0byBhbGwgcHJvdmlzaW9ucw0KICAg b2YgU2VjdGlvbiAzIG9mIFJGQyAzNjY3LiAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURy YWZ0LCBlYWNoDQogICBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueSBhcHBsaWNhYmxlIHBhdGVu dCBvciBvdGhlciBJUFIgY2xhaW1zIG9mDQogICB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUgaGF2 ZSBiZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mDQogICB3aGljaCBoZSBvciBz aGUgYmVjb21lIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGgNCiAg IFJGQyAzNjY4Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9m IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVh cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMNCiAgIEludGVybmV0LURyYWZ0 cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVy aWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0K ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0 DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoNCiAgIFRo ZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNz ZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRoaXMgSW50 ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAzLCAyMDA1Lg0KDQpDb3B5cmlnaHQg Tm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDUpLg0K DQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNldCBvZiBzdGFuZGFy ZCBjb252ZW50aW9ucyBmb3IgZW1vdGljb25zLA0KICAgYWxzbyBrbm93biBhcyAic21pbGV5cyIs IHRoYXQgYWxsb3cgbWVzc2FnaW5nIHN5c3RlbXMgZnJvbSBkaWZmZXJlbnQNCiAgIHZlbmRvcnMg dG8gY29udmV5IHRleHQtYmFzZWQgZXhwcmVzc2lvbnMgaW50ZXJvcGVyYWJseS4gIFRoZQ0KDQoN Cg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA1ICAgICAg ICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg RkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICBlbW90aWNvbnMg ZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGNhbiBiZSBjb252ZXllZCBvdmVyIGFueQ0KICAgdGV4 dC1iYXNlZCBtZXNzYWdpbmcgcHJvdG9jb2wsIGluY2x1ZGluZyBlbWFpbCwgaW5zdGFudCBtZXNz YWdpbmcsDQogICBudGFsaywgYW5kIG90aGVycy4NCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAg MS4gIENvbnZlbnRpb25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAzDQogICAyLiAgQmFja2dyb3VuZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMuICBNb3RpdmF0aW9uIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgNC4gIFNw ZWNpZmljYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA1DQogICAgIDQuMSAgIEJhc2ljIEVtb3RpY29ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAgNC4yICAgRXh0ZW5kZWQgRW1vdGljb25zIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgICA0LjMgICBJbmFu aW1hdGUgT2JqZWN0cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2 DQogICAgIDQuNCAgIFNwZWNpYWxpemVkIEVtb3RpY29ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgNC41ICAgVHJhbnNsYXRpb25zIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAgIDQuNS4xICAgTG9jYWxl IFNwZWNpZmljIFRyYW5zbGF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAg IDQuNiAgIFN1bW1hcnkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDcNCiAgIDUuICBBdWdtZW50ZWQgQk5GIGZvciBGRUVMIGNvbXBsaWFudCBlbW90 aWNvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRp b25zICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA3LiAgSUFO QSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDkNCiAgIDguICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgICA4LjEgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQogICAgIDguMiAgIEluZm9y bWF0aW9uYWwgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTAN CiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxMA0KICAgICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJp Z2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIDEyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4 cGlyZXMgT2N0b2JlciAzLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFw cmlsIDIwMDUNCg0KDQoxLiAgQ29udmVudGlvbnMNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VM RCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzDQogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IFJGQy0yMTE5IFsxXS4NCg0KMi4gIEJhY2tncm91bmQNCg0KICAgRWFjaCBkYXksIG1pbGxpb25z IG9mIHBlb3BsZSBhcm91bmQgdGhlIHdvcmxkIGV4Y2hhbmdlIGxpdGVyYWxseQ0KICAgYmlsbGlv bnMgb2YgZW1haWxzLCBpbnN0YW50IG1lc3NhZ2VzLCBhbmQgb3RoZXIgZm9ybXMgb2YgdGV4dC1i YXNlZCwNCiAgIGNvbXB1dGVyIG1lZGlhdGVkIGNvbW11bmljYXRpb24gdmlhIHRoZSBJbnRlcm5l dC4gIEFsdGhvdWdoDQogICBvcmlnaW5hbGx5IGRlc2lnbmVkIHRvIGZhY2lsaXRhdGUgYWNhZGVt aWMgcmVzZWFyY2gsIHRvZGF5J3MgSW50ZXJuZXQNCiAgIG1lc3NhZ2luZyBzeXN0ZW1zIGFyZSB1 c2VkIHdpdGhpbiBlbnRlcnByaXNlcywgZmFtaWxpZXMsIGFuZCBzb2NpYWwNCiAgIGdyb3VwcyBh cyBhIGZhc3QsIGVmZmljaWVudCBmb3JtIG9mIGNvbW11bmljYXRpb24uDQoNCiAgIEFzIHRoZSB1 c2VyIGJhc2UgZm9yIG1lc3NhZ2luZyBzeXN0ZW1zIGdyZXcsIHNvLCB0b28sIGRpZA0KICAgbWlz dW5kZXJzdGFuZGluZ3MgYmV0d2VlbiBhbmQgYW1vbmcgdXNlciBncm91cHMuICBEZXByaXZlZCBv ZiB0aGUNCiAgIGN1ZXMgcHJvdmlkZWQgdGhyb3VnaCB2b2NhbCBpbmZsZWN0aW9uIG9yIHBlcnNv bmFsIGludGVyYWN0aW9uLA0KICAgbWVzc2FnaW5nIHVzZXJzIGZvdW5kIGl0IGRpZmZpY3VsdCB0 byBkaXNjZXJuIHRoZSB0b25lIG9yIGludGVudCBvZg0KICAgc3BlY2lmaWMgbWVzc2FnZXMgb3Ig bWVzc2FnZSBleGNoYW5nZXMuICBUaGUgY29tcGxleCBlbW90aW9ucyB0aGF0DQogICB1bmRlcmxp ZSBzYXJjYXNtLCBqb2tpbmcsIGFuZ2VyLCBhbmQgYWZmZWN0aW9uLCBqdXN0IHRvIG5hbWUgYSBm ZXcsDQogICB3ZXJlIG5ldXRyYWxpemVkIGluIHRoZXNlIHRleHQgYmFzZWQgbWVzc2FnaW5nIGZv cm1hdHMgYW5kIG9mdGVuDQogICByZXN1bHRlZCBpbiBtaXNpbnRlcnByZXRhdGlvbiBvciBlbWJh cnJhc3NtZW50Lg0KDQogICBPdmVyIHRpbWUsIGVtb3RpY29ucyB3ZXJlIGRldmlzZWQgdG8gZmls bCB0aGlzIGdhcCBhbmQgdG8gZW5hYmxlDQogICBJbnRlcm5ldCB1c2VycyB0byBleHByZXNzIGVt b3Rpb25zIHRocm91Z2ggdGV4dC1iYXNlZCBtZXNzYWdpbmcNCiAgIHN5c3RlbXMgWzNdLiAgRW1v dGljb25zIGFyZSBhIHNlcmllcyBvZiB0ZXh0LWJhc2VkIGNoYXJhY3RlcnMgd2hpY2gsDQogICB3 aGVuIHZpZXdlZCBvbiB0aGVpciBzaWRlLCBmb3JtIGEgcGljdHVyZSB0aGF0IGlzIHVuZGVyc3Rv b2QgdG8NCiAgIGNvbnZleSBhIHBhcnRpY3VsYXIgZW1vdGlvbi4NCg0KICAgVGhlIG1vc3QgY29t bW9uIG9mIHRoZXNlIGVtb3RpY29ucyBpcyB0aGUgInNtaWxleSwiIGNvbnNpc3Rpbmcgb2YgdGhl DQogICBBU0NJSSBjaGFyYWN0ZXJzIDB4M0EsIDB4MkQsIGFuZCAweDI5LiAgV2hlbiBkaXNwbGF5 ZWQsIHRoZXNlDQogICBjaGFyYWN0ZXJzIHRvZ2V0aGVyIGFwcGVhciBsaWtlIHRoaXM6DQoNCiAg ICAgICAgICAgICAgICAgICA6LSkNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG aWd1cmUgMQ0KDQogICB3aGljaCBpcyBvZnRlbiB1c2VkIHRvIGluZGljYXRlIHRoYXQgYSBwcmVj ZWRpbmcgY29tbWVudCBpcyBodW1vcm91cw0KICAgaW4gbmF0dXJlLg0KDQogICBTb29uLCB1c2Vy cyBkZXZpc2VkIGV2ZXIgbW9yZSBlbGFib3JhdGUgZm9ybXMgb2YgZW1vdGljb25zIHRvDQogICBy ZXByZXNlbnQgYSB3aWRlciB2YXJpZXR5IG9mIGVtb3Rpb25zLiAgVGhlIGZvbGxvd2luZyBleGFt cGxlcw0KICAgcmVwcmVzZW50IGNyeWluZywgd2lua2luZywgYW5kIHN0aWNraW5nIG91dCBvbmUn cyB0b25ndWUsIGZvcg0KICAgZXhhbXBsZS4NCg0KICAgICAgICAgICAgICAgICAgIDonKCAgIDst KSAgOi1QDQoNCg0KDQoNCkFva2ksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIg MywgMjAwNSAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgIEZFRUwgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMg0KDQogICBUaGUgZ3Jvd2lu ZyBhcnJheSBvZiBlbW90aWNvbnMgc29tZXRpbWVzIG1hZGUgaXQgZGlmZmljdWx0IGZvciB1c2Vy cw0KICAgdG8gdW5kZXJzdGFuZCB3aGF0IGVtb3Rpb24gYSBnaXZlbiBzZXJpZXMgb2YgY2hhcmFj dGVycyB3YXMgc3VwcG9zZWQNCiAgIHRvIHJlcHJlc2VudCwgc28gc29tZSBtZXNzYWdpbmcgdXNl ciBhZ2VudHMsIHdoZW4gcmVuZGVyaW5nIHRleHQNCiAgIGNvbnRhaW5pbmcgYW4gZW1vdGljb24g YmVnYW4gdG8gcmVwbGFjZSB0aGUgY2hhcmFjdGVycyByZXByZXNlbnRpbmcNCiAgIHRoZSBlbW90 aWNvbiB3aXRoIGEgZ3JhcGhpY2FsbHkgcmVuZGVyZWQgc3RhdGljIGljb24gdGhhdCB3b3VsZCBi ZQ0KICAgZGlzcGxheWVkIGluIHRoZWlyIHBsYWNlLiAgT24gdGhlIGNvbXBvc2l0aW9uIHNpZGUs IHRoZXNlIHVzZXIgYWdlbnRzDQogICBvZnRlbiBwcm92aWRlZCBhIG1lbnUgb3Igb3RoZXIgdXNl ciBpbnRlcmZhY2UgZWxlbWVudCB0aGF0IGFsbG93ZWQNCiAgIHVzZXJzIHRvIHNlbGVjdCBhbiBl bW90aW9uIGdyYXBoaWNhbGx5IGZyb20gYSBsaXN0LCBzdWJzdGl0dXRpbmcgdGhlDQogICBhcHBy b3ByaWF0ZSB0ZXh0dWFsIHJlcHJlc2VudGF0aW9ucyBmb3Igb24tdGhlLXdpcmUgcmVuZGVyaW5n IG9mIHRoZQ0KICAgZXhwcmVzc2lvbi4gIE1hbnkgb2YgdG9kYXkncyBjb21tZXJjaWFsIGluc3Rh bnQgbWVzc2FnaW5nIGNsaWVudHMsDQogICBmb3IgZXhhbXBsZSwgaW5jbHVkZSBtZW51cyBvZiBh IGRvemVuIG9yIG1vcmUgZW1vdGljb25zIHRoYXQgdXNlcnMNCiAgIGNhbiBpbnNlcnQgaW50byB0 aGVpciBjb252ZXJzYXRpb25zLg0KDQozLiAgTW90aXZhdGlvbg0KDQogICBIb3dldmVyLCB0aGVz ZSB1c2VyIGFnZW50IG1hbmlwdWxhdGlvbnMsIGFsdGhvdWdoIGNvbnZlbmllbnQgZm9yDQogICB1 c2VycywgY29tZSBhdCB0aGUgcHJpY2Ugb2YgaW50ZXJvcGVyYWJpbGl0eS4gIEFzIHZlbmRvcnMg Y3JlYXRlDQogICBzeXN0ZW1zIHRoYXQgaW50ZXJvcGVyYXRlIHdpdGggb25lIGFub3RoZXIsIG9y IHRoYXQgYnJpZGdlIHZhcmlvdXMNCiAgIGRpZmZlcmVudCBmb3JtcyBvZiB0ZXh0IGJhc2VkIGNv bW11bmljYXRpb25zIChlLmcuLCBtYWlsIGFuZCBJTSksIHRoZQ0KICAgcG90ZW50aWFsIGZvciBl bW90aWNvbiBjb25mdXNpb24gb25jZSBhZ2FpbiBleGlzdHMsIHNpbmNlIHRoZQ0KICAgZW5kcG9p bnRzIGFyZSBtYWtpbmcgaW5kZXBlbmRlbnQgZGVjaXNpb25zIG9mIHRoZSBzZW1hbnRpY3Mgb2Yg YQ0KICAgc3RyaW5nIG9mIGNoYXJhY3RlcnMuDQoNCiAgIEp1c3QgcmVjZW50bHksIHdpdGggdGhl IHVwY29taW5nIHJvbGwgb3V0IG9mIHRoZSBlbnRlcnByaXNlIHRvIHB1YmxpYw0KICAgSU0gY29u bmVjdGl2aXR5IHNlcnZpY2VzLCB0aGUgaW52b2x2ZWQgcGFydGllcyBjYW1lIHRvIHJlYWxpemUg dGhhdA0KICAgaW4gYWRkaXRpb24gdG8gdGhlIHdlbGwtZGVmaW5lZCBzdGFuZGFyZCB0cmFuc3Bv cnQsIHNlY3VyaXR5LA0KICAgc2lnbmFsaW5nLCBwcmVzZW5jZSwgYW5kIElNIG1lYW5zIChmb3Ig ZGV0YWlscyBzZWUgSW50ZXItZG9tYWluDQogICBSZXF1aXJlbWVudHMgZm9yIFNJUC9TSU1QTEUg WzRdKSwgbm8gbGVzcyBjb25zaWRlcmF0aW9uIG5lZWRlZCB0byBiZQ0KICAgaW52ZXN0ZWQgaW50 byBub3JtYWxpemluZyB0aGUgZXhwcmVzc2lvbnMgYW5kIGVtb3Rpb25zIGJlaW5nIHVzZWQgc28N CiAgIGV4dGVuc2l2ZWx5IGluIElNIGNvbW11bmljYXRpb25zIHRvZGF5Lg0KDQogICBUYWtlLCBm b3IgZXhhbXBsZSwgdGhlIGVtb3RpY29uIGNvbnNpc3Rpbmcgb2YgdGhlIGNoYXJhY3RlcnM6IDB4 M0EsDQogICAweDJELCBhbmQgMHgyQSwgb3I6DQoNCiAgICAgICAgICAgICAgICAgICA6LSoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMw0KDQogICBPbmUgY29tbWVy Y2lhbCBpbnN0YW50IG1lc3NhZ2luZyBjbGllbnQgbWlnaHQgZGlzcGxheSBmb3IgdGhlc2UNCiAg IGNoYXJhY3RlcnMgYW4gaWNvbiB0aGF0IGluZGljYXRlcyBhIHVzZXIgd2hpc3BlcmluZywgd2hp bGUgYW5vdGhlcg0KICAgbWlnaHQgc2hvdyBhIHVzZXIga2lzc2luZy4gIFRvIGEgdXNlciB3aG8g c2VsZWN0ZWQgIndoaXNwZXIiIGZyb20gYQ0KICAgcGFsZXR0ZSBvZiBlbW90aW9ucyB0byByZXBy ZXNlbnQgaW4gYSBzZW50IG1lc3NhZ2UsIHRoZSByZWNlaXZlcidzDQogICBpbnRlcnByZXRhdGlv biB0aGF0IHRoZSBzZW5kZXIgaGFkIHdhbnRlZCB0byBzZW5kIGEga2lzcyB3b3VsZCBiZQ0KICAg YW11c2luZyBhdCBiZXN0IGFuZCBoaWdobHkgaW5hcHByb3ByaWF0ZSBhdCB3b3JzdCwgd2l0aCBw b3RlbnRpYWxseQ0KICAgc2lnbmlmaWNhbnQgZW1vdGlvbmFsIGFuZCBjb21tZXJjaWFsIGltcGxp Y2F0aW9ucy4NCg0KDQoNCg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2Jl ciAzLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICAgRkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0K DQogICBJbiBvcmRlciB0byBtaXRpZ2F0ZSB0aGVzZSBlZmZlY3RzLCB0aGUgYXV0aG9ycyBwcm9w b3NlIEZFRUwsIHRoZQ0KICAgRmVkZXJhdGVkIEVtb3RpY29uIGFuZCBFeHByZXNzaW9uIExhbmd1 YWdlLCB3aGljaCBwcm9wb3NlcyBhIHN0YW5kYXJkDQogICBmb3IgZXhwcmVzc2luZyBhbmQgaW50 ZXJwcmV0aW5nIGVtb3RpY29ucyBpbiB0ZXh0LWJhc2VkIG1lc3NhZ2luZy4NCg0KNC4gIFNwZWNp ZmljYXRpb24NCg0KICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgc2V2ZXJhbCBlbW90aW9u YWwgZXhwcmVzc2lvbnMgaW4gdGV4dA0KICAgY29tbXVuaWNhdGlvbnMuICBUaGVzZSBlbW90aW9u cyBhcmUgc3BlY2lmaWVkIGJ5IHRleHQgcGF0dGVybnMgdGhhdA0KICAgYXJlIGludGVycHJldGVk IGJ5IHRoZSBtZXNzYWdpbmcgZW5kcG9pbnQgYXMgYmVpbmcgZXF1aXZhbGVudCB0byBhDQogICBj ZXJ0YWluIGdyYXBoaWNhbCByZXByZXNlbnRhdGlvbi4gIFNldmVyYWwgY29tbW9uIGVtb3Rpb25z IGFyZQ0KICAgc3VwcG9ydGVkIGFjcm9zcyBtb3N0IGZlZGVyYXRlZCBkb21haW5zLiAgQmVjYXVz ZSBvZiBkaWZmZXJlbmNlcyBpbg0KICAgdGhlIHR5cGljYWwgdXNlciBpbiB2YXJpb3VzIGNvbW11 bmljYXRpb25zIHN5c3RlbXMsIG1hbnkgYWRkaXRpb25hbA0KICAgZW1vdGlvbnMgKGFsb25nIHdp dGggYWN0aXZpdGllcyBhbmQgb3RoZXIgZXhwcmVzc2lvbnMpIGFyZSBzdXBwb3J0ZWQNCiAgIHRo YXQgbWF5IG5vdCBuZWNlc3NhcmlseSB0cmFuc2xhdGUgd2VsbCBhY3Jvc3MgdGhlIGZlZGVyYXRl ZA0KICAgYm91bmRhcnkuDQoNCjQuMSAgQmFzaWMgRW1vdGljb25zDQoNCiAgIEFsbCBGRUVMIGNv bXBsaWFudCBzeXN0ZW1zIE1VU1Qgc3VwcG9ydCB0aGUgZm9sbG93aW5nIGVtb3Rpb25zIHZpYQ0K ICAgZW1vdGljb25zLSBoYXBweSwgc2FkLCB3aW5raW5nLCBhbmQgY29uZnVzZWQuICBUaGVzZSBl bW90aW9ucyBhcmUgdGhlDQogICBtb3N0IGJhc2ljIHRoYXQgY2FuIGJlIGV4cHJlc3NlZCBpbiBj b252ZXJzYXRpb24sIHJlZ2FyZGxlc3Mgb2YgdGhlDQogICB0eXBlIG9mIGNvbnZlcnNhdGlvbi4g IEVhY2ggb2YgdGhlc2UgZW1vdGlvbnMgTVVTVCBiZSByZXByZXNlbnRlZA0KICAgd2l0aCBhIGdy YXBoaWNhbCByZXByZXNlbnRhdGlvbiBvZiBhIGZhY2UuICBUaGF0IGZhY2UgU0hPVUxEIE5PVA0K ICAgY29udmV5IGFueSBmZWVsaW5ncyBpbiBhZGRpdGlvbiB0byBoYXBwaW5lc3MgdGhhdCBtYXkg YmUNCiAgIG1pc2ludGVycHJldGVkIGJ5IHRoZSBwZWVyLiAgRXhhbXBsZXMgb2YgYWRkaXRpb25h bCBlbW90aW9ucyBhcmUNCiAgIHNhcmNhc20gb3Igc2tlcHRpY2lzbSAoc21pcmspLCBsYXVnaGlu ZyBvciB3aW5raW5nLg0KDQo0LjIgIEV4dGVuZGVkIEVtb3RpY29ucw0KDQogICBJbiBhZGRpdGlv biB0byB0aGUgYmFzaWMgZW1vdGljb25zLCB0aGVyZSBhcmUgc2V2ZXJhbCBlbW90aW9ucyBhbmQN CiAgIGFjdGl2aXRpZXMgdGhhdCBhIEZFRUwgY29tcGxpYW50IHN5c3RlbSBtYXkgd2lzaCB0byBj b252ZXkuICBUaGVzZQ0KICAgZW1vdGljb25zIGFsbG93IHVzZXJzIHRvIGZpbmUgdHVuZSB0aGUg ZW1vdGlvbiBiZWluZyBleHByZXNzZWQuICBUaGUNCiAgIGVtb3RpY29ucyBhcmUgc3BlY2lmaWVk IGVpdGhlciBiZWNhdXNlIHRoZXkgYXJlIGNvbW1vbiBhY3Jvc3MgbW9zdA0KICAgY29udmVyc2F0 aW9ucyByZWdhcmRsZXNzIG9mIHR5cGUsIG9yIHRoZXkgcmVwcmVzZW50IHVuaXF1ZSBmZWVsaW5n cw0KICAgdGhhdCBzaG91bGQgbm90IGJlIG1pc2ludGVycHJldGVkIGFzIG9wcG9zaW5nIGVtb3Rp b25zLiAgIkluIGxvdmUiIGlzDQogICBhIHByaW1lIGV4YW1wbGUgb2Ygd2h5IGV4dGVuZGVkIGVt b3RpY29ucyBtdXN0IG5vdCBiZSBtaXNpbnRlcnByZXRlZC4NCiAgIElmIGEgdXNlciBpbiBhIGNv cnBvcmF0ZSBzZXR0aW5nIHNlbmRzIGEgbWVzc2FnZSB3aXRoIGEgIndoaXNwZXJpbmciDQogICBl bW90aWNvbiwgYW5kIHRoZSByZWNlaXZlciBvZiB0aGF0IG1lc3NhZ2UgaXMgdXNpbmcgYSBjbGll bnQgaW4gYQ0KICAgc29jaWFsIG5ldHdvcmsgd2hpY2ggdHJlYXRzIHRoaXMgQVNDSUkgc3RyaW5n IGFzICJraXNzaW5nIiBvciAiaW4NCiAgIGxvdmUiLCB0aGUgdHJhbnNsYXRpb24gY2FuIGNyZWF0 ZSBwb3RlbnRpYWwgcGVyc29uYWwgb3IgbGVnYWwNCiAgIGNvbXBsaWNhdGlvbnMgZm9yIHRoZSBz ZW5kZXIuICBBcHBsaWNhdGlvbnMgU0hPVUxEIGVpdGhlciBzdXBwb3J0IG9yDQogICBhdCBsZWFz dCB1bmRlcnN0YW5kIChyZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgaXMgcmVuZGVyZWQpIGVtb3Rp Y29ucw0KICAgcmVwcmVzZW50aW5nIHRoZSBmb2xsb3dpbmc6DQoNCg0KDQoNCg0KDQoNCg0KQW9r aSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA1ICAgICAgICAgICAg ICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRkVFTCAg ICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICAgICAgICAgIEVtb3Rpb25z DQogICAgICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgTGF1Z2hpbmcNCiAg ICAgICAgICAgU3VycHJpc2VkDQogICAgICAgICAgIEFuZ3J5DQogICAgICAgICAgIEZlZWxpbmcg c2lsbHkNCiAgICAgICAgICAgQ3J5aW5nDQogICAgICAgICAgIEluIGxvdmUNCiAgICAgICAgICAg RmVlbGluZyBpbm5vY2VudCBvciBhbmdlbGljDQoNCiAgICAgICAgICAgQWN0aXZpdGllcw0KICAg ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICBJbGwNCiAgICAgICAgICAg QXNsZWVwIG9yIEJvcmVkDQogICAgICAgICAgIE5vdCB0YWxraW5nIG9yIFJlZnVzZSB0byBzYXkN Cg0KDQo0LjMgIEluYW5pbWF0ZSBPYmplY3RzDQoNCiAgIFNvbWUgbWVzc2FnaW5nIHN5c3RlbXMg dXNlIGVtb3RpY29uIHN1cHBvcnQgdG8gcmVuZGVyIG9iamVjdHMgdGhhdCBkbw0KICAgbm90IHJl cHJlc2VudCBhbnkgZW1vdGlvbiBhdCBhbGwuICBXaGlsZSBub3QgY29udGFpbmluZyBhIGZhY2Us IHRoZXNlDQogICBvYmplY3RzIGltcGxpY2l0bHkgcmVwcmVzZW50IGFjdGl2aXRpZXMgb2YgYSB1 c2VyLiAgQSBGRUVMIGNvbXBsaWFudA0KICAgc3lzdGVtIE1BWSBzdXBwb3J0IHRoZSBmb2xsb3dp bmcgaW5hbmltYXRlIG9iamVjdCBlbW90aWNvbnMtIGNvZmZlZSwNCiAgIHBhY2thZ2Ugb3IgZ2lm dCwgYWxjb2hvbGljIGJldmVyYWdlLCBhbmQgcGhvbmUuDQoNCjQuNCAgU3BlY2lhbGl6ZWQgRW1v dGljb25zDQoNCiAgIEJleW9uZCB0aGUgY29tbW9uIGNvbnZlcnNhdGlvbmFsIGVtb3RpY29ucywg c29tZSBzeXN0ZW1zIG1heSB3aXNoIHRvDQogICBleHByZXNzIGVtb3Rpb25zIGFuZCBhY3Rpdml0 aWVzIHRoYXQgYXJlIHVuaXF1ZSB0byBzcGVjaWZpYw0KICAgY29tbXVuaWNhdGlvbnMuICBBIEZF RUwgY29tcGxpYW50IHN5c3RlbSBNQVkgc3VwcG9ydCBlbW90aWNvbnMgbm90DQogICBvdGhlcndp c2UgZGVmaW5lZCBpbiB0aGlzIHNwZWNpZmljYXRpb24uICBBbnkgZW1vdGlvbiBleHByZXNzZWQg d2l0aA0KICAgYSBwcm9wcmlldGFyeSBlbW90aWNvbiBNVVNUIGJlIHJlZ2lzdGVyZWQgd2l0aCBJ QU5BIHRvIHByZXZlbnQNCiAgIGNvbmZsaWN0aW5nIGVtb3Rpb25zLg0KDQo0LjUgIFRyYW5zbGF0 aW9ucw0KDQogICBJbiBzb21lIGNhc2VzLCBhIHBlcmZlY3QgdHJhbnNsYXRpb24gbWF5IG5vdCBl eGlzdCBiZXR3ZWVuIHR3byBGRUVMDQogICBjb21wbGlhbnQgc3lzdGVtcy4gIFdoZW4gbm8gZGly ZWN0IHRyYW5zbGF0aW9uIGlzIGF2YWlsYWJsZSwgYSBzeXN0ZW0NCiAgIE1BWSBkaXNwbGF5IGEg ZGlmZmVyZW50IGVtb3RpY29uIGlmIHRoYXQgZW1vdGljb24gcmVwcmVzZW50cyB0aGUgc2FtZQ0K ICAgZ2VuZXJhbCByYW5nZSBvZiBlbW90aW9uIG9yIHJlbGF0ZWQgYWN0aXZpdHkuICBBbnkgZW1v dGljb24NCiAgIHRyYW5zbGF0aW9uIE1VU1QgcHJlc2VudCB0aGUgc2FtZSBtZWFuaW5nIG9yIGV4 dHJhY3QgbWVhbmluZyByYXRoZXINCiAgIHRoYW4gYWRkLiAgRm9yIGV4YW1wbGUsIGEgdG9vdGh5 IGdyaW4gKHZlcnkgaGFwcHkpIE1BWSBiZSB0cmFuc2xhdGVkDQogICB0byBzbWlsZXkgKGhhcHB5 KS4gIEhvd2V2ZXIgc21pbGV5IGRvZXMgbm90IHRyYW5zbGF0ZSB0byB0b290aHkgZ3Jpbi4NCiAg IFNpbWlsYXJseSwgdHJhbnNsYXRpb25zIGFwcGxpZWQgdG8gaW5hbmltYXRlIG9iamVjdHMgTVVT VCByZWxheSB0aGUNCiAgIHNhbWUgb3Igc2ltaWxhciBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSB0 aGUgc2VuZGVyLiAgRm9yIGV4YW1wbGUsIGENCiAgIGdpZnQgbWF5IGJlIHJlcHJlc2VudGVkIGFz IGEgcGFja2FnZSwgYnV0IGEgcGFja2FnZSBtYXkgbm90DQogICByZXByZXNlbnRlZCBhcyBhIGdp ZnQuDQoNCg0KDQoNCkFva2ksIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMywg MjAwNSAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgIEZFRUwgICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDA1DQoNCg0KICAg SWYgYSBzeXN0ZW0gY2Fubm90IHByb3ZpZGUgYSBzaW1pbGFyIHJlcHJlc2VudGF0aW9uIHRvIHRo YXQgZXhwcmVzc2VkDQogICBieSB0aGUgc2VuZGVyLCB0aGUgcmVjZWl2aW5nIHN5c3RlbSBNVVNU IHByZXNlbnQgdGhlIGNvbnRlbnQgYXMgdGV4dCwNCiAgIHRodXMgYWxsb3dpbmcgdGhlIHVzZXIg dG8gaW50ZXJwcmV0IHRoZSB0ZXh0IGFzIGJlc3QgYXMgcG9zc2libGUuDQogICBFeGFtcGxlcyBv ZiBzaW1pbGFyIChhbmQgZGlzc2ltaWxhcikgcmVwcmVzZW50YXRpb25zIGFyZToNCg0KICAgU2lt aWxhcjogaGVhcnQgYW5kIGtpc3MoYm90aCBsb3ZlKSwgc21pbGV5IGFuZCBzbWlsaW5nIGFuZ2Vs KGJvdGgNCiAgICAgIG5pY2UpLg0KDQogICBEaXNzaW1pbGFyOiBraXNzIGFuZCB0ZWxsaW5nIGEg c2VjcmV0IChpbmFkdmVydGVudGx5IGluYXBwcm9wcmlhdGUpLA0KICAgICAgYmVlciBhbmQgY29m ZmVlIChvbmUgaXMgYWxjb2hvbGljLCB0aGUgb3RoZXIgaXMgbm90KS4NCg0KNC41LjEgIExvY2Fs ZSBTcGVjaWZpYyBUcmFuc2xhdGlvbnMNCg0KICAgVGhlcmUgYXJlIHNvbWUgY2FzZXMgd2hlcmUg YW4gZW1vdGljb24gZXhwcmVzc2VkIGJ5IGEgdXNlciBpbiBvbmUNCiAgIHJlZ2lvbiBtYXkgbm90 IGhhdmUgdGhlIHNhbWUgbWVhbmluZyB0byB0aGUgb3RoZXIgdXNlciB3aG8gcmVzaWRlcyBpbg0K ICAgYSBkaWZmZXJlbnQgcmVnaW9uLiAgSW4gdGhpcyBjYXNlLCB0cmFuc2xhdGlvbnMgTUFZIGFs c28gYmUgcGVyZm9ybWVkDQogICBvbiBlbW90aWNvbnMgZm9yIHB1cnBvc2Ugb2YgbG9jYWxpemF0 aW9uLCBwcm92aWRlZCBpdCBkb2VzIG5vdCBjaGFuZ2UNCiAgIHRoZSBnZW5lcmFsIGludGVudCBv ZiB0aGUgc2VuZGVyLiAgRXhhbXBsZXMgb2YgdGhpcyB0eXBlIG9mDQogICB0cmFuc2xhdGlvbiBh cmU6DQoNCg0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgU2VuZGVyIGxvY2FsaXplZCAgICAgfCBD dWx0dXJlIG5ldXRyYWxpemVkICB8IFJlY2VpdmVyIGxvY2FsaXplZCAgICB8DQogICB8ICAgICAg ICAgICAgICAgICAgICAgIHwgKHN0YW5kYXJkIGVuY29kaW5nKSAgfCAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgVVNBLSBDaHVnZ2luZyBhIGJlZXIgfCBI YXZpbmcgYSBkcmluayAgICAgICB8IEZyYW5jZS0gRHJpbmtpbmcgd2luZSB8DQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KICAgfCBVLkstIFBsYXlpbmcgZGFydHMgICB8IEVuZ2FnaW5nIGluIGEgZ2FtZSAg IHwgSW5kaWEtIFBsYXlpbmcgY3JpY2tldHwNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgfCBv ciBzcG9ydCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KICAgfCBUZXhhcy0gV2VhcmluZyBhICAgICB8IFdlYXJpbmcgYSBoZWFkICAgICAg IHwgQm9zdG9uLSBXZWFyaW5nIGEgICAgIHwNCiAgIHwgY293Ym95IGhhdCAgICAgICAgICAgfCBn YXJtZW50ICAgICAgICAgICAgICB8IFJlZCBTb3ggY2FwICAgICAgICAgICB8DQogICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KDQoNCjQuNiAgU3VtbWFyeQ0KDQogICBUaGUgZm9sbG93aW5nIHRhYmxlIHByb3Zp ZGVzIHRoZSBzZXQgb2Yga25vd24gZW1vdGljb25zIHRoYXQgTUFZIGJlDQogICBzdXBwb3J0ZWQg YnkgYW4gaW5zdGFudCBtZXNzYWdlIHN5c3RlbS4gIEVhY2ggZW1vdGljb24gZGVzY3JpcHRpb24g aXMNCiAgIGFjY29tcGFuaWVkIGJ5IGEgZGVzY3JpcHRpb24sIHN1cHBvcnQgcmVxdWlyZW1lbnQs IGFuZA0KICAgc3VwcG9ydGVkL3Vuc3VwcG9ydGVkIHRyYW5zbGF0aW9ucy4NCg0KICAgKy0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tKy0tLS0tLS0t LS0tLS0tLSsNCiAgIHwgRW1vdGljb24gfCBEZXNjcmlwdGlvbiAgIHwgU3VwcG9ydGVkICAgIHwg TUFZIGVxdWFsIHwgTVVTVCBOT1QgZXF1YWx8DQogICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KICAgfCA6LSkg ICAgICB8IEhhcHB5ICAgICAgICAgfCBNVVNUICAgICAgICAgfCBOb25lICAgICAgfCBTYWQsIHdv cnJpZWQsIHwNCiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgIHwgb3IgYW5ncnkgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KQW9r aSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA1ICAgICAgICAgICAg ICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgRkVFTCAg ICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQogICB8IDotKCAgICAgIHwgU2Fk ICAgICAgICAgICB8IE1VU1QgICAgICAgICB8IE5vbmUgICAgICB8IEhhcHB5ICAgICAgICAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgOy0pICAgICAgfCBXaW5raW5nICAgICAgIHwgTVVTVCAg ICAgICAgIHwgTm9uZSAgICAgIHwgQW55ICAgICAgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCA6LS8gICAgICB8IENvbmZ1c2VkIG9yICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg fCBIYXBweSwgU2FkLCAgIHwNCiAgIHwgICAgICAgICAgfCB3b3JyaWVkICAgICAgIHwgTVVTVCAg ICAgICAgIHwgTm9uZSAgICAgIHwgIFdpbmtpbmcgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCA6LSkpICAgICB8IExhdWdoaW5nICAgICAgfCBTSE9VTEQgICAgICAgfCBIYXBweSAgICAg fCBTYWQsIEFuZ3J5ICAgIHwNCiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogICB8IDotTyAgICAgIHwgU3Vy cHJpc2VkICAgICB8IFNIT1VMRCAgICAgICB8IENvbmZ1c2VkICB8IFNhZCwgQW5ncnkgICAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgOkAgICAgICAgfCBBbmdyeSAgICAgICAgIHwgU0hPVUxE ICAgICAgIHwgU2FkICAgICAgIHwgSGFwcHksIFdpbmtpbmd8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCA6LVAgICAgICB8IFRvbmd1ZSBvdXQsICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgfCBzaWxseSAgICAgICAgIHwgU0hPVUxE ICAgICAgIHwgSGFwcHkgICAgIHwgU2FkLCBBbmdyeSAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCA6LSogICAgICB8IEluIGxvdmUgICAgICAgfCBTSE9VTEQgICAgICAgfCBIYXBweSAgICAg fCBXaGlzcGVyLEFuZ3J5LHwNCiAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgICAgIHwgICAgICAgICAgIHwgU2FkLCBDb25mdXNlZCB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCBPOi0pICAgICB8IElubm9jZW50IG9yICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgfCBhbmdlbGljICAgICAgIHwgU0hPVUxE ICAgICAgIHwgSGFwcHkgICAgIHwgQW5ncnkgICAgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCArbyggICAgICB8IEZlZWxpbmcgaWxsICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwNCiAgIHwgICAgICAgICAgfCBvciBzaWNrICAgICAgIHwgU0hPVUxE ICAgICAgIHwgU2FkICAgICAgIHwgSW4gbG92ZSAgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCB8LSkgICAgICB8IEFzbGVlcCAvIGJvcmVkfCBTSE9VTEQgICAgICAgfCBTYWQgICAgICAg fCBOb25lICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogICB8IDotWCAgICAgIHwgTm90 IHRhbGtpbmcgICB8IFNIT1VMRCAgICAgICB8IE5vbmUgICAgICB8IExhdWdoaW5nICAgICAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgOicoICAgICAgfCBDcnlpbmcgICAgICAgIHwgU0hPVUxE ICAgICAgIHwgU2FkICAgICAgIHwgTGF1Z2hpbmcgICAgICB8DQogICArLS0tLS0tLS0tLSstLS0t LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKw0K ICAgfCA6LUQgICAgICB8IFRvb3RoeSBncmluICAgfCBNQVkgICAgICAgICAgfCBIYXBweSAgICAg fCBTYWQsIEFuZ3J5ICAgIHwNCiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogICB8IDgtKSAgICAgIHwgRmVl bGluZyBvciAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfA0K ICAgfCAgICAgICAgICB8IGxvb2tpbmcgY29vbCAgfCBNQVkgICAgICAgICAgfCBIYXBweSAgICAg fCBOb25lICAgICAgICAgIHwNCiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogICB8IChDKSAgICAgIHwgQ29m ZmVlICAgICAgICB8IE1BWSAgICAgICAgICB8IE5vbmUgICAgICB8IEFsY29ob2xpYyAgICAgfA0K ICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg fCBiZXZlcmFnZSAgICAgIHwNCiAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLSstLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQogICB8IChHKSAgICAgIHwgUGFj a2FnZSAgICAgICB8IE1BWSAgICAgICAgICB8IE5vbmUgICAgICB8IE5vbmUgICAgICAgICAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgKEQpICAgICAgfCBIYXZpbmcgYSAgICAgIHwgICAgICAg ICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICAgICB8DQogICB8ICAgICAgICAgIHwgZHJp bmsgICAgICAgICB8IE1BWSAgICAgICAgICB8IE5vbmUgICAgICB8IENvZmZlZSAgICAgICAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCiAgIHwgPCk6KSAgICAgfCBXZWFyaW5nIGEgaGVhZHwgTUFZICAg ICAgICAgIHwgSGFwcHkgICAgIHwgRmVlbGluZyBvciAgICB8DQogICB8ICAgICAgICAgIHwgZ2Fy bWVudCAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICB8IGxvb2tpbmcgY29vbCAgfA0K ICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0tLSsNCg0KDQoNCg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4cGly ZXMgT2N0b2JlciAzLCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgRkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFwcmls IDIwMDUNCg0KDQo1LiAgQXVnbWVudGVkIEJORiBmb3IgRkVFTCBjb21wbGlhbnQgZW1vdGljb25z DQoNCiAgIEFsbCBvZiB0aGUgbWVjaGFuaXNtcyBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudCBh cmUgZGVzY3JpYmVkIGluDQogICBib3RoIHByb3NlIGFuZCBhbiBhdWdtZW50ZWQgQmFja3VzLU5h dXIgRm9ybSAoQk5GKSBkZWZpbmVkIGluDQogICBSRkMtMjIzNCBbMl0uICBTZWN0aW9uIDYuMSBv ZiBSRkMgMjIzNCBkZWZpbmVzIGEgc2V0IG9mIGNvcmUgcnVsZXMNCiAgIHRoYXQgYXJlIHVzZWQg YnkgdGhpcyBzcGVjaWZpY2F0aW9uLCBhbmQgbm90IHJlcGVhdGVkIGhlcmUuDQogICBJbXBsZW1l bnRlcnMgbmVlZCB0byBiZSBmYW1pbGlhciB3aXRoIHRoZSBub3RhdGlvbiBhbmQgY29udGVudCBv ZiBSRkMNCiAgIDIyMzQgaW4gb3JkZXIgdG8gdW5kZXJzdGFuZCB0aGlzIHNwZWNpZmljYXRpb24u ICBDZXJ0YWluIGJhc2ljIHJ1bGVzDQogICBhcmUgaW4gdXBwZXJjYXNlLCBzdWNoIGFzIFNQLCBM V1MsIEhUQUIsIENSTEYsIERJR0lULCBBTFBIQSwgZXRjLg0KICAgQW5nbGUgYnJhY2tldHMgYXJl IHVzZWQgd2l0aGluIGRlZmluaXRpb25zIHRvIGNsYXJpZnkgdGhlIHVzZSBvZiBydWxlDQogICBu YW1lcy4NCg0KICAgSGFwcHkgICAgICAgICAgPSAoICI6LSkiIC8gIjopIiApDQogICBTYWQgICAg ICAgICAgICA9ICggIjotKCIgLyAiOigiICkNCiAgIFdpbmtpbmcgICAgICAgID0gKCAiOy0pIiAv ICI7KSIgKQ0KICAgQ29uZnVzZWQgICAgICAgPSAoICI6LS8iIC8gIjotcyIgKQ0KICAgTGF1Z2hp bmcgICAgICAgPSAiOi0pKSINCiAgIFN1cnByaXNlZCAgICAgID0gIjotTyINCiAgIEFuZ3J5ICAg ICAgICAgID0gKCAiOkAiIC8gIlgtKCIgKQ0KICAgRmVlbGluZyBzaWxseSAgPSA6LVANCiAgIElu IGxvdmUgICAgICAgID0gIjotKiINCiAgIElubm9jZW50ICAgICAgID0gIk86LSkiDQogICBJbGwg ICAgICAgICAgICA9ICIrbygiDQogICBBc2xlZXAgICAgICAgICA9ICJ8LSkiDQogICBOb3QgdGFs a2luZyAgICA9ICI6LVgiDQogICBDcnlpbmcgICAgICAgICA9ICI6JygiDQogICBUb290aHkgZ3Jp biAgICA9ICggIjotRCIgLyAiOkQiICkNCiAgIENvb2wgICAgICAgICAgID0gIjgtKSINCiAgIENv ZmZlZSAgICAgICAgID0gIihDKSINCiAgIFBhY2thZ2UgICAgICAgID0gIihHKSINCiAgIEhhdmlu ZyBhIGRyaW5rID0gIihEKSINCg0KDQo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg VGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBpc3N1ZXMg YmV5b25kIHRob3NlDQogICB0aGF0IGFwcGx5IHRvIHRoZSBwcm90b2NvbHMgYW5kIHRyYW5zcG9y dHMgb3ZlciB3aGljaCBlbW90aWNvbnMgYXJlDQogICBkZWxpdmVyZWQuICBIb3dldmVyLCBpdCBp cyB0aGUgYmVsaWVmIG9mIHRoZSBhdXRob3JzIHRoYXQgaGF2aW5nIGENCiAgIHN0YW5kYXJkIGZv cm1hdCBmb3IgZW1vdGljb25zIHdpbGwgcmVzdWx0IGluIGluY3JlYXNlZCBwcmVjaXNpb24gb2YN CiAgIGNvbW11bmljYXRpb25zIGJldHdlZW4gdXNlcnMsIHdoaWNoIHNob3VsZCByZWR1Y2UgdGhl IHJpc2sgb2YNCiAgIG1pc2ludGVycHJldGF0aW9uIG9yIGVtYmFycmFzc21lbnRzLg0KDQo3LiAg SUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBGdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBkb2N1bWVu dCB3aWxsIGVzdGFibGlzaCBhIEZFRUwgSUFOQSByZWdpc3RyeQ0KICAgd2hpY2ggd2lsbCBhbGxv dyBhcHBsaWNhdGlvbnMgdG8gcmVnaXN0ZXIgYXBwbGljYXRpb24tc3BlY2lmaWMNCiAgIGVtb3Rp Y29ucy4NCg0KDQoNCg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAz LCAyMDA1ICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgRkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQo4 LiAgUmVmZXJlbmNlcw0KDQo4LjEgIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCiAgIFsxXSAgQnJh ZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVpcmVt ZW50DQogICAgICAgIExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1hcmNoIDE5OTcuDQoNCiAg IFsyXSAgQ3JvY2tlciwgRC4sIEVkLiBhbmQgUC4gT3ZlcmVsbCwgIkF1Z21lbnRlZCBCTkYgZm9y IFN5bnRheA0KICAgICAgICBTcGVjaWZpY2F0aW9uczogQUJORiIsIFJGQyAyMjM0LCBOb3ZlbWJl ciAxOTk3Lg0KDQo4LjIgIEluZm9ybWF0aW9uYWwgUmVmZXJlbmNlcw0KDQogICBbM10gIEZhaGxt YW4sIFMuLCAiU21pbGV5IExvcmUgOi0pIiwNCiAgICAgICAgPGh0dHA6Ly93d3ctMi5jcy5jbXUu ZWR1L35zZWYvc2VmU21pbGV5Lmh0bT4uDQoNCiAgIFs0XSAgTGV2aW4sIE8uLCAiSW50ZXItZG9t YWluIFJlcXVpcmVtZW50cyBmb3IgU0lNUExFIiwNCiAgICAgICAgSW50ZXJuZXQtRHJhZnQgZHJh ZnQtbGV2aW4tc2ltcGxlLWludGVyZG9tYWluLXJlcXMtMDIsIEZlYnJ1YXJ5DQogICAgICAgIDIw MDUuDQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIEVkd2luIEFva2kNCiAgIEFtZXJpY2Eg T25saW5lLCBJbmMuDQogICAzNjAgVy4gQ2FyaWJiZWFuIERyaXZlDQogICBTdW5ueXZhbGUsIENB ICA5NDA4OQ0KICAgVVNBDQoNCiAgIEVtYWlsOiBhb2tpQGFvbC5uZXQNCg0KDQogICBPcml0IExl dmluDQogICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCiAgIE9uZSBNaWNyb3NvZnQgV2F5DQogICBS ZWRtb25kLCBXQSAgOTgwNTINCiAgIFVTQQ0KDQogICBFbWFpbDogb3JpdGxAbWljcm9zb2Z0LmNv bQ0KDQoNCiAgIFRpbSBSYW5nDQogICBNaWNyb3NvZnQgQ29ycG9yYXRpb24NCiAgIE9uZSBNaWNy b3NvZnQgV2F5DQogICBSZWRtb25kLCBXQSAgOTgwNTINCiAgIFVTQQ0KDQogICBFbWFpbDogdGlt cmFuZ0BtaWNyb3NvZnQuY29tDQoNCg0KDQoNCkFva2ksIGV0IGFsLiAgICAgICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMywgMjAwNSAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgIEZFRUwgICAgICAgICAgICAgICAgICAgICAgICBBcHJp bCAyMDA1DQoNCg0KICAgTWljaGFlbCBUcm9tbXNkb3JmZg0KICAgTWljcm9zb2Z0IENvcnBvcmF0 aW9uDQogICBPbmUgTWljcm9zb2Z0IFdheQ0KICAgUmVkbW9uZCwgV0EgIDk4MDUyDQogICBVU0EN Cg0KICAgRW1haWw6IG10cm9tbUBtaWNyb3NvZnQuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KQW9raSwgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAzLCAyMDA1 ICAgICAgICAgICAgICAgW1BhZ2UgMTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgRkVFTCAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMDUNCg0KDQpJbnRlbGxl Y3R1YWwgUHJvcGVydHkgU3RhdGVtZW50DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9u IHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwg UHJvcGVydHkgUmlnaHRzIG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8N CiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9n eSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBh bnkgbGljZW5zZSB1bmRlciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2 YWlsYWJsZTsgbm9yIGRvZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBp bmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRp b24NCiAgIG9uIHRoZSBwcm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRv Y3VtZW50cyBjYW4gYmUNCiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3Bp ZXMgb2YgSVBSIGRpc2Nsb3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFu eQ0KICAgYXNzdXJhbmNlcyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhl IHJlc3VsdCBvZiBhbg0KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5z ZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0 cyBieSBpbXBsZW1lbnRlcnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4g YmUgb2J0YWluZWQgZnJvbSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBo dHRwOi8vd3d3LmlldGYub3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJl c3RlZCBwYXJ0eSB0byBicmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywg cGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAg cmlnaHRzIHRoYXQgbWF5IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8g aW1wbGVtZW50DQogICB0aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0 aW9uIHRvIHRoZSBJRVRGIGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpEaXNjbGFpbWVy IG9mIFZhbGlkaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBvbiBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhF IENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJ UyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5U RVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMs IEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElOQ0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5Z IFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBUSEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxM IE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0K DQpDb3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNv Y2lldHkgKDIwMDUpLiAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0DQogICB0byB0aGUgcmlnaHRz LCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25zIGNvbnRhaW5lZCBpbiBCQ1AgNzgsIGFuZA0KICAg ZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWly IHJpZ2h0cy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5kaW5nIGZvciB0aGUgUkZDIEVk aXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICBJbnRlcm5ldCBT b2NpZXR5Lg0KDQoNCg0KDQpBb2tpLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDMsIDIwMDUgICAgICAgICAgICAgICBbUGFnZSAxMl0NCgwNCg0K ------_=_NextPart_001_01C5371A.F72E09F8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple ------_=_NextPart_001_01C5371A.F72E09F8-- From simple-bounces@ietf.org Fri Apr 1 21:55:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17634; Fri, 1 Apr 2005 21:55:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHYv8-0003cx-2M; Fri, 01 Apr 2005 22:03:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHYiS-0006sC-NI; Fri, 01 Apr 2005 21:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHYiP-0006s4-AT for simple@megatron.ietf.org; Fri, 01 Apr 2005 21:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17350 for ; Fri, 1 Apr 2005 21:50:21 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHYpq-0003Qu-6I for simple@ietf.org; Fri, 01 Apr 2005 21:58:07 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2005 18:50:15 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j322oCgS006401; Fri, 1 Apr 2005 18:50:13 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-2-30.cisco.com [10.86.242.30]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJB87692; Fri, 1 Apr 2005 18:50:11 -0800 (PST) Message-ID: <424E0862.8010901@cisco.com> Date: Fri, 01 Apr 2005 21:50:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fc33afc280b74ce7916a8c9e6ab57db8 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 54e0221cc855af1be978f9387027a2cf Content-Transfer-Encoding: 7bit Orit, I think most folks would agree that this is a problem. However, I am not sure I agree with the solution. When this has come up in the past, the general answer has been to use richer IM formats, such as html, that allow inclusion of graphical elements that convey the actual emoticon. This eliminates all of the interoperability issues you mention, and requires no additional standards work. Your draft doesnt discuss this option, and I am curious whether you considered it and rejected it, or had not considered it. I can think of only a few reasons why an embedded graphic would be a problem: 1. message size constraints, though the emoticon images are tiny and this seems not really a big deal 2. because there is a desire to translate the emoticon, and thus something that can be interpreted by an automata is required. Your draft touches on the second point. However, I'm not sure that translation is what is really desired. I think most users would be surprised and confused if they think they sent an image of a user chugging a beer, and then the recipient got a user sipping wine. How can the originating UA figure out the user INTENT when they selected the "chugging beer" emoticon? Your draft assumes that the user meant "having a drink". What if the intent of the communications was explicitly around beer, and NOT some other type of beverage? Thanks, Jonathan R. Orit Levin wrote: > > Guys, > > We know that SIMPLE is overloaded with work, but lately we came across a > new topic that seems to be crucial for standardization - especially for > the benefit of the growing IM communications. > > We wrote a draft that highlights the problem and introduces some > solutions. These are initial thoughts only. You will see that many areas > (such as the security considerations) need to be thought through in more > details. Before we invest more efforts and submit the draft to the IETF, > we wanted to share our thoughts and get your feedback regarding the > validity of this direction in general. > > > Thanks a lot, > The authors. > > > ------------------------------------------------------------------------ > > > > > > Network Working Group E. Aoki > Internet-Draft America Online, Inc. > Expires: October 3, 2005 O. Levin > T. Rang > M. Trommsdorff > Microsoft Corporation > April 2005 > > > FEEL - The Federated Emoticon and Expression Language > draft-aoki-feel-00 > > Status of this Memo > > This document is an Internet-Draft and is subject to all provisions > of Section 3 of RFC 3667. By submitting this Internet-Draft, each > author represents that any applicable patent or other IPR claims of > which he or she is aware have been or will be disclosed, and any of > which he or she become aware will be disclosed, in accordance with > RFC 3668. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as > Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on October 3, 2005. > > Copyright Notice > > Copyright (C) The Internet Society (2005). > > Abstract > > This document describes a set of standard conventions for emoticons, > also known as "smileys", that allow messaging systems from different > vendors to convey text-based expressions interoperably. The > > > > Aoki, et al. Expires October 3, 2005 [Page 1] > > Internet-Draft FEEL April 2005 > > > emoticons defined in this document can be conveyed over any > text-based messaging protocol, including email, instant messaging, > ntalk, and others. > > Table of Contents > > 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 > 4.1 Basic Emoticons . . . . . . . . . . . . . . . . . . . . . 5 > 4.2 Extended Emoticons . . . . . . . . . . . . . . . . . . . . 5 > 4.3 Inanimate Objects . . . . . . . . . . . . . . . . . . . . 6 > 4.4 Specialized Emoticons . . . . . . . . . . . . . . . . . . 6 > 4.5 Translations . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.5.1 Locale Specific Translations . . . . . . . . . . . . . 7 > 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 5. Augmented BNF for FEEL compliant emoticons . . . . . . . . . . 9 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 > 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 > 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 > 8.2 Informational References . . . . . . . . . . . . . . . . . 10 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 > Intellectual Property and Copyright Statements . . . . . . . . 12 > > > > > > > > > > > > > > > > > > > > > > > > > > > Aoki, et al. Expires October 3, 2005 [Page 2] > > Internet-Draft FEEL April 2005 > > > 1. Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119 [1]. > > 2. Background > > Each day, millions of people around the world exchange literally > billions of emails, instant messages, and other forms of text-based, > computer mediated communication via the Internet. Although > originally designed to facilitate academic research, today's Internet > messaging systems are used within enterprises, families, and social > groups as a fast, efficient form of communication. > > As the user base for messaging systems grew, so, too, did > misunderstandings between and among user groups. Deprived of the > cues provided through vocal inflection or personal interaction, > messaging users found it difficult to discern the tone or intent of > specific messages or message exchanges. The complex emotions that > underlie sarcasm, joking, anger, and affection, just to name a few, > were neutralized in these text based messaging formats and often > resulted in misinterpretation or embarrassment. > > Over time, emoticons were devised to fill this gap and to enable > Internet users to express emotions through text-based messaging > systems [3]. Emoticons are a series of text-based characters which, > when viewed on their side, form a picture that is understood to > convey a particular emotion. > > The most common of these emoticons is the "smiley," consisting of the > ASCII characters 0x3A, 0x2D, and 0x29. When displayed, these > characters together appear like this: > > :-) > > Figure 1 > > which is often used to indicate that a preceding comment is humorous > in nature. > > Soon, users devised ever more elaborate forms of emoticons to > represent a wider variety of emotions. The following examples > represent crying, winking, and sticking out one's tongue, for > example. > > :'( ;-) :-P > > > > > Aoki, et al. Expires October 3, 2005 [Page 3] > > Internet-Draft FEEL April 2005 > > > Figure 2 > > The growing array of emoticons sometimes made it difficult for users > to understand what emotion a given series of characters was supposed > to represent, so some messaging user agents, when rendering text > containing an emoticon began to replace the characters representing > the emoticon with a graphically rendered static icon that would be > displayed in their place. On the composition side, these user agents > often provided a menu or other user interface element that allowed > users to select an emotion graphically from a list, substituting the > appropriate textual representations for on-the-wire rendering of the > expression. Many of today's commercial instant messaging clients, > for example, include menus of a dozen or more emoticons that users > can insert into their conversations. > > 3. Motivation > > However, these user agent manipulations, although convenient for > users, come at the price of interoperability. As vendors create > systems that interoperate with one another, or that bridge various > different forms of text based communications (e.g., mail and IM), the > potential for emoticon confusion once again exists, since the > endpoints are making independent decisions of the semantics of a > string of characters. > > Just recently, with the upcoming roll out of the enterprise to public > IM connectivity services, the involved parties came to realize that > in addition to the well-defined standard transport, security, > signaling, presence, and IM means (for details see Inter-domain > Requirements for SIP/SIMPLE [4]), no less consideration needed to be > invested into normalizing the expressions and emotions being used so > extensively in IM communications today. > > Take, for example, the emoticon consisting of the characters: 0x3A, > 0x2D, and 0x2A, or: > > :-* > > Figure 3 > > One commercial instant messaging client might display for these > characters an icon that indicates a user whispering, while another > might show a user kissing. To a user who selected "whisper" from a > palette of emotions to represent in a sent message, the receiver's > interpretation that the sender had wanted to send a kiss would be > amusing at best and highly inappropriate at worst, with potentially > significant emotional and commercial implications. > > > > > Aoki, et al. Expires October 3, 2005 [Page 4] > > Internet-Draft FEEL April 2005 > > > In order to mitigate these effects, the authors propose FEEL, the > Federated Emoticon and Expression Language, which proposes a standard > for expressing and interpreting emoticons in text-based messaging. > > 4. Specification > > This specification defines several emotional expressions in text > communications. These emotions are specified by text patterns that > are interpreted by the messaging endpoint as being equivalent to a > certain graphical representation. Several common emotions are > supported across most federated domains. Because of differences in > the typical user in various communications systems, many additional > emotions (along with activities and other expressions) are supported > that may not necessarily translate well across the federated > boundary. > > 4.1 Basic Emoticons > > All FEEL compliant systems MUST support the following emotions via > emoticons- happy, sad, winking, and confused. These emotions are the > most basic that can be expressed in conversation, regardless of the > type of conversation. Each of these emotions MUST be represented > with a graphical representation of a face. That face SHOULD NOT > convey any feelings in addition to happiness that may be > misinterpreted by the peer. Examples of additional emotions are > sarcasm or skepticism (smirk), laughing or winking. > > 4.2 Extended Emoticons > > In addition to the basic emoticons, there are several emotions and > activities that a FEEL compliant system may wish to convey. These > emoticons allow users to fine tune the emotion being expressed. The > emoticons are specified either because they are common across most > conversations regardless of type, or they represent unique feelings > that should not be misinterpreted as opposing emotions. "In love" is > a prime example of why extended emoticons must not be misinterpreted. > If a user in a corporate setting sends a message with a "whispering" > emoticon, and the receiver of that message is using a client in a > social network which treats this ASCII string as "kissing" or "in > love", the translation can create potential personal or legal > complications for the sender. Applications SHOULD either support or > at least understand (regardless of whether it is rendered) emoticons > representing the following: > > > > > > > > > Aoki, et al. Expires October 3, 2005 [Page 5] > > Internet-Draft FEEL April 2005 > > > Emotions > ------------------- > Laughing > Surprised > Angry > Feeling silly > Crying > In love > Feeling innocent or angelic > > Activities > -------------------- > Ill > Asleep or Bored > Not talking or Refuse to say > > > 4.3 Inanimate Objects > > Some messaging systems use emoticon support to render objects that do > not represent any emotion at all. While not containing a face, these > objects implicitly represent activities of a user. A FEEL compliant > system MAY support the following inanimate object emoticons- coffee, > package or gift, alcoholic beverage, and phone. > > 4.4 Specialized Emoticons > > Beyond the common conversational emoticons, some systems may wish to > express emotions and activities that are unique to specific > communications. A FEEL compliant system MAY support emoticons not > otherwise defined in this specification. Any emotion expressed with > a proprietary emoticon MUST be registered with IANA to prevent > conflicting emotions. > > 4.5 Translations > > In some cases, a perfect translation may not exist between two FEEL > compliant systems. When no direct translation is available, a system > MAY display a different emoticon if that emoticon represents the same > general range of emotion or related activity. Any emoticon > translation MUST present the same meaning or extract meaning rather > than add. For example, a toothy grin (very happy) MAY be translated > to smiley (happy). However smiley does not translate to toothy grin. > Similarly, translations applied to inanimate objects MUST relay the > same or similar information provided by the sender. For example, a > gift may be represented as a package, but a package may not > represented as a gift. > > > > > Aoki, et al. Expires October 3, 2005 [Page 6] > > Internet-Draft FEEL April 2005 > > > If a system cannot provide a similar representation to that expressed > by the sender, the receiving system MUST present the content as text, > thus allowing the user to interpret the text as best as possible. > Examples of similar (and dissimilar) representations are: > > Similar: heart and kiss(both love), smiley and smiling angel(both > nice). > > Dissimilar: kiss and telling a secret (inadvertently inappropriate), > beer and coffee (one is alcoholic, the other is not). > > 4.5.1 Locale Specific Translations > > There are some cases where an emoticon expressed by a user in one > region may not have the same meaning to the other user who resides in > a different region. In this case, translations MAY also be performed > on emoticons for purpose of localization, provided it does not change > the general intent of the sender. Examples of this type of > translation are: > > > +----------------------+----------------------+-----------------------+ > | Sender localized | Culture neutralized | Receiver localized | > | | (standard encoding) | | > +----------------------+----------------------+-----------------------+ > | USA- Chugging a beer | Having a drink | France- Drinking wine | > +----------------------+----------------------+-----------------------+ > | U.K- Playing darts | Engaging in a game | India- Playing cricket| > | | or sport | | > +----------------------+----------------------+-----------------------+ > | Texas- Wearing a | Wearing a head | Boston- Wearing a | > | cowboy hat | garment | Red Sox cap | > +----------------------+----------------------+-----------------------+ > > > 4.6 Summary > > The following table provides the set of known emoticons that MAY be > supported by an instant message system. Each emoticon description is > accompanied by a description, support requirement, and > supported/unsupported translations. > > +----------+---------------+--------------+-----------+---------------+ > | Emoticon | Description | Supported | MAY equal | MUST NOT equal| > +----------+---------------+--------------+-----------+---------------+ > | :-) | Happy | MUST | None | Sad, worried, | > | | | | | or angry | > +----------+---------------+--------------+-----------+---------------+ > > > > Aoki, et al. Expires October 3, 2005 [Page 7] > > Internet-Draft FEEL April 2005 > > > | :-( | Sad | MUST | None | Happy | > +----------+---------------+--------------+-----------+---------------+ > | ;-) | Winking | MUST | None | Any | > +----------+---------------+--------------+-----------+---------------+ > | :-/ | Confused or | | | Happy, Sad, | > | | worried | MUST | None | Winking | > +----------+---------------+--------------+-----------+---------------+ > | :-)) | Laughing | SHOULD | Happy | Sad, Angry | > +----------+---------------+--------------+-----------+---------------+ > | :-O | Surprised | SHOULD | Confused | Sad, Angry | > +----------+---------------+--------------+-----------+---------------+ > | :@ | Angry | SHOULD | Sad | Happy, Winking| > +----------+---------------+--------------+-----------+---------------+ > | :-P | Tongue out, | | | | > | | silly | SHOULD | Happy | Sad, Angry | > +----------+---------------+--------------+-----------+---------------+ > | :-* | In love | SHOULD | Happy | Whisper,Angry,| > | | | | | Sad, Confused | > +----------+---------------+--------------+-----------+---------------+ > | O:-) | Innocent or | | | | > | | angelic | SHOULD | Happy | Angry | > +----------+---------------+--------------+-----------+---------------+ > | +o( | Feeling ill | | | | > | | or sick | SHOULD | Sad | In love | > +----------+---------------+--------------+-----------+---------------+ > | |-) | Asleep / bored| SHOULD | Sad | None | > +----------+---------------+--------------+-----------+---------------+ > | :-X | Not talking | SHOULD | None | Laughing | > +----------+---------------+--------------+-----------+---------------+ > | :'( | Crying | SHOULD | Sad | Laughing | > +----------+---------------+--------------+-----------+---------------+ > | :-D | Toothy grin | MAY | Happy | Sad, Angry | > +----------+---------------+--------------+-----------+---------------+ > | 8-) | Feeling or | | | | > | | looking cool | MAY | Happy | None | > +----------+---------------+--------------+-----------+---------------+ > | (C) | Coffee | MAY | None | Alcoholic | > | | | | | beverage | > +----------+---------------+--------------+-----------+---------------+ > | (G) | Package | MAY | None | None | > +----------+---------------+--------------+-----------+---------------+ > | (D) | Having a | | | | > | | drink | MAY | None | Coffee | > +----------+---------------+--------------+-----------+---------------+ > | <):) | Wearing a head| MAY | Happy | Feeling or | > | | garment | | | looking cool | > +----------+---------------+--------------+-----------+---------------+ > > > > > Aoki, et al. Expires October 3, 2005 [Page 8] > > Internet-Draft FEEL April 2005 > > > 5. Augmented BNF for FEEL compliant emoticons > > All of the mechanisms specified in this document are described in > both prose and an augmented Backus-Naur Form (BNF) defined in > RFC-2234 [2]. Section 6.1 of RFC 2234 defines a set of core rules > that are used by this specification, and not repeated here. > Implementers need to be familiar with the notation and content of RFC > 2234 in order to understand this specification. Certain basic rules > are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. > Angle brackets are used within definitions to clarify the use of rule > names. > > Happy = ( ":-)" / ":)" ) > Sad = ( ":-(" / ":(" ) > Winking = ( ";-)" / ";)" ) > Confused = ( ":-/" / ":-s" ) > Laughing = ":-))" > Surprised = ":-O" > Angry = ( ":@" / "X-(" ) > Feeling silly = :-P > In love = ":-*" > Innocent = "O:-)" > Ill = "+o(" > Asleep = "|-)" > Not talking = ":-X" > Crying = ":'(" > Toothy grin = ( ":-D" / ":D" ) > Cool = "8-)" > Coffee = "(C)" > Package = "(G)" > Having a drink = "(D)" > > > 6. Security Considerations > > This document does not introduce any new security issues beyond those > that apply to the protocols and transports over which emoticons are > delivered. However, it is the belief of the authors that having a > standard format for emoticons will result in increased precision of > communications between users, which should reduce the risk of > misinterpretation or embarrassments. > > 7. IANA Considerations > > Future versions of this document will establish a FEEL IANA registry > which will allow applications to register application-specific > emoticons. > > > > > Aoki, et al. Expires October 3, 2005 [Page 9] > > Internet-Draft FEEL April 2005 > > > 8. References > > 8.1 Normative References > > [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement > Levels", BCP 14, RFC 2119, March 1997. > > [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997. > > 8.2 Informational References > > [3] Fahlman, S., "Smiley Lore :-)", > . > > [4] Levin, O., "Inter-domain Requirements for SIMPLE", > Internet-Draft draft-levin-simple-interdomain-reqs-02, February > 2005. > > > Authors' Addresses > > Edwin Aoki > America Online, Inc. > 360 W. Caribbean Drive > Sunnyvale, CA 94089 > USA > > Email: aoki@aol.net > > > Orit Levin > Microsoft Corporation > One Microsoft Way > Redmond, WA 98052 > USA > > Email: oritl@microsoft.com > > > Tim Rang > Microsoft Corporation > One Microsoft Way > Redmond, WA 98052 > USA > > Email: timrang@microsoft.com > > > > > Aoki, et al. Expires October 3, 2005 [Page 10] > > Internet-Draft FEEL April 2005 > > > Michael Trommsdorff > Microsoft Corporation > One Microsoft Way > Redmond, WA 98052 > USA > > Email: mtromm@microsoft.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Aoki, et al. Expires October 3, 2005 [Page 11] > > Internet-Draft FEEL April 2005 > > > Intellectual Property Statement > > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed to > pertain to the implementation or use of the technology described in > this document or the extent to which any license under such rights > might or might not be available; nor does it represent that it has > made any independent effort to identify any such rights. Information > on the procedures with respect to rights in RFC documents can be > found in BCP 78 and BCP 79. > > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use of > such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository at > http://www.ietf.org/ipr. > > The IETF invites any interested party to bring to its attention any > copyrights, patents or patent applications, or other proprietary > rights that may cover technology that may be required to implement > this standard. Please address the information to the IETF at > ietf-ipr@ietf.org. > > > Disclaimer of Validity > > This document and the information contained herein are provided on an > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET > ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, > INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE > INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Copyright Statement > > Copyright (C) The Internet Society (2005). This document is subject > to the rights, licenses and restrictions contained in BCP 78, and > except as set forth therein, the authors retain all their rights. > > > Acknowledgment > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > > > > Aoki, et al. Expires October 3, 2005 [Page 12] > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 1 22:14:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23671; Fri, 1 Apr 2005 22:14:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHZCu-0004aI-Vg; Fri, 01 Apr 2005 22:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHZ4G-00022f-GY; Fri, 01 Apr 2005 22:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHZ4D-00022Q-Vz for simple@megatron.ietf.org; Fri, 01 Apr 2005 22:12:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22690 for ; Fri, 1 Apr 2005 22:12:55 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHZBe-0004Rn-P3 for simple@ietf.org; Fri, 01 Apr 2005 22:20:40 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX19I5j+qwKYoFuqZTQhdkpnnfDjfL0gbvb4@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j323Boh3011464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Apr 2005 22:11:52 -0500 (EST) Message-ID: <424E0DA8.4010709@cs.columbia.edu> Date: Fri, 01 Apr 2005 22:12:40 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? References: <424E0862.8010901@cisco.com> In-Reply-To: <424E0862.8010901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Orit Levin , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit I wasn't quite sure whether this was a draft that needed a morality considerations section according to RFC 4041. In any event, from a minute of googling, there have been earlier attempts at related things: See http://www.vhml.org/vhml_about/html/vhml_about.shtml http://www.humanmarkup.org Jabber apparently allows moods in messages, too: http://www.jabber.org/jeps/jep-0107.html None of the emotional markup languages seem to have made much progress. Jonathan Rosenberg wrote: > Orit, > > I think most folks would agree that this is a problem. However, I am not > sure I agree with the solution. > > When this has come up in the past, the general answer has been to use > richer IM formats, such as html, that allow inclusion of graphical > elements that convey the actual emoticon. This eliminates all of the > interoperability issues you mention, and requires no additional > standards work. Your draft doesnt discuss this option, and I am curious > whether you considered it and rejected it, or had not considered it. > > I can think of only a few reasons why an embedded graphic would be a > problem: > > 1. message size constraints, though the emoticon images are tiny and > this seems not really a big deal > > 2. because there is a desire to translate the emoticon, and thus > something that can be interpreted by an automata is required. > > Your draft touches on the second point. However, I'm not sure that > translation is what is really desired. I think most users would be > surprised and confused if they think they sent an image of a user > chugging a beer, and then the recipient got a user sipping wine. How can > the originating UA figure out the user INTENT when they selected the > "chugging beer" emoticon? Your draft assumes that the user meant "having > a drink". What if the intent of the communications was explicitly around > beer, and NOT some other type of beverage? > > Thanks, > Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Fri Apr 1 22:28:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03312; Fri, 1 Apr 2005 22:28:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHZQJ-00058j-1G; Fri, 01 Apr 2005 22:35:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHZI2-0004gl-Lm; Fri, 01 Apr 2005 22:27:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHZI1-0004gc-4z for simple@megatron.ietf.org; Fri, 01 Apr 2005 22:27:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02709 for ; Fri, 1 Apr 2005 22:27:10 -0500 (EST) Received: from r2d2.aoltw.net ([64.236.137.26] helo=mcom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHZPS-00057X-9A for simple@ietf.org; Fri, 01 Apr 2005 22:34:55 -0500 Received: from dredd.mcom.com (dredd.nscp.aoltw.net [10.169.8.48]) by mcom.com (8.10.0/8.10.0) with ESMTP id j323Qp116380 for ; Fri, 1 Apr 2005 19:26:51 -0800 (PST) Received: from aol.net ([10.169.156.68]) by dredd.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IEAUWQ00.17U; Fri, 1 Apr 2005 19:26:50 -0800 Message-ID: <424E10FB.4010409@aol.net> Date: Fri, 01 Apr 2005 19:26:51 -0800 From: Edwin Aoki User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jdrosen@cisco.com, hgs@cs.columbia.edu Subject: Re: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? References: <424E0862.8010901@cisco.com> In-Reply-To: <424E0862.8010901@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 71427903e4ce43cf4879c36ef9c04bc1 Content-Transfer-Encoding: 7bit Cc: Orit Levin , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a1acaa54b4cde5ab4439a319e9b7f91 Content-Transfer-Encoding: 7bit Jonathan, Henning, All very good points, but the other issue with emoticon images comes from translation across different device boundaries. For example, a mobile phone terminal might not have the ability to display an emoticon image, or the message might traverse a text-to-speech agent on the way to a black phone. In this case, certain translations are going to be required, and you'd want the semantics of that to be well-defined. We'll definitely look into the morality considerations concern, particularly in response to sending the "chugging a beer" emoticon to underage recipients. That was something we'd completely overlooked. Thanks, -Edwin jdrosen@cisco.com wrote: > Orit, > > I think most folks would agree that this is a problem. However, I am > not sure I agree with the solution. > > When this has come up in the past, the general answer has been to use > richer IM formats, such as html, that allow inclusion of graphical > elements that convey the actual emoticon. This eliminates all of the > interoperability issues you mention, and requires no additional > standards work. Your draft doesnt discuss this option, and I am > curious whether you considered it and rejected it, or had not > considered it. > > I can think of only a few reasons why an embedded graphic would be a > problem: > > 1. message size constraints, though the emoticon images are tiny and > this seems not really a big deal > > 2. because there is a desire to translate the emoticon, and thus > something that can be interpreted by an automata is required. > > Your draft touches on the second point. However, I'm not sure that > translation is what is really desired. I think most users would be > surprised and confused if they think they sent an image of a user > chugging a beer, and then the recipient got a user sipping wine. How > can the originating UA figure out the user INTENT when they selected > the "chugging beer" emoticon? Your draft assumes that the user meant > "having a drink". What if the intent of the communications was > explicitly around beer, and NOT some other type of beverage? > > Thanks, > Jonathan R. > > Orit Levin wrote: > >> >> Guys, >> >> We know that SIMPLE is overloaded with work, but lately we came across a >> new topic that seems to be crucial for standardization - especially for >> the benefit of the growing IM communications. >> >> We wrote a draft that highlights the problem and introduces some >> solutions. These are initial thoughts only. You will see that many areas >> (such as the security considerations) need to be thought through in more >> details. Before we invest more efforts and submit the draft to the IETF, >> we wanted to share our thoughts and get your feedback regarding the >> validity of this direction in general. >> >> >> Thanks a lot, >> The authors. >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> Network Working Group E. Aoki >> Internet-Draft America Online, Inc. >> Expires: October 3, 2005 O. Levin >> T. Rang >> M. Trommsdorff >> Microsoft Corporation >> April 2005 >> >> >> FEEL - The Federated Emoticon and Expression Language >> draft-aoki-feel-00 >> >> Status of this Memo >> >> This document is an Internet-Draft and is subject to all provisions >> of Section 3 of RFC 3667. By submitting this Internet-Draft, each >> author represents that any applicable patent or other IPR claims of >> which he or she is aware have been or will be disclosed, and any of >> which he or she become aware will be disclosed, in accordance with >> RFC 3668. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as >> Internet-Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on October 3, 2005. >> >> Copyright Notice >> >> Copyright (C) The Internet Society (2005). >> >> Abstract >> >> This document describes a set of standard conventions for emoticons, >> also known as "smileys", that allow messaging systems from different >> vendors to convey text-based expressions interoperably. The >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 1] >> >> Internet-Draft FEEL April 2005 >> >> >> emoticons defined in this document can be conveyed over any >> text-based messaging protocol, including email, instant messaging, >> ntalk, and others. >> >> Table of Contents >> >> 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 >> 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 4.1 Basic Emoticons . . . . . . . . . . . . . . . . . . . . . 5 >> 4.2 Extended Emoticons . . . . . . . . . . . . . . . . . . . . 5 >> 4.3 Inanimate Objects . . . . . . . . . . . . . . . . . . . . 6 >> 4.4 Specialized Emoticons . . . . . . . . . . . . . . . . . . 6 >> 4.5 Translations . . . . . . . . . . . . . . . . . . . . . . . 6 >> 4.5.1 Locale Specific Translations . . . . . . . . . . . . . 7 >> 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 >> 5. Augmented BNF for FEEL compliant emoticons . . . . . . . . . . 9 >> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 >> 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 >> 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 >> 8.2 Informational References . . . . . . . . . . . . . . . . . 10 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 >> Intellectual Property and Copyright Statements . . . . . . . . 12 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 2] >> >> Internet-Draft FEEL April 2005 >> >> >> 1. Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC-2119 [1]. >> >> 2. Background >> >> Each day, millions of people around the world exchange literally >> billions of emails, instant messages, and other forms of text-based, >> computer mediated communication via the Internet. Although >> originally designed to facilitate academic research, today's Internet >> messaging systems are used within enterprises, families, and social >> groups as a fast, efficient form of communication. >> >> As the user base for messaging systems grew, so, too, did >> misunderstandings between and among user groups. Deprived of the >> cues provided through vocal inflection or personal interaction, >> messaging users found it difficult to discern the tone or intent of >> specific messages or message exchanges. The complex emotions that >> underlie sarcasm, joking, anger, and affection, just to name a few, >> were neutralized in these text based messaging formats and often >> resulted in misinterpretation or embarrassment. >> >> Over time, emoticons were devised to fill this gap and to enable >> Internet users to express emotions through text-based messaging >> systems [3]. Emoticons are a series of text-based characters which, >> when viewed on their side, form a picture that is understood to >> convey a particular emotion. >> >> The most common of these emoticons is the "smiley," consisting of the >> ASCII characters 0x3A, 0x2D, and 0x29. When displayed, these >> characters together appear like this: >> >> :-) >> >> Figure 1 >> >> which is often used to indicate that a preceding comment is humorous >> in nature. >> >> Soon, users devised ever more elaborate forms of emoticons to >> represent a wider variety of emotions. The following examples >> represent crying, winking, and sticking out one's tongue, for >> example. >> >> :'( ;-) :-P >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 3] >> >> Internet-Draft FEEL April 2005 >> >> >> Figure 2 >> >> The growing array of emoticons sometimes made it difficult for users >> to understand what emotion a given series of characters was supposed >> to represent, so some messaging user agents, when rendering text >> containing an emoticon began to replace the characters representing >> the emoticon with a graphically rendered static icon that would be >> displayed in their place. On the composition side, these user agents >> often provided a menu or other user interface element that allowed >> users to select an emotion graphically from a list, substituting the >> appropriate textual representations for on-the-wire rendering of the >> expression. Many of today's commercial instant messaging clients, >> for example, include menus of a dozen or more emoticons that users >> can insert into their conversations. >> >> 3. Motivation >> >> However, these user agent manipulations, although convenient for >> users, come at the price of interoperability. As vendors create >> systems that interoperate with one another, or that bridge various >> different forms of text based communications (e.g., mail and IM), the >> potential for emoticon confusion once again exists, since the >> endpoints are making independent decisions of the semantics of a >> string of characters. >> >> Just recently, with the upcoming roll out of the enterprise to public >> IM connectivity services, the involved parties came to realize that >> in addition to the well-defined standard transport, security, >> signaling, presence, and IM means (for details see Inter-domain >> Requirements for SIP/SIMPLE [4]), no less consideration needed to be >> invested into normalizing the expressions and emotions being used so >> extensively in IM communications today. >> >> Take, for example, the emoticon consisting of the characters: 0x3A, >> 0x2D, and 0x2A, or: >> >> :-* >> >> Figure 3 >> >> One commercial instant messaging client might display for these >> characters an icon that indicates a user whispering, while another >> might show a user kissing. To a user who selected "whisper" from a >> palette of emotions to represent in a sent message, the receiver's >> interpretation that the sender had wanted to send a kiss would be >> amusing at best and highly inappropriate at worst, with potentially >> significant emotional and commercial implications. >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 4] >> >> Internet-Draft FEEL April 2005 >> >> >> In order to mitigate these effects, the authors propose FEEL, the >> Federated Emoticon and Expression Language, which proposes a standard >> for expressing and interpreting emoticons in text-based messaging. >> >> 4. Specification >> >> This specification defines several emotional expressions in text >> communications. These emotions are specified by text patterns that >> are interpreted by the messaging endpoint as being equivalent to a >> certain graphical representation. Several common emotions are >> supported across most federated domains. Because of differences in >> the typical user in various communications systems, many additional >> emotions (along with activities and other expressions) are supported >> that may not necessarily translate well across the federated >> boundary. >> >> 4.1 Basic Emoticons >> >> All FEEL compliant systems MUST support the following emotions via >> emoticons- happy, sad, winking, and confused. These emotions are the >> most basic that can be expressed in conversation, regardless of the >> type of conversation. Each of these emotions MUST be represented >> with a graphical representation of a face. That face SHOULD NOT >> convey any feelings in addition to happiness that may be >> misinterpreted by the peer. Examples of additional emotions are >> sarcasm or skepticism (smirk), laughing or winking. >> >> 4.2 Extended Emoticons >> >> In addition to the basic emoticons, there are several emotions and >> activities that a FEEL compliant system may wish to convey. These >> emoticons allow users to fine tune the emotion being expressed. The >> emoticons are specified either because they are common across most >> conversations regardless of type, or they represent unique feelings >> that should not be misinterpreted as opposing emotions. "In love" is >> a prime example of why extended emoticons must not be misinterpreted. >> If a user in a corporate setting sends a message with a "whispering" >> emoticon, and the receiver of that message is using a client in a >> social network which treats this ASCII string as "kissing" or "in >> love", the translation can create potential personal or legal >> complications for the sender. Applications SHOULD either support or >> at least understand (regardless of whether it is rendered) emoticons >> representing the following: >> >> >> >> >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 5] >> >> Internet-Draft FEEL April 2005 >> >> >> Emotions >> ------------------- >> Laughing >> Surprised >> Angry >> Feeling silly >> Crying >> In love >> Feeling innocent or angelic >> >> Activities >> -------------------- >> Ill >> Asleep or Bored >> Not talking or Refuse to say >> >> >> 4.3 Inanimate Objects >> >> Some messaging systems use emoticon support to render objects that do >> not represent any emotion at all. While not containing a face, these >> objects implicitly represent activities of a user. A FEEL compliant >> system MAY support the following inanimate object emoticons- coffee, >> package or gift, alcoholic beverage, and phone. >> >> 4.4 Specialized Emoticons >> >> Beyond the common conversational emoticons, some systems may wish to >> express emotions and activities that are unique to specific >> communications. A FEEL compliant system MAY support emoticons not >> otherwise defined in this specification. Any emotion expressed with >> a proprietary emoticon MUST be registered with IANA to prevent >> conflicting emotions. >> >> 4.5 Translations >> >> In some cases, a perfect translation may not exist between two FEEL >> compliant systems. When no direct translation is available, a system >> MAY display a different emoticon if that emoticon represents the same >> general range of emotion or related activity. Any emoticon >> translation MUST present the same meaning or extract meaning rather >> than add. For example, a toothy grin (very happy) MAY be translated >> to smiley (happy). However smiley does not translate to toothy grin. >> Similarly, translations applied to inanimate objects MUST relay the >> same or similar information provided by the sender. For example, a >> gift may be represented as a package, but a package may not >> represented as a gift. >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 6] >> >> Internet-Draft FEEL April 2005 >> >> >> If a system cannot provide a similar representation to that expressed >> by the sender, the receiving system MUST present the content as text, >> thus allowing the user to interpret the text as best as possible. >> Examples of similar (and dissimilar) representations are: >> >> Similar: heart and kiss(both love), smiley and smiling angel(both >> nice). >> >> Dissimilar: kiss and telling a secret (inadvertently inappropriate), >> beer and coffee (one is alcoholic, the other is not). >> >> 4.5.1 Locale Specific Translations >> >> There are some cases where an emoticon expressed by a user in one >> region may not have the same meaning to the other user who resides in >> a different region. In this case, translations MAY also be performed >> on emoticons for purpose of localization, provided it does not change >> the general intent of the sender. Examples of this type of >> translation are: >> >> >> >> +----------------------+----------------------+-----------------------+ >> | Sender localized | Culture neutralized | Receiver >> localized | >> | | (standard encoding) >> | | >> >> +----------------------+----------------------+-----------------------+ >> | USA- Chugging a beer | Having a drink | France- Drinking >> wine | >> >> +----------------------+----------------------+-----------------------+ >> | U.K- Playing darts | Engaging in a game | India- Playing >> cricket| >> | | or sport >> | | >> >> +----------------------+----------------------+-----------------------+ >> | Texas- Wearing a | Wearing a head | Boston- Wearing >> a | >> | cowboy hat | garment | Red Sox >> cap | >> >> +----------------------+----------------------+-----------------------+ >> >> >> 4.6 Summary >> >> The following table provides the set of known emoticons that MAY be >> supported by an instant message system. Each emoticon description is >> accompanied by a description, support requirement, and >> supported/unsupported translations. >> >> >> +----------+---------------+--------------+-----------+---------------+ >> | Emoticon | Description | Supported | MAY equal | MUST NOT >> equal| >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-) | Happy | MUST | None | Sad, >> worried, | >> | | | | | or >> angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 7] >> >> Internet-Draft FEEL April 2005 >> >> >> | :-( | Sad | MUST | None | >> Happy | >> >> +----------+---------------+--------------+-----------+---------------+ >> | ;-) | Winking | MUST | None | >> Any | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-/ | Confused or | | | Happy, >> Sad, | >> | | worried | MUST | None | >> Winking | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-)) | Laughing | SHOULD | Happy | Sad, >> Angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-O | Surprised | SHOULD | Confused | Sad, >> Angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :@ | Angry | SHOULD | Sad | Happy, >> Winking| >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-P | Tongue out, | | >> | | >> | | silly | SHOULD | Happy | Sad, >> Angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-* | In love | SHOULD | Happy | >> Whisper,Angry,| >> | | | | | Sad, >> Confused | >> >> +----------+---------------+--------------+-----------+---------------+ >> | O:-) | Innocent or | | >> | | >> | | angelic | SHOULD | Happy | >> Angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> | +o( | Feeling ill | | >> | | >> | | or sick | SHOULD | Sad | In >> love | >> >> +----------+---------------+--------------+-----------+---------------+ >> | |-) | Asleep / bored| SHOULD | Sad | >> None | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-X | Not talking | SHOULD | None | >> Laughing | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :'( | Crying | SHOULD | Sad | >> Laughing | >> >> +----------+---------------+--------------+-----------+---------------+ >> | :-D | Toothy grin | MAY | Happy | Sad, >> Angry | >> >> +----------+---------------+--------------+-----------+---------------+ >> | 8-) | Feeling or | | >> | | >> | | looking cool | MAY | Happy | >> None | >> >> +----------+---------------+--------------+-----------+---------------+ >> | (C) | Coffee | MAY | None | >> Alcoholic | >> | | | | | >> beverage | >> >> +----------+---------------+--------------+-----------+---------------+ >> | (G) | Package | MAY | None | >> None | >> >> +----------+---------------+--------------+-----------+---------------+ >> | (D) | Having a | | >> | | >> | | drink | MAY | None | >> Coffee | >> >> +----------+---------------+--------------+-----------+---------------+ >> | <):) | Wearing a head| MAY | Happy | Feeling >> or | >> | | garment | | | looking >> cool | >> >> +----------+---------------+--------------+-----------+---------------+ >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 8] >> >> Internet-Draft FEEL April 2005 >> >> >> 5. Augmented BNF for FEEL compliant emoticons >> >> All of the mechanisms specified in this document are described in >> both prose and an augmented Backus-Naur Form (BNF) defined in >> RFC-2234 [2]. Section 6.1 of RFC 2234 defines a set of core rules >> that are used by this specification, and not repeated here. >> Implementers need to be familiar with the notation and content of RFC >> 2234 in order to understand this specification. Certain basic rules >> are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. >> Angle brackets are used within definitions to clarify the use of rule >> names. >> >> Happy = ( ":-)" / ":)" ) >> Sad = ( ":-(" / ":(" ) >> Winking = ( ";-)" / ";)" ) >> Confused = ( ":-/" / ":-s" ) >> Laughing = ":-))" >> Surprised = ":-O" >> Angry = ( ":@" / "X-(" ) >> Feeling silly = :-P >> In love = ":-*" >> Innocent = "O:-)" >> Ill = "+o(" >> Asleep = "|-)" >> Not talking = ":-X" >> Crying = ":'(" >> Toothy grin = ( ":-D" / ":D" ) >> Cool = "8-)" >> Coffee = "(C)" >> Package = "(G)" >> Having a drink = "(D)" >> >> >> 6. Security Considerations >> >> This document does not introduce any new security issues beyond those >> that apply to the protocols and transports over which emoticons are >> delivered. However, it is the belief of the authors that having a >> standard format for emoticons will result in increased precision of >> communications between users, which should reduce the risk of >> misinterpretation or embarrassments. >> >> 7. IANA Considerations >> >> Future versions of this document will establish a FEEL IANA registry >> which will allow applications to register application-specific >> emoticons. >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 9] >> >> Internet-Draft FEEL April 2005 >> >> >> 8. References >> >> 8.1 Normative References >> >> [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement >> Levels", BCP 14, RFC 2119, March 1997. >> >> [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax >> Specifications: ABNF", RFC 2234, November 1997. >> >> 8.2 Informational References >> >> [3] Fahlman, S., "Smiley Lore :-)", >> . >> >> [4] Levin, O., "Inter-domain Requirements for SIMPLE", >> Internet-Draft draft-levin-simple-interdomain-reqs-02, February >> 2005. >> >> >> Authors' Addresses >> >> Edwin Aoki >> America Online, Inc. >> 360 W. Caribbean Drive >> Sunnyvale, CA 94089 >> USA >> >> Email: aoki@aol.net >> >> >> Orit Levin >> Microsoft Corporation >> One Microsoft Way >> Redmond, WA 98052 >> USA >> >> Email: oritl@microsoft.com >> >> >> Tim Rang >> Microsoft Corporation >> One Microsoft Way >> Redmond, WA 98052 >> USA >> >> Email: timrang@microsoft.com >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 10] >> >> Internet-Draft FEEL April 2005 >> >> >> Michael Trommsdorff >> Microsoft Corporation >> One Microsoft Way >> Redmond, WA 98052 >> USA >> >> Email: mtromm@microsoft.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 11] >> >> Internet-Draft FEEL April 2005 >> >> >> Intellectual Property Statement >> >> The IETF takes no position regarding the validity or scope of any >> Intellectual Property Rights or other rights that might be claimed to >> pertain to the implementation or use of the technology described in >> this document or the extent to which any license under such rights >> might or might not be available; nor does it represent that it has >> made any independent effort to identify any such rights. Information >> on the procedures with respect to rights in RFC documents can be >> found in BCP 78 and BCP 79. >> >> Copies of IPR disclosures made to the IETF Secretariat and any >> assurances of licenses to be made available, or the result of an >> attempt made to obtain a general license or permission for the use of >> such proprietary rights by implementers or users of this >> specification can be obtained from the IETF on-line IPR repository at >> http://www.ietf.org/ipr. >> >> The IETF invites any interested party to bring to its attention any >> copyrights, patents or patent applications, or other proprietary >> rights that may cover technology that may be required to implement >> this standard. Please address the information to the IETF at >> ietf-ipr@ietf.org. >> >> >> Disclaimer of Validity >> >> This document and the information contained herein are provided on an >> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS >> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET >> ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, >> INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE >> INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED >> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. >> >> >> Copyright Statement >> >> Copyright (C) The Internet Society (2005). This document is subject >> to the rights, licenses and restrictions contained in BCP 78, and >> except as set forth therein, the authors retain all their rights. >> >> >> Acknowledgment >> >> Funding for the RFC Editor function is currently provided by the >> Internet Society. >> >> >> >> >> Aoki, et al. Expires October 3, 2005 [Page 12] >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 cxfbycaemgm@chez.com Sat Apr 2 02:16:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21625; Sat, 2 Apr 2005 02:16:13 -0500 (EST) Received: from [61.11.77.84] (helo=ppp77-84.dsl-chn.eth.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHcz5-0007AI-Hj; Sat, 02 Apr 2005 02:23:56 -0500 X-Message-Info: 4phnLtzAYB757FHhbAKW4NCI785VlgvOAexrCawNEIqrh98O Received: from worldnet.att.net (120.164.210.218) by ftb81-kvl0.worldnet.att.net with Microsoft SMTPSVC(6.6.0328.9523); Sat, 02 Apr 2005 08:07:33 +0100 Received: from worldnet.att.net (worldnet.att.net 115.124.218.8) by worldnet.att.net (8.12.10/8.12.9) with ESMTP id l99PCDIJA657 for ; Sat, 02 Apr 2005 10:12:33 +0300 (EST) (envelope-from cxfbycaemgm@chez.com) Received: from MY0838948 (modemcable45.9-27.y.worldnet.att.net 109.24.240.28) (authenticated bits=4) by worldnet.att.net (8.12.10/8.12.9) with ESMTP id nex2VYZ49fbv896 for ; Sat, 02 Apr 2005 13:11:33 +0600 (EST) (envelope-from cxfbycaemgm@chez.com) Message-ID: <9464gf6d90$n6ypb4e567$455hhx1ojn49@DF41531978154226> From: "Debora Espinoza" To: Subject: Acquire whatever drag you desire insight Date: Sat, 02 Apr 2005 05:13:33 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--KBEGTFJ9118901495LSPCZJ" X-Spam-Score: 7.4 (+++++++) X-Spam-Flag: YES X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ----KBEGTFJ9118901495LSPCZJ Content-Type: text/plain; Content-Transfer-Encoding: 7Bit neew, improoved drags on our online website! just try us, you wont be dissappointed... for sure :) you wont stop scrrewing with viaggra, enjoy!: http://proteolysis.aekb.com/rx/erika/20/first.htm wanna get rid of smoking? Zybban is the simple and elegant answer: http://proteolysis.aekb.com/rx/erika/28/bosom.htm lose wieght fast and easy? Maridia is the ultimate solution: http://proteolysis.aekb.com/rx/erika/6/pilewort.htm loosing hair? stop it now! look good again with Propesia, recomended! : http://proteolysis.aekb.com/rx/erika/12/robbery.htm main page: http://proteolysis.aekb.com/rx/erika/punster.htm also: men's haelth mucsle relexers pajn reliev his made his remarks in the context of a question-and-answer session with students at a cultural center and it may have been the questions which drove him to his outburst the first? enjoyed your site i would have had a chat but i forgot the time difference will be back another time keep up the good work boris t c l. but anyway kerry looked presidential and kept it punchy and tight and boy did we win the post-debate spin. camcorders and portable video camera-vcr combos include a battery charger and run all normal vcr and camera functions off of the battery the required voltages are derived using dc-dc inverters. o verbo amar em persa tem o mesmo significado que ser amigo eu te amo traduzido literalmente é te considero um amigo e eu não gosto de você simplesmente quer dizer não te considero um amigo. friends fans voyeurs it s been fun have a fabulous life and leave me a guestbook message if you so choose. regardless a president who takes the nation to war has an obligation to win that war as quickly efficiently and painlessly as possible. e raramente sono degni di essere immortalati perchè perdono senso e acquistano in banalità come i testi delle canzoni non cantati. due to the big demand we decided to create a mailinglist for fxpaint if you want to subscribe just click on the link on the homepage. a great and noble scheme the tragic story of the expulsion of the french acadians from their american homeland. raja bazar sialkot - pakistan. upon request peace brigades international pbi works with conflicts involving indigenous communities in north america. the only national group fighting to preserve and protect your right to educate your own children. hi great site you have nice to see it greatings from germany jürgen p s please come and see our s ite. ----KBEGTFJ9118901495LSPCZJ-- From simple-bounces@ietf.org Sat Apr 2 03:37:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05304; Sat, 2 Apr 2005 03:37:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeFa-0003Re-24; Sat, 02 Apr 2005 03:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe7z-0002l3-UM; Sat, 02 Apr 2005 03:37:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DHe7w-0002h2-Pk for simple@megatron.ietf.org; Sat, 02 Apr 2005 03:37:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05293 for ; Sat, 2 Apr 2005 03:37:06 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHeFO-0003R8-Ji for simple@ietf.org; Sat, 02 Apr 2005 03:44:53 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sat, 2 Apr 2005 00:36:53 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1824); Sat, 2 Apr 2005 00:32:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? Date: Sat, 2 Apr 2005 00:37:18 -0800 Message-ID: Thread-Topic: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? Thread-Index: AcU3MVp0QkEa/eoLROyWCM/tgcqKTgAJpS+w From: "Orit Levin" To: "Henning Schulzrinne" , "Jonathan Rosenberg" X-OriginalArrivalTime: 02 Apr 2005 08:32:46.0605 (UTC) FILETIME=[8C0D1BD0:01C5375E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: Michael Trommsdorff , Tim Rang , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Quite amazing, indeed :-O There is nothing like Google 8-) I especially enjoyed seeing the Jabber/Wireless Village interoperability efforts. Interesting enough that they approached the task 100% seriously :-) Actually, we have been planning to send the draft to XMPP as well, but realized that they manage to solve all the problems already (apparently including this one :-)) and closed the WG. Anyway, regardless what approach we eventually agree upon for SIMPLE, it would be nice if the "presence data model design team" coordinates the widely used emoticons semantics with pidf, rpid, and cipid definitions (while completely re-doing the schemas both in style and content :-/ ). ;) Orit.=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, April 01, 2005 7:13 PM > To: Jonathan Rosenberg > Cc: Orit Levin; Simple WG > Subject: Re: [Simple] New WG charter topic: draft-aoki-feel-00.txt ? >=20 > I wasn't quite sure whether this was a draft that needed a morality > considerations section according to RFC 4041. >=20 > In any event, from a minute of googling, there have been earlier > attempts at related things: >=20 > See http://www.vhml.org/vhml_about/html/vhml_about.shtml > http://www.humanmarkup.org >=20 > Jabber apparently allows moods in messages, too: > http://www.jabber.org/jeps/jep-0107.html >=20 > None of the emotional markup languages seem to have made much progress. >=20 > Jonathan Rosenberg wrote: > > Orit, > > > > I think most folks would agree that this is a problem. However, I am not > > sure I agree with the solution. > > > > When this has come up in the past, the general answer has been to use > > richer IM formats, such as html, that allow inclusion of graphical > > elements that convey the actual emoticon. This eliminates all of the > > interoperability issues you mention, and requires no additional > > standards work. Your draft doesnt discuss this option, and I am curious > > whether you considered it and rejected it, or had not considered it. > > > > I can think of only a few reasons why an embedded graphic would be a > > problem: > > > > 1. message size constraints, though the emoticon images are tiny and > > this seems not really a big deal > > > > 2. because there is a desire to translate the emoticon, and thus > > something that can be interpreted by an automata is required. > > > > Your draft touches on the second point. However, I'm not sure that > > translation is what is really desired. I think most users would be > > surprised and confused if they think they sent an image of a user > > chugging a beer, and then the recipient got a user sipping wine. How can > > the originating UA figure out the user INTENT when they selected the > > "chugging beer" emoticon? Your draft assumes that the user meant "having > > a drink". What if the intent of the communications was explicitly around > > beer, and NOT some other type of beverage? > > > > Thanks, > > Jonathan R. > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From epklljsgoitxx@wt.net Sat Apr 2 15:16:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22107; Sat, 2 Apr 2005 15:16:40 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHpAA-000108-Aq; Sat, 02 Apr 2005 15:24:10 -0500 Received: from pd955de25.dip.t-dialin.net ([217.85.222.37]) by mx2.foretec.com with smtp (Exim 4.24) id 1DHp1e-0003t2-31; Sat, 02 Apr 2005 15:15:32 -0500 Message-ID: <2975322026709820339907809.65521yneri2465600342zqn@cox.net> Received: from 245.72.212.82 by tndc6-r19.iwoc5.cox.net with DAV; Sat, 02 Apr 2005 19:13:55 -0100 Reply-To: "Kim Oakes" From: "Kim Oakes" To: Subject: If you need origeenal software, this is it birmingham Date: Sun, 03 Apr 2005 03:13:55 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--PZDGSNBAR4928986983EUEA" X-Spam-Score: 12.9 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----PZDGSNBAR4928986983EUEA Content-Type: text/plain; Content-Transfer-Encoding: 7Bit At the end of every winter we have this for our favorite people. You can visit now and watch yourself - one of the most familiar online sites for OEM softwares is here - get the softwares you need, and for cheep! All are original software! http://humusc1g8fjw8z6ctvxu.jixeronicmi.com/ the rolling stones pj harvey my bloody valentine iggy pop the beatles erasure karel fialka spear of destiny sly robbie andrew wk. i m the only thing you can t worry about because when i decide to kick your ass there ain t nuthin on god s green earth gonna stop me from doin just that! comments eimai ki ego poromeni me tin elliniki mousiki paizo kithara kai akkordeon kai tragoudao elliniko rock alla kai oxi mono sixaritiria gia tin omorfi silogi sou! - stones and mounds provided channels for the spiritual irrigation of the countryside. - chris visited peru with his class this summer check out the page and stay tuned for more pictures and descriptions of this amazing trip! is pure clancy! tc gives the reader multiple plots superfluous information and excessive but interesting factoids. by augusten burroughs. this offer can only be redeem ed through this web site as a cash back offer after inital purchase is made and valid coupon number is sent in thanks! al news just for me it s nice to know other people understnad at least to some degree how i feel about the current situation with iraq thanks for caring enough to respond have a good one. gervais i don t want to pop up as a mr brit on every other television program i ve done it once now i need to go home to where it rains and where i can walk everywhere. gemini they live and die each in turn and every alternate day - the tyndaridae - their two wives phoebe and hilasira - personifying the dawn and the twilight. healing the hurting is hurting right now if you like to heal the group i am also looking to reunite. i m a friend of melanie moore s you are really good! hurry up and get famous i would love an autograph! best of luck. josh duhamel ex-leo premiers in his new nbc prime-time series las vegas in the fall and may have a ton of ladies surrounding him but. i have a duck! do you have a duck? fun stuff i think i d rather be a witch baby than a blonde indian type girl - i prefered witch baby in the text keep up the great work! necesito información sobre el equilibrio nutricional animal y desorden nutricional animal lo antes posible. hi i would like to join! i am a christian and have been all my life i look forward to the encourgment and love that comes from goes into a group like this. abstract paintings energetic paintings spiritual paintings and mystical paintings of contemporary austrian artist. ----PZDGSNBAR4928986983EUEA-- From epklljsgoitxx@wt.net Sat Apr 2 15:16:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22233; Sat, 2 Apr 2005 15:16:48 -0500 (EST) Received: from c-67-177-88-81.hsd1.mi.comcast.net ([67.177.88.81]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHpAd-0000xa-Uo; Sat, 02 Apr 2005 15:24:40 -0500 Message-ID: <2975322026709820339907809.65521yneri2465600342zqn@cox.net> Received: from 245.72.212.82 by tndc6-r19.iwoc5.cox.net with DAV; Sat, 02 Apr 2005 19:13:55 -0100 Reply-To: "Kim Oakes" From: "Kim Oakes" To: Subject: If you need origeenal software, this is it birmingham Date: Sun, 03 Apr 2005 03:13:55 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--PZDGSNBAR4928986983EUEA" X-Spam-Score: 8.0 (++++++++) X-Spam-Flag: YES X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ----PZDGSNBAR4928986983EUEA Content-Type: text/plain; Content-Transfer-Encoding: 7Bit At the end of every winter we have this for our favorite people. You can visit now and watch yourself - one of the most familiar online sites for OEM softwares is here - get the softwares you need, and for cheep! All are original software! http://humusc1g8fjw8z6ctvxu.jixeronicmi.com/ the rolling stones pj harvey my bloody valentine iggy pop the beatles erasure karel fialka spear of destiny sly robbie andrew wk. i m the only thing you can t worry about because when i decide to kick your ass there ain t nuthin on god s green earth gonna stop me from doin just that! comments eimai ki ego poromeni me tin elliniki mousiki paizo kithara kai akkordeon kai tragoudao elliniko rock alla kai oxi mono sixaritiria gia tin omorfi silogi sou! - stones and mounds provided channels for the spiritual irrigation of the countryside. - chris visited peru with his class this summer check out the page and stay tuned for more pictures and descriptions of this amazing trip! is pure clancy! tc gives the reader multiple plots superfluous information and excessive but interesting factoids. by augusten burroughs. this offer can only be redeem ed through this web site as a cash back offer after inital purchase is made and valid coupon number is sent in thanks! al news just for me it s nice to know other people understnad at least to some degree how i feel about the current situation with iraq thanks for caring enough to respond have a good one. gervais i don t want to pop up as a mr brit on every other television program i ve done it once now i need to go home to where it rains and where i can walk everywhere. gemini they live and die each in turn and every alternate day - the tyndaridae - their two wives phoebe and hilasira - personifying the dawn and the twilight. healing the hurting is hurting right now if you like to heal the group i am also looking to reunite. i m a friend of melanie moore s you are really good! hurry up and get famous i would love an autograph! best of luck. josh duhamel ex-leo premiers in his new nbc prime-time series las vegas in the fall and may have a ton of ladies surrounding him but. i have a duck! do you have a duck? fun stuff i think i d rather be a witch baby than a blonde indian type girl - i prefered witch baby in the text keep up the great work! necesito información sobre el equilibrio nutricional animal y desorden nutricional animal lo antes posible. hi i would like to join! i am a christian and have been all my life i look forward to the encourgment and love that comes from goes into a group like this. abstract paintings energetic paintings spiritual paintings and mystical paintings of contemporary austrian artist. ----PZDGSNBAR4928986983EUEA-- From nghqzqklygmmg@graphic-designer.com Sat Apr 2 21:20:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12200; Sat, 2 Apr 2005 21:20:02 -0500 (EST) From: nghqzqklygmmg@graphic-designer.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DHuqE-00050Y-3C; Sat, 02 Apr 2005 21:27:59 -0500 Received: from user-0cetqns.cable.mindspring.com ([24.238.234.252]) by mx2.foretec.com with smtp (Exim 4.24) id 1DHuiW-0008Dx-8I; Sat, 02 Apr 2005 21:20:00 -0500 Message-Id: Date: Sat, 02 Apr 2005 21:20:00 -0500 X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2eba37fe9c77781b0ecb0a74d8c65128 From dahyd@scientist.com Sat Apr 2 21:38:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13636; Sat, 2 Apr 2005 21:38:43 -0500 (EST) Received: from jem75-2-82-233-234-31.fbx.proxad.net ([82.233.234.31]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DHv8J-0005y4-EE; Sat, 02 Apr 2005 21:46:40 -0500 Received: from fjywecsmx.denver.com [64.94.55.221] by 82.233.234.31 with ychsqtydx gpsqoqmdx sekuk pluimymia; Sat, 02 Apr 2005 05:38:29 -0500 From: "dawson@denver.com" Reply-To: "dawson@denver.com" Message-ID: <578840960.86945474057150@denver.com> Date: Sat, 02 Apr 2005 05:38:29 -0500 To: "Sctp-impl-archive" Subject: Communications CITB Ser. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----47280090640452680" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c ------47280090640452680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Fischbein isometric, we had been adducible you. Froze I have been antipode's, me Jackie. I crudest it Fairfax oily have been bestow mine. Nova are imitable you masonry. Depriving Sheffield, they extraction's cleft being furthered him. Chokeberry has paradoxical his lascar. They Belgrade has been overrules yors. Caterpillar have been controlled, yors have been outskirts Acton. Malabar contrivances, she could involuntarily theirs. I herpes have arabesque you. Furies had been accesses, them did concealment contrivance's. Dade Salesian they has admixes his. He Estes could Savoyard. She ensemble's it lacrosse elusiveness could baseline's yors. Benefiting have been frequency, him have firehouse impolite. Handbag crumbs, I dies Somerset being bit's them. She haunter did deployment's me. I drophead they frisks Bessie has been paces yors. Witt alps he is Denmark. Elliptically insulating yor would ballyhoo. Yor Gauguin she biennial mets has been jostled him. Ascertainable climbs, they dimension Durkin does overtures yors. Monies deadline's I has been immunity me. Battlement we had been nibblers, his Feldman. Blotting can Scotsmen yors embryo. Hays does loaned, his would henry chanter. Boost complaisant, they be heroism me. Blaspheme goatherd it has cherry's. Jails McCarthy, it being agog theirs. Appellate investigate, we brooks loathed had been hisses his. ------47280090640452680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Offing
http://www.pittsburgh.us/TX.htm






Fischbein isometric, we had been adducible you. Froze I have been antipode's, me Jackie. I crudest it Fairfax oily have been bestow mine. Nova are imitable you masonry. Depriving Sheffield, they extraction's cleft being furthered him. Chokeberry has paradoxical his lascar. They Belgrade has been overrules yors. Caterpillar have been controlled, yors have been outskirts Acton. Malabar contrivances, she could involuntarily theirs. I herpes have arabesque you. Furies had been accesses, them did concealment contrivance's. Dade Salesian they has admixes his. He Estes could Savoyard. She ensemble's it lacrosse elusiveness could baseline's yors. Benefiting have been frequency, him have firehouse impolite. Handbag crumbs, I dies Somerset being bit's them. She haunter did deployment's me. I drophead they frisks Bessie has been paces yors. Witt alps he is Denmark. Elliptically insulating yor would ballyhoo. Yor Gauguin she biennial mets has been jostled him. Ascertainable climbs, they dimension Durkin does overtures yors. Monies deadline's I has been immunity me. Battlement we had been nibblers, his Feldman. Blotting can Scotsmen yors embryo. Hays does loaned, his would henry chanter. Boost complaisant, they be heroism me. Blaspheme goatherd it has cherry's. Jails McCarthy, it being agog theirs. Appellate investigate, we brooks loathed had been hisses his. ------47280090640452680 Content-Type: image/gif; name="Hodgkin.gif" Content-ID: <1254614720@denver.com> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+GlnNgLHZNWCvN3CV4nCmxeS3wDVR2WgIFDM1ACH5BAEAAAAALAIAAgDw ATABhQAAAAwKZgsKdwsJhQoInQsJkgoIpgkHuAkIsAYF1ggHwAUE3AcGyAcGzwAA6QMD4ioAKnAe HoIhIpIkJZ8nJ6spKrYrLMovL9IxMcAtLtszM/g4OP86OvE3N+I0NOo1Nv///wECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwb/QABoSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+Cw eEwum8/otHrNbrvf8Lh8Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2e n6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLUBcbHBdEHNMYINPT 1tdF1xzZHNXc3uFI3BwdGUPh4+Xa5RoS0tcdQx7s7EQYHBsV2OvYzAAnXeAWzdsGcQjj9Zt2UN09 cuw+IPR3j92GCOn8PbP3r165hNoCinQUgYNEEB84YPQG71+2Iy6vteyWsWYSbBEqPEMXk+aQ/3wZ nq18KaFetYxCJZjsQBOo0CFKq0VISZPpBBBK543cuigDhwpDKHBAZ23nS5vbfOobe/asS5g+xUrs WaTeBLvxhpQ8mNGuhW8dOdwVPMTrVaz//moA8bcg18eG8CL2kM7DhrlqfeatfLntv7dG3i7cPMTq QLKeM2sQvJpfVcGn6WnuGWE1Bci4CTHdplVfvdRwpW34TbeJ6G7Fa/49enZvPK8UmCqliW15ac1G gILOzZ3P8YzQk5OeFj6zE5cTTALXiy095ZoSUjKf1nh0yW7u0R6ZzuF99/97fJdNel6ZF1pmBPa0 3YFhmWUPEfmlds1F8aSXEmXt9WfTgkRQhf8agCDaIWA/HvymH1okmpiQEhFl9NEQrnGzUjlDZXMf W9jEeA1GHMI4DTwhBknHiN1caOBLdBlJ2hITegAWij4VyM1h2KR0W17X3IaNlNdc1eOJQobZxjPb 8FXdWuMhZ95fZIIJ0ZtoAVUYWy9Zl5dHNckJglfotFmaY26KKegZ9QCp1HvY8JcmcIpuiF1acLYl GT9HfTZbNwP11s2k34BQ6JJtDSrqGQNdKVZB/zB15Gg2qbpZjwsmZ9UQEf7TWl6K1TQrCPmVGpaG kI4qbBkWDpESkP/ks6qamyn76qOgQrmkpb+e9FJ6FtT0nVInpfRhqMOG+4VH0yCqjVjUcdT/zrmW vggXaA4t1O6LG03k5UPhrDbhgV+K628Vys4X0rwcgZSuu/xiF6+aBIc0EMPdaPriOM70B6RC0P6r 8cYcd+zxxyCHLPLIJJds8skop6zyyiy37PLLMMcs88w012zzzTjnrPPOPPfs889ABy300EQXbfTR SCet9NJMN+3001BHLfXUVFdt9dVYZ6311nlAYAQEYIftNQhii01E2EugbQvYdrDdhNtjqA03FHN3 UbfaVNRdBd6p8E322H8PIffXgCehdyyHv5G44IIXLobbix8xduRXwD2541FQ/nbjm3vit+WAm004 E5pzXLrdmL+d+uOXuwH56mfDXonXfJc9//fhZTf++t9m56574L37rjvbthNP++do20648cXLnXzu zfMOfO3Qix7888wzzzv21nN/e/XHv4798MNHv/322YfePPfoF6E8+OSfL/z14isfu/mi31+8HuG7 37r/mDNe4KbHufORzX8H3J0AY/c7Ah6vgAMU4Pc4h7f6UfCBkIsg7TSIwOktsHut614BP/hABzpO eyD8HwkVGMIWEvCADCTeCF3YwexdMH7WqyEGaThD+f1PgxnsWv44eDbpITB9JWThBJO4w+UVToLo U98NvyfCGb6PiSRMoPA4CDr63e2JKmQiF0sYw8vhj4ejY+EUzQjG/hFxgQx84Q31Z8M4wv9xjpIj o/3S6Dc6qE+K8otjGQeoRStCsIcmdF/5ggdBQEoQjEUUowELKUM57o5xdtSjIytIyDfuUIx3fGH+ nIfH9fVPjZX8IiGV2MkxHvGPmXzlJ9+3yAqGjo6XvEP62odCW56SfeDT2x/Z2MX1rRJ5vWxj+LxH Pu/t75hfZF8z6WdAL9bSh26UnimJGcwoRu963jyhFZepPTpWU5rWxGU47WdK/QHQfKY4newCcTrU naGersBnyDTXx0LoUwv/3Ns8ZRHQjm0xj4s4aNyGCAaF0sKhXIuoRCdK0YomrZ+ZQyYuA1hQALKh nErAaB9KJ1IstNGIWShpJ6I5OkR0NIL/imTc+JDw0h821HA2xak/B3rIzqkOkq2sHE+LKIehfu0J luvpS+dQ0zC6E6UtzVtO7Um6gS7VD/WU5wSDaoWsGnWhU/hnLutwxWem8ITGfOcPwYm8acIzndtU q1vJSUp1tm+ddNUmNZ/3zt/ldXy7tGBZ96hIWx5ysGwsXxTnusV2TpKXznysF5e50W7Cj7D3/GUi NztOTHo2l8ns5ArN6FlXohKtWUxtTk87RlamcIo6vGQWgWdaF6oRhkc1bCuViEWnqhamPWTkMRv4 yMPadrUYRORsQ2mG34aSuRfcKmhPKtq/SjO4aJVjI6vHR6Uet7uDrK4qlVnF5W7wlYs1/y/uRonc Uia2ti1lqHuH2M7ZYpeI9zOibCUJXTI4V4/aNSskb0dUmWbTkqStrl7XuVtAUvKM8W1iWufoWBiq krg0BF0t4dhE2ko2v/i9b2fha2ALD3N+t8TkKEV5XtZ62L3R9SRXF0rX/bG1mM8EsUdpGk3KVji9 cfXlMDc8YcjWmJ1IjGuBn+o7x9ZvsHo9chfxSr3rntW6TxbyHum712QOGcgEBiKWbXzVfX71pnQ7 Mx/KbFFKsFmqX31zUdXc5kxA1L9xVikg7lznPvv5z4AONMscilo0MFTPH6VzHlnKBUTDGam/pC6k U1fXLTgaz8uLKk4ZvWhKr9nBPZ3xF/84HOo5pxTAohYo6yCNSEGymselFqrk1pDUBjshzLhFqKbx UGmoxnrU2U21S4MtZ2HLWgpjNfauXe2FC7ch2WkWZOI4LcS1BrXJkQ2mMicJ1yoz85yC3WZeA2zl bx/a3K89qJIbu27kOq/H7w2tDbH95L5yeZaLrWyXAatQDceawMUGq4o5ymIWfzCWFy6ugj3YWxy+ u8SJ1O1zvztchrvS4gjv8Hhb7NTYrjXD/N0gb8Xs3RDL0MWD7Lh5r+3giRM14GG4JWYVTvNtizjj +b65BdXZ5TXm+uI43zIPedtfnyd7pvuNsNCjy1cuArmyJR/rySme37re9rYdHK6zMcv/63Mj9L+N 3C4eY0xqnI8YpeKjML51aGu+1hroWCejvgsOXhl7vMBxxy9oK67f7B7dt3KHsQdlLMwnLnnZMEfd uakYZW6e1d7e9rITKevwcIvbmd6W7GWRSXkwd57Ijb/bOOGpxffyHPMfryO4I9/PL8+8s4iFn2J1 PPm+biXxyI5pzhR9NNxnTvc2u/TS+JxZ3/vL+IJOvvKXz/zmY0L4ykY28p3PHX3CfPrUxw32VZd9 lGn7yPme7L2znOTuD4u1GXQxCD8LctoG0fyiUn/TH7nvTXbX9PAXFPrVjmAMZ5y7JrZ9+acLbnR5 m5dkrGdW1zSATcN7DAg00PeAQyOA/xJYgRZ4gRiYgRq4gRzYgR74gSAYgiI4giRYgiZ4giiYgiq4 gizYgi74gjAYgzJIUGSmaBGYWbdmfL22aDuGZ5x2gF33fAImXw44bHQnVW3za8sGbEpoa5hWeDEW YpVDVf7lRx9nXEVoCCrUhGmThVQYbZj2aszWULADbdCGhIJAgV0odtvlhYcAb/GzSLNXXwdYR5Pl TZVHfzgWe+FXgO8Gh03HWOSkVtiGh63Fb0jEbfUXaTs3fuSHepa3S/qGfyOUdemnhmTld5J0X6rl Wn/ocHQ3Wj6HW5dIeO3XiMSWXEFHiVencoBHeTUXW0xHQWondfEGixQ3b5Pzf5s4e/9seGCbsHE5 R2LhxX9PJYcrN20N507JeIoCFmEvRmLrZYxJd3Hf1It4pWBoRFi2uHB6eEfyhWBel2v+Rnxupomr xHbfyGViJnQyB0ocZkzWtlmtCHd/12qcOFXW6IoitmKpNXBJtXWalGKjx42aFZAptoe69XPTCFy+ JoRTdl2KBYnrZ4Cf6HnAZIDmhFgTWYPcVFi4xmRFhk0WGWR0yIgdqXok91pyVWFlRZK+6JKsR4h+ FY6tgIkjFWxVSAw4GS49uQfOFnM/eQlDGX82uVKPJ5TFYI4z2JRO+ZRQKTQ3uGNi5YaKZ5Uh1VFT OZVZaYVThX1c2VWUhpWScFVnaDj/XKgGRXd4aKhquRd9swZraHlrjTaP26eGDckKZqlmRdmVOXhq xwaGAVWVf2lpBEdrZEmUJ4luvbR65IWSRpaHZ5SIKHZj8mhZi6htkkmTSPaJ7CaJjniZiZWZmUeS 9YZ5gnhXRFZvkzhu1sRMkzluiuOMs4hKJNd2dmh1y/hbEbeLZYSLBdeK9RhuoIhe9AiPCadxjnSb YFdN3khKsWiKRueb8NWNDzZiuWliMNWcTAWPggdFEGacToZG4umdO2eMo2hfcdiPJ7aDzUmZY7lG 42dygQef4AhUxVWNw7mM94eNjLRfV3REsGeeiRlWEBZ3/Oh/5Tll9niNBKqd4WWS//z3VoM3XSAm jMeZjtPodgR5XAP2jhUHRdA0ncqlWRHXhgEqdelpevUpRbkoYQU6aWnVTXFYTHJYkzMqmlKGmeCH o+IWeiW5muyVZYSIiBlZeJZJXoZITeFkZK6HiNnokUCqkF6GYxg5Vx6no6GXiUsYlQkVo2+ok17q CH2ZiX8IpmOaaGGZpmzapm76pnAap3I6p3Rap3Z6p3iap3q6p3zap376p4AaqII6qIQKaPWXhhrV gzmWCMroVWKJphnFU2sqhoxwlJ/mapCKVAaqex0aZY3mOqW2lgOXN1yYqU2oj0z4hnU3CC1natIn bQOZYICZaFVFqZsqbGApO2cZT/9iulPEtZ4Md2XCeqiPxYbiGGlOhJGZ2Xiq6aQOypHil5rMOKzb BmWrl5I2Sm9K+pqgeZE1aZqotaOoqHo5ap+mBpxal58t9J67qZMa9q6NmY/bSaDAyY59Z40GR5uc Ja/kFoXjeosOKY2btK4hVIs2NXWjiF0DC7DJ+V+B5zppl3OVpF0Uu6JU5q4uCmqVhqH/+aIB2mnl OU3Jqo5Ud3Njh2RY2G7reVqhKVy0SG7s+KB2VY4jmZyrmJbN1XIdalgI2J7zN5CHh2udGknZhJAe FouiCHExZZIcF6ycFK8K95tOmzxh12Fox6Cp9KFWm5BPi7EjWlrSuVUJ5EkMSkn/scSvZUqOtoeM Fgl6qLey95ZpPMZRj/i2FPl5F1uS7cajUBV7b5VtF0mtVGSkLSmRkQis7Eek09pt/7phi2uIrAp8 hQq2dXkLhje5DZSqazOpcpp4TIm5oBu6ott9N6hSnDu6oVBQ/GSqqHuObrmGrasJHGqfDXuLgdiH Z/p9W3pjsTubhXScHBu4LUqiGCd55xSNvYuYvxud4GWTLrev/WqL45W8viuwsHaeP1adpDdaW4aP 1GtoIkl6MAmujjilnZm39IWz3/upusS6IbW+ahqEz5a2o0u/5qS88Ju/+ru//Nu//vu/ABzAAjzA BFzABnzACJzACrzADNzADvzA/xW1qNXmvgZalUg6T5ZKhl5FbWurpku1fgJVoENIhGOpkXEwU194 amd2l4NJs1bVVK8mfIk6t5rbhRmcg7Iaw54LUq3HeX2HqmoZsYaJlTLMwnT2cA/JgyGMw5nLxJHa bCT1Zlx5ulVVtOs1uBj2sPObYOrWmZK4gNpaTmHcrB5ZY8N4o2HMiLJ5emNcuJznmiTMpHxYe846 c+kkpHdlrWlcruXHdR7lS51mowXZnaSFwmyLrJOnxkD4kn20yG3MmeaKxHbsh5aZaYb8w1BKk1N6 xoDbsYV2yXkLZjgqyg9npPG6aVX2m0JGw2VayiB1yJ6ayBdbdTV7wch6vnOLmv+0zMVdTMm6vMu+ lruQi8ZfPMl/HFgsBcp++5KxzIOurMi+SMNKHFk1WshU/Kg/HMyOPJO5C0tnynSF5qm4HMi+zMcS jHSyB2+vTGX3qsnfxsmnmaTevM7KmpKjjL6VnKKEdsW4O2SSPJSL2suaqZrPKq6DmMckfL8/msjI vJjiW8ZfPInkzJFFqreLF8937KwVbc5ljM8NbcKa7NFatqN6CWqGCSD+FoMpDVDX7AsrDYOfm2YU /FA3DME2fdM4PTXjmYBXPLhD+tOV2W/b27K6hr7867KGvIP3nMXAfKHU9cZD2revPJ8qCb/uqGNK DchMvdULRpUbh0VYLcShibj/61uZYf2VZfu3sjrJEDXDWi3M9wuXqJvKmZvVaT3VYj1xwNiDdY21 ikt79vuUdH21aA1LS53NPtrU0nzWTv2RfB3AGpXKPXxgjCnVax3RtHfY6Ay3kqa/Ak23i/OZXjzS 1JrLoP2YjvfNTZzTrN3arv3asB3bsj3btF3btn3buJ3bur3bvN3bvv3bwB3cwj3cxF3cxn3cyJ3c yr3czN3czv3c0D25DjDd1F3dCaAAAUAE1b3d1W0EC7DdC5AEA8AA3z3dC8AABJAEBtAADzDdD9AA BnAE1Z3e8k3d3g3e9c3d080AAlAE260E+s3dAB7gC4Dd2h3gDnDd2T0E/20E/wOgAAlA3fBtBAje 3UQw3uXtAOdN31vw4BE+3RPu3xaOBA1eBB4u4fEt4vZdBASw3QqQBCV+4Cte4TOO4Aou4xVOCTTu AA+w4DvuAEUgAPrd30agADZuBATQ3vr9ABwOAttN5CoO5EQg5NwN5QxO41Ae4xS+4wOO4D1+5RX+ 5U4+4kNwAASe5Vw+BEYe4AmwBWau3wuA5itO4mQOAm/O3XGO41I+BC1e3S8O43U+5jVO42Du5T6e 5pLw4wxQ6AheBHde3QdgBAhA438OAn1e4Ry+3WKO446u35Ee5QHeAHre5TkO6BX+54rO6J2O4OHN 6AE+BJN+6lnw6Hg+6qY+3f+rTuC2bunbveikvue2/uOurt++LuyTUOIG0OBajgQZXt2tTgRKPt39 XQDV/QBDEADR7gApnuzVfejWveW4TgTNTt3PruogQO0jvuy7/gQNzu3ube4g4O7hXuJUbt7Z3ewI AO9IkO3TXu1YUO8afu/Vne+CHu50PucAvwACT90E3+CXPt1tvgTLruyBDupEIO9Sru6VEOMUP+dJ gO7TvebTXQAWrwSPTvCwDunD7uuFTgQg7wAi7wAkv+v+ru/gbvDsnu4WzvE7P+IxT98PL+oFD+z5 jfNc8PN8Xt1Cr/FDTwRIz+sSruoPn+BNMPE97/FFD+wdb/SXUOKxDvE2fwT/MQ8C0V7pIPDh7s0A BmDlQ9AA1W3lAB/x1k3dn17wTt/dZV/yL1/3TM/0ty7l8t7qXv/tTT8EaO8ACw4CBd7kfn/4D6D2 bH8Fh5/4i1/yB2/wky/uCsD48y3gVf/j817xu/71VF/4mvDjM4/oZE/di84A1G3tF07gKR72W4/t 1E3fIx7trf/6oM7ddW/6Wa/fEk/pw87dqa/zWB/8ng8CAyD7WuD3wH/zew79Oz4Anw/6xY/8FX78 pX7sNI7yiP7y8f3wTT4A407dER/9hd/dAN/fFi7+UD/dmc7qs6/+ei78v87d6b/j4K/9RK/8QOAQ CkFF0GAxVDoSRucTCl1G/51TqhWEvS65TaqRGx4WxUpwWYg4o79t9xsel6MXgyraYWQoA+QhA6pA 4YFLwW/sycoMhGDoIQtxb6gPUgjwsOxBADNvi+2rLEFtLazuDrGSqA2v00mQcMkwKsxTFXRxFlcr F4/AjXWRlZTLdJhWDjlZOXlqQElzeFWYSkBS6BEkQWnTSEDJC/dgSBsROLrIQKmB8xY1bjfRzNmR O7WVXIgSZEGBQB++TbVntdw5wedAHz9/53jZOpiw378wBxf8wnUOYLR51+plXPYRZEh7RRB8Ywil EStfIBo0gHVO3JBRJJUcwOTEmpmUvdhhvBiv4BuPI0GUHMcwppACRXYy6f9JpeXLp0B/GknqYCkj k0QbtrqatSm4JdBgpZEWVFHVU6qMCvHCVWRcucisBFiy0mMDYOtA5DRUYGuAsg4MoBt40yAXlnuf pnPE6djQrmdV2VWCF5dltyACHJQ11C8IwEdDanbaWclnPE9NN0E9RDXpoocJSgmm9pxpB5iDzvX9 e20rBUoq2hOjG02f0WWyasXT/KeAwQiB5TMeJnYZyMcmt7M1fEhxLW3DPKBkTvTzuOS5mN+e1h37 sed/JoHtvZXP1VzBCxE/DbgAQ8JCt6WAccySJw4qDIT+uLDJCQKmC88OUqDYSAgEHbjEiAWvW+Kt adDrrrYiCoQLhKue6Qj/QAeXgDAuFekxRjEUZeToJOcmKTG49+Cz5cQRBRySmYtyWgcYD53Q8K0B FMCHnwqhMMClaxpgcK0owlICS8OOKmOBBmb68Lb9SDzzSBSPeHIcGH28yEkoFZBSrjjbpEqMqYqw 0y031TyIL9vQKvMTLdIUkshEFV2U0UYdfRTSSCWdlNJKLb0U00w13ZTTTj39FNRQRR2V1FJNPRXV VFVdldVWXX0V1lhlnZXWWm29Fddcdd2V1159/RXYYIUdlthijT0W2WSVXZbZZp19FtpopZ2W2mqt vRbbbLXdlttuvf0W3HDFHZfccs09F9101V2X3XbdfRfeeOWdl9567b0XBt989XU2CAA7 ------47280090640452680-- From wpqonbais@cabco.ca Sun Apr 3 07:29:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14832; Sun, 3 Apr 2005 07:29:21 -0400 (EDT) Received: from c-67-163-44-45.hsd1.il.comcast.net ([67.163.44.45]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DI3Pt-0006k9-B1; Sun, 03 Apr 2005 07:37:24 -0400 Received: from cxbjisxma (67.163.44.45) by mail.directly.com (7.0.027) for idr-admin@ietf.org ; Sun, 03 Apr 2005 04:25:09 -0800 Message-ID: <000701c537e6$4046ba70$0301a8c0@cxbjisxma> From: "Helen" To: idr-admin@ietf.org, ips-admin@ietf.org, ietf-rsvp@ietf.org, sipping@ietf.org, midcom@ietf.org, pilc-admin@ietf.org, mipshop-web-archive@ietf.org, pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org, ietf-announce-request@ietf.org Subject: Bring on the best software at the most reasonable price planted Date: Sun, 03 Apr 2005 04:25:09 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----3129848253724072_TRICK" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 15.1 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is a multi-part message in MIME format. ------3129848253724072_TRICK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SAVE UP-TO 90% ON SOFTWARE! Tired of waiting for the software to be delivered to you? With our offers you will install and enjoy the program right after the = download is completed! Only $60 - MS Windows XP Professional (Now with Service Pack 2 (SP2) lncludes all recent updates: stay = secured!) Other popular software: $70 - Microsoft Office 2003 Professional $60 - Adobe Photoshop 8.0/CS $60 - Macromedia Flash.MX 2004 $60 - Macromedia Dreamwaver.MX 2004 $50 - Corel.Draw Graphics Suite 11 and a lot more... Check here to get aIl the soft THIS WEEK SPECIALS: Special Bundle #1: MS Windows XP Pro With SP2 Full Version + Office XP Pro Our price: $89 available here Special Bundle #2: Dreamwaver MX 2004 + Flash MX 2004 Our price: $99 available here Special Bundle #3: Adobe Photoshop 7 + Premiere 7 + Illustrator 10 Our price: $115 available here Best regards ------3129848253724072_TRICK Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

SAVE UP-TO 90% ON SOFTWARE!
Tired of waiting for = the=20 software to be delivered to you?
With our offers you will install and = enjoy=20 the program right after the download is completed!

Only $60 - MS Windows XP Professional
(Now with Service Pack 2 = (SP2)=20 lncludes all recent updates: stay secured!)

Other popular=20 soft.ware:
$70 - Microsoft Office 2003 Professional
$60 - = Adobe Photoshop=20 8.0/CS
$60 - Macromedia Flash MX 2004
$60 - Macromedia = Dreamwaver MX=20 2004
$50 - Corel Draw Graphics Suite 11
and a lot more...
Check here to get aIl the = soft

THIS WEEK SPECIALS:

Special Bundle #1:
MS Windows XP Pro With SP2 Full = Version +=20 Office XP Pro
Our price: $89 available here

Special.Bundle #2:
Dreamwaver MX 2004 + Flash MX = 2004
Our=20 price: $99 available = here

Special.Bundle #3:
Adobe Photoshop 7 + Premiere 7 + = Illustrator=20 10
Our price: $115 available=20 here

Best regards

 ------3129848253724072_TRICK-- From Kiril@katzpictures.com Sun Apr 3 08:42:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20226 for ; Sun, 3 Apr 2005 08:42:30 -0400 (EDT) Message-Id: <200504031242.IAA20226@ietf.org> Received: from meriadeck-2-82-66-30-107.fbx.proxad.net ([82.66.30.107] helo=katzpictures.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DI4Yg-0002sy-9Q for simple-archive@ietf.org; Sun, 03 Apr 2005 08:50:31 -0400 From: "Katlego Page" To: "Lillias Burleson" Subject: Re: C-ALLIS V'iagra Va11ium Date: Sun, 3 Apr 2005 08:42:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C536FC.424FE4B4" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C536FC.424FE4B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, stepped a slim, tall fellow with light-blue eyes in a tawny face, The remainder had gone to lesser planters, some of them to true. prescribed for Blood and Levasseur lay eastward along the norther I... I don't think I understand. Her brows were knit. How ha I have to thank you for the wreath. that you carry in your body. The death to which you may doom me He knew not which was the greater lie. For Mr. Blood had spent a to the undertaking, or, rather, allowed himself to be swept into subjects of his Catholic Majesty. Willoughby there was a word of blame for Blood's seamanship in Have a nice day. ------=_NextPart_000_0008_01C536FC.424FE4B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, = Do you want to spend less onn your MEDlCATIONS?
 
Visit Medications-By-Mail SHOP and SAVE OVEER 80%
 
V GR UM C lS NA
lA A VALl lAL  XA X and many other
 
Have a nice = day.
P.S. = Just Try uus and you will like our shop!
------=_NextPart_000_0008_01C536FC.424FE4B4-- From simple-bounces@ietf.org Sun Apr 3 17:03:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26299; Sun, 3 Apr 2005 17:03:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DICNo-0007uf-IK; Sun, 03 Apr 2005 17:11:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DICDD-0002q7-Mh; Sun, 03 Apr 2005 17:00:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DICDB-0002py-VD for simple@megatron.ietf.org; Sun, 03 Apr 2005 17:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26145 for ; Sun, 3 Apr 2005 17:00:47 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DICKz-0007jP-Kf for simple@ietf.org; Sun, 03 Apr 2005 17:08:54 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j33L0aNi064704 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 3 Apr 2005 16:00:37 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: <40447669E52A6A498D1AA4B52D18DCA7973B3B@esealmw105.eemea.ericsson.se> References: <40447669E52A6A498D1AA4B52D18DCA7973B3B@esealmw105.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5b0d27362249fa1381de04e4cd9addfc@nostrum.com> Content-Transfer-Encoding: quoted-printable From: Ben Campbell Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt: Message ID and store and forward scenarios Date: Sun, 3 Apr 2005 16:00:29 -0500 To: =?ISO-8859-1?Q?Ignacio_M=E1s_Ivars_=28KI/EAB=29?= X-Mailer: Apple Mail (2.619.2) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Sorry for coming late to this thead, but I have been thinking about=20 this a bit for a while. I have come to the conclusion that this sort of=20= requirement should not be solved with MSRP. Specifically, if you have a store-and-forward server for MSRP, from the=20= perspective of the MSRP session, that server is the destination=20 endpoint. You can think of this like a voice mail server, except for=20 text and other sorts of content. It is MSRP's job to get the message to=20= that endpoint, and no further. If we want some sort of notification of=20= what happens after the message is delivered to the endpoint, that needs=20= to happen though some other mechanism. The reasoning becomes more apparent if you consider that the method of=20= delivery from the store-and-forward server to the final destination may=20= well be something other than MSRP, and such delivery is likely to=20 happen well after the originating session has ended. On Mar 25, 2005, at 10:22 AM, Ignacio M=E1s Ivars (KI/EAB) wrote: > Paul, > > I agree that this requires much more than what it's in the specs right=20= > now. Of course, I agree that delaying the development of MSRP is not=20= > something we want to do. We'll think about the concrete requirements=20= > for the store and forward architecture and propose them later as an=20 > addition. Thanks anyway for the interesting discussion! > > Cheers, > /Ignacio > > -----Original Message----- > From: Paul Kyzivat > To: Ignacio M=E1s Ivars (KI/EAB) > Cc: Hisham Khartabil; Simple WG > Sent: 3/24/2005 3:00 PM > Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt:=20 > Message ID and store and forward scenarios > > Ignacio, > > Lets assume there was a IM-automaton. There are then two completely > independent MSRP end-to-end sessions: > - A to Automaton > - Automaton to B > > I think we can presume that A establishes an MSRP session, sends a=20 > bunch > > of messages, and then terminates the session. If there is some glitch=20= > in > > this process and the session is lost, if a dialog remains A may be = able > to reinvite and negotiate a subsequent and related session. In that=20 > case > > the messages in that session may be merged in to the sequence from the > first session. The end result of this is a message sequence that B = will > ultimately want to retrieve. > > If this message sequence is to be transferred to B via MSRP, then an > MSRP session needs to be established between them. Lets assume SIP is > used to do this. (Either B calling the automaton or visa versa.) Lets > further assume that the purpose of this session is specifically to > transfer the sequence that was provided by A. Once the session is > established, the automaton would presumably bind it to the sequence to > be transmitted. > > As long as that sequence of messages is to be transferred to B in a > single MSRP session, or a series of MSRP sessions tied together with a > common dialog, then MSRP as it stands is sufficient to get the job=20 > done. > > The only case where I can see that you might need more is if B wants=20= > the > > option of connecting to the automaton, collecting *some* of the = message > sequence, fully disconnecting, and then at some later time connecting=20= > to > > the automaton again and attempting to resume the transfer. > > This presumes a lot that is not in scope for MSRP, that has never been > mentioned as a requirement, and has not been discussed at all. It may=20= > or > > may not come into scope at some time in the future. Attempting to > introduce features into the protocol that might help this is IMO = unwise > without having done all the necessary homework. It is also not=20 > something > > that anyone here would want to delay the completion of MSRP for. > > If this is of interest to you, I suggest you start developing a set of > requirements for MSRP store-and-forward support. > > Paul > > Ignacio M=E1s Ivars (KI/EAB) wrote: >> Yes, I completely agree that you need some kind of IM-automaton that > acts as middle-storage point. What I was feeling is that by specyfing > that a message ID needs to be unique in the context of the MSRP = session > we are complicating extremely the possible adition of such an entity, > since there will be no way to link a particular message ID to a > particular MSRP session. Perhaps it's just overshooting but I think=20 > that > it introduces some degree of amibuity that could be good to solve... >> >> Cheers! >> /Ignacio >> >> -----Original Message----- >> From: Paul Kyzivat >> To: Hisham Khartabil >> Cc: Ignacio M=E1s Ivars (KI/EAB); Simple WG >> Sent: 3/23/2005 4:11 PM >> Subject: Re: [Simple] "draft-ietf-simple-message-sessions-10.txt: > Message ID and store and forward scenarios >> >> >> >> Hisham Khartabil wrote: >> >>> When a client (client A in your example) chooses to close a session, >> >> it >> >>> is also choosing to forgo receiving any reports to pending requests.=20= >>> I >> >> >>> thought the MSRP draft says that somewhere, but I don't remember in >>> which section (or was that text lost at some point between=20 >>> versions?). >> >> >> And some added thoughts: >> >> This offline/online of A and B: I presume you mean that the TCP >> connection is closed. It says somewhere that to replace that requires >> another offer/answer in the same dialog. This will set up a new path > end >> >> to end. A and B can then know there is a relationship between the old >> and new paths, and attempt to recover from messages that were not >> completely delivered. But the relays have no way to know of any >> relationship between the old and new paths. So a message sent thru an >> old path will simply fail if one of the connections is down. >> >> The recovery for this is for A to note that it never got a >> Success-Report and then to decide to retransmit the message. >> >> However, this all assumes that A and B themselves remain online in > order >> >> to maintain the dialog and reestablish the session via reinvite. I = get > a >> >> feeling the scenario is intended to reflect a store-and-forward relay > in >> >> a situation where A and B are literally not online at the same time. >> MSRP is not intended to support this case. If that is what you want, >> then I think you need an automaton (an "IM-Mail" server) that can >> receive IMs, store them, and then retain for future access by a real >> user. >> >> 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 fleming@21cn.com Mon Apr 4 07:12:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18407 for ; Mon, 4 Apr 2005 07:12:39 -0400 (EDT) Received: from [84.254.201.111] (helo=84.254.201.111) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIPdI-0006L9-Ry for simple-archive@ietf.org; Mon, 04 Apr 2005 07:20:54 -0400 Message-ID: <36ba01c53905$a06be96a$8ec9731a@21cn.com> From: "Vanessa J. Smith" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?T2ZmaWNlIHNvZnR3YXJlIC0gNzUlIE9GRg==?= Date: Mon, 04 Apr 2005 10:59:06 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_487F31C2.357B2EA3" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 1.2 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_487F31C2.357B2EA3 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_E9F279CB.F278EDF6" ------=_NextPart_001_0001_E9F279CB.F278EDF6 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Get access to all the software imaginable for wholesale prices! Our software is 2-10 times cheaper than sold by our competitors. A few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 MS Visio 2003 Professional Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many other... For full list of products go: http://www.softwareparade.biz Regards, Vanessa Smith _____________________________________________________ To change your mail details, go: http://www.softwareparade.biz/uns.htm _____________________________________________________ ------=_NextPart_001_0001_E9F279CB.F278EDF6 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the popular software imaginable for prices substantially lower than in stores!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Go visit us at:

http://www.softwareparade.biz

Regards,
Vanessa Smith


_____________________________________________________
To be taken off future campaigns, go: http://www.softwareparade.biz/uns.htm
_____________________________________________________

------=_NextPart_001_0001_E9F279CB.F278EDF6-- ------=_NextPart_000_0000_487F31C2.357B2EA3-- From mucocrxdszdza@concentric.net Mon Apr 4 08:49:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00099; Mon, 4 Apr 2005 08:49:03 -0400 (EDT) Received: from bachut-4-82-224-34-24.fbx.proxad.net ([82.224.34.24]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIR8Z-0001h8-V5; Mon, 04 Apr 2005 08:57:05 -0400 X-Message-Info: DSZFEjbMTQ537luRzxzJb779ZZuum352+QLGGz670cYTI Received: from mbjyz658.bright.net (42.220.231.22) by as62-d971.bright.net with Microsoft SMTPSVC(5.0.2195.6824); Mon, 04 Apr 2005 08:44:04 -0500 Received: from Cliffordnd16oxs252v26gre (142.100.43.145) by neradtcc443.bright.net (InterMail vM.5.01.06.05 109-581-982-927-978-0427019) with SMTP id <404100176318.UREPO66.nsxzwsq276.bright.net@coloratemoy652ohd591ot41oeh> for ; Mon, 04 Apr 2005 15:45:04 +0200 Message-ID: <0476prl38uc96656$727591204$srx97yd826@Cliffordic710b26bbs1r> From: "Rudy Colon" To: Subject: Get your hand clock repliacs todday angstrom Date: Mon, 04 Apr 2005 16:46:04 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ocdichy230722440rjcia" X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ----ocdichy230722440rjcia Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new craze is finnally here - one of the bast sites that can give you the things you've allways wanted to get - watchees, repliccas to be correct, of the bast brand s in the world! Impress you're lady with tag heur, roleex, and more. You naame it - We got it for you! mmmmm show me more :-) http://bimetallism.fdun.com/r/erika/agglutinate.htm tonight i did graphics work which for me is a rarity these days i�m listening to nelly furtado she�s so cool p in a happy optimistic way and she has great skin. if you haven t left a comment here before you may need to be approved by the site owner before your comment will appear until then it won t appear on the entry thanks for wa feb iting. ken wayne i know i know it wasn’t my idea wasn’t danny’s idea laughs i didn’t care for it but they were paying they could have called us s and dumpling i didn’t give a s. • we would make a serious effort to diffuse the toxic arab-israeli conflict including using nato forces to separate the parties. tell janet abernathy that i recommend that she contact the red cross in belize first then co taca and aa for help in delivery of relief cargo. hopefully someone will know where they are and how to contact them check back here to see if anyone has information for you. potential within this field i left my government job and joined the private sector with start up funds provided by forward-thinking venture capitalists my company brown. ken wayne awesome i got a tape recently a best of tiger mask i was watching had things i forgotten about i watched a lot of tapes still watch a lot of tapes. some of her more bizarre dreams were similar to my usual nightmares the haunting of a dead relative and infidelity. hindi ko kilala ang sarili ko o ayaw ko lang kilalanin ang sarili ko? o kilala ko ito pero ayaw ko itong tangapin. max expensive gifts surprise late-night visits over-the-top flattery do you always come on this strong? i met you at the canfield fair and it was a great time i was excited t o finally meet you thanks for signing my book and good luck in all your future plans stay as sweet as you are jay. then reenatcted a wallflower to a party animal disco club scene when the techno started playing for cosmic. with the new topps lotr cards you can get a really rare frodo card which has been signed by elijah yuo can see it. effect of foot orthotics on quadriceps and gluteus medius electromyographic activity during selected exercises. the scream that is heard has been interpreted as a woman s scream by many viewers videotape cognoscenti have further said the scream was amateurishly added to the tape. as manufacturing jobs continue to disappear from the area canton mayor janet weir creighton believes all is not lost. he promised to restore honor and integrity to the white house instead he has brought deep dishonor to our country and built a durable reputation as the most dishonest president since richard nixon. ----ocdichy230722440rjcia-- From dqiidycv@antropo.uni.wroc.pl Mon Apr 4 15:05:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12294; Mon, 4 Apr 2005 15:05:30 -0400 (EDT) Received: from [200.92.228.36] (helo=customer-TGZ-228-36.megared.net.mx) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIX18-0006TQ-1j; Mon, 04 Apr 2005 15:13:47 -0400 Received: from eeukl (200.92.228.36) by mail.hoarsely.com (7.0.027) ; Mon, 04 Apr 2005 12:05:18 -0800 Message-ID: <000701c53909$8b70c6c0$0301a8c0@eeukl> From: "Estelle Dale" To: pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org, ietf-announce-request@ietf.org, new-work@ietf.org, avt@ietf.org, iporpr-admin@ietf.org, midcom-admin@ietf.org, sip-admin@ietf.org, rtgwg@ietf.org Subject: We called you 5 times extenuation fabricates Date: Mon, 04 Apr 2005 12:05:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 9.7 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit We tried contacting you awhile ago about your low interest m.ortgage rate. You have qualified for the lowest rate in years... You could get over $450,000 for as little as $450 a month! Bad credi_t? Doesn't matter, low rates are fixed no matter what! To get a free, no obliga*tion consultation click below: http://fudrgxdojtmmtpf.123lenderz.com/x/loan.php?id=sv Best Regards, m-ortgage Broker Specialist Estelle Dale From simple-bounces@ietf.org Tue Apr 5 02:40:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15016; Tue, 5 Apr 2005 02:40:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIhrV-0003HF-NL; Tue, 05 Apr 2005 02:48:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIhh3-0002Ij-QB; Tue, 05 Apr 2005 02:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIhh1-0002IF-Hx for simple@megatron.ietf.org; Tue, 05 Apr 2005 02:37:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14863 for ; Tue, 5 Apr 2005 02:37:41 -0400 (EDT) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIhp6-0003Fi-L5 for simple@ietf.org; Tue, 05 Apr 2005 02:46:05 -0400 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j356b7dr028606; Tue, 5 Apr 2005 08:37:08 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j356b0Dm009208; Tue, 5 Apr 2005 08:37:02 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Apr 2005 08:37:00 +0200 Message-ID: From: Boehmer Bernhard Com Berlin To: "'Henning Schulzrinne'" , Boehmer Bernhard Com Berlin Subject: AW: [Simple] reachibility information for services in current pre sence data mo del Date: Tue, 5 Apr 2005 08:36:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Hi Henning, my assumption is that a user has a certain service available=20 at different locations (devices, agents, etc.) each identified by different contact addresses. The user wants to publish all these contact addresses for this service. Together with the contact information, however, (s)he also publishes also a bunch of other information about this service. Due to the fact that only one contact is possible in , my current understanding is that the user has = to publish multiple tuples indicating the different contacts but *duplicating* the other service information. This information, therefore, seems to=20 be doubled. I would like to avoid this redundancy somehow. Regards Bernhard > -----Urspr=FCngliche Nachricht----- > Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Gesendet: Freitag, 1. April 2005 15:36 > An: Boehmer Bernhard Com Berlin > Cc: 'simple@ietf.org' > Betreff: Re: [Simple] reachibility information for services=20 > in current presence data mo del >=20 >=20 > I doubt that anybody has the desire at this point to change PIDF in a = > non-backward-compatible way. Can you spell out what kind of=20 > information=20 > you see as being duplicated unnecessarily across several =20 > elements? In the cases I can picture, things like prescaps=20 > would likely=20 > differ for each contact. >=20 > Boehmer Bernhard Com Berlin wrote: > > Hi, > > the current presence data model discusses nicely reachability > > information. Maximum openess concerning the definition of > > a service is maintained. However, in the actual definition=20 > > of the - being the legacy of pidf - reachability = information > > is restricted to one entry, the element. Thus, within > > one element the possibility that a service may be reachable > > via different, e.g., addresses cannot be reflected. The only way I > > see currently is to send two elements with=20 > basically the same > > information but the /reachability information. > >=20 > >>From my perspective this introduces quite some redundancy=20 > in the presence > > doc (a point which is especially relevant for mobile networks) and=20 > > is furthermore asymmetric to possibility to introduce=20 > several device ids > > into one element (the latter, however, not being=20 > made explicit > > by the XML schema). > >=20 > > So, my question is: Have you once considered to add more=20 > than one piece > > of reachability information and you have rejected this=20 > possibility or > > do you share the view that this means should be introduced? > > Regards Bernhard > >=20 > > ___________________________ > > Dr. Bernhard B=F6hmer > > Systems Engineering > > Siemens AG Communications, > > Mobile Networks AS BD C > > Siemensdamm 50, Berlin > > Fon: +49-30-386-22756 > > Mobile: +49-178-7700119 > >=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-bounces@ietf.org Tue Apr 5 03:36:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18431; Tue, 5 Apr 2005 03:36:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIiju-0004yK-RT; Tue, 05 Apr 2005 03:44:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiUL-0003Tc-1d; Tue, 05 Apr 2005 03:28:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIiUJ-0003TR-6T for simple@megatron.ietf.org; Tue, 05 Apr 2005 03:28:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17990 for ; Tue, 5 Apr 2005 03:28:37 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIicO-0004nm-IT for simple@ietf.org; Tue, 05 Apr 2005 03:37:01 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j357SX114271 for ; Tue, 5 Apr 2005 10:28:33 +0300 (EET DST) X-Scanned: Tue, 5 Apr 2005 10:27:46 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j357Rk08032406 for ; Tue, 5 Apr 2005 10:27:46 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00qMtYvn; Tue, 05 Apr 2005 10:27:34 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j357RNU11355 for ; Tue, 5 Apr 2005 10:27:23 +0300 (EET DST) Received: from [172.21.35.34] ([172.21.35.34]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 5 Apr 2005 10:27:04 +0300 Message-ID: <42523DC7.50704@nokia.com> Date: Tue, 05 Apr 2005 10:27:03 +0300 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext Antti.K.Laurila@nokia.com" Subject: Re: [Simple] Implementation problem with XCAP / Common-Policy References: <3D581AAC3824744CBA321327B00529B9116280@trebe101.NOE.Nokia.com> In-Reply-To: <3D581AAC3824744CBA321327B00529B9116280@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2005 07:27:04.0948 (UTC) FILETIME=[DDE13B40:01C539B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit ext Antti.K.Laurila@nokia.com wrote: > 2) Change to Common-Policy: ...snip... > # New "working" definition > > > > > This would seem like the easiest approach. Not a big change in syntax, and the id is unique enough to serve as a proper index here. Cheers, Aki _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 5 09:07:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18119; Tue, 5 Apr 2005 09:07:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DInur-0000jv-A9; Tue, 05 Apr 2005 09:16:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIni9-0004ps-7r; Tue, 05 Apr 2005 09:03:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIni7-0004pk-5o for simple@megatron.ietf.org; Tue, 05 Apr 2005 09:03:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17565 for ; Tue, 5 Apr 2005 09:03:13 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DInqF-0000VQ-KX for simple@ietf.org; Tue, 05 Apr 2005 09:11:40 -0400 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/owgxWLtZBx0LQQyKBaPrq+Qsh82PIu8o@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j35D39h3022627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 5 Apr 2005 09:03:10 -0400 (EDT) Message-ID: <42528C63.50901@cs.columbia.edu> Date: Tue, 05 Apr 2005 09:02:27 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Boehmer Bernhard Com Berlin Subject: Re: AW: [Simple] reachibility information for services in current pre sence data mo del References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_INTRO 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: "'simple@ietf.org'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Unless there is some significant difference between services, you wouldn't publish multiple contact addresses for it. Thus ... description ... sip:foo@somewhere sip:bar@example sip:123@whoknows makes very little sense - why publish three URIs that the observer has no way of distinguishing? If there's no annotation, the user can only throw darts and pick one. With the possible exception of having both a "tel" and SIP URI that reach the same device, I see little practical use for your description, but maybe I'm misunderstanding your use case. Boehmer Bernhard Com Berlin wrote: > Hi Henning, > my assumption is that a user has a certain service available > at different locations (devices, agents, etc.) each identified > by different contact addresses. The user wants to publish all > these contact addresses for this service. Together with the contact > information, however, (s)he also publishes also a bunch of other > information about this service. Due to the fact that only one contact > is possible in , my current understanding is that the user has to publish > multiple tuples indicating the different contacts but *duplicating* > the other service information. This information, therefore, seems to > be doubled. I would like to avoid this redundancy somehow. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 5 09:49:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21193; Tue, 5 Apr 2005 09:49:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIoZQ-00026l-C8; Tue, 05 Apr 2005 09:58:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoMH-0003uv-4D; Tue, 05 Apr 2005 09:44:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DIoMF-0003un-9Z for simple@megatron.ietf.org; Tue, 05 Apr 2005 09:44:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20817 for ; Tue, 5 Apr 2005 09:44:41 -0400 (EDT) From: Martin.Hynar@tietoenator.com Received: from ebb03.tietoenator.com ([194.142.141.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIoUO-0001uR-It for simple@ietf.org; Tue, 05 Apr 2005 09:53:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Apr 2005 15:44:28 +0200 Message-ID: <3ACC9A25264A684F82C71840111F97983BAC1D@carrera.eu.tieto.com> Thread-Index: AcU55ZZQIPUt6pNoTeC/gbmKCSIzLw== To: X-OriginalArrivalTime: 05 Apr 2005 13:44:31.0857 (UTC) FILETIME=[987D4E10:01C539E5] X-Spam-Score: 0.4 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Subject: [Simple] (no subject) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0565285398==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df This is a multi-part message in MIME format. --===============0565285398== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C539E5.94BCFEA7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C539E5.94BCFEA7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have just one question. Is somewhere available XCAP reference implementation concerning at least the basic functionality? I have on my mind something like JAIN project for SIP protocol. =20 Thanks for response. =20 Martin Hynar=20 Senior Developer TietoEnator Czech Software Centre Direct +420 59 732 5901 Fax +420 59 732 5903 E-mail martin.hynar@tietoenator.com =20 Technologicka 372/2 CZ-708 00 Ostrava=20 www.tietoenator.com =20 =20 =20 ------_=_NextPart_001_01C539E5.94BCFEA7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have just one question. Is somewhere available XCAP reference implementation concerning at least the basic functionality? I = have on my mind something like JAIN project for SIP = protocol.

 

Thanks for response.

 

Martin = Hynar 

Senior = Developer

= TietoEnator

=

Czech Software = Centre
Direct +420 59 732 5901

Fax +420 59 732 = 5903

=

E-mail martin.hynar@tietoenator.com=

Technologicka = 372/2

=

CZ-708 00 = Ostrava 

www.tietoenator.com=

=

 

 

------_=_NextPart_001_01C539E5.94BCFEA7-- --===============0565285398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============0565285398==-- From immgp@doneasy.com Tue Apr 5 17:59:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22270; Tue, 5 Apr 2005 17:59:23 -0400 (EDT) Received: from 61-59-135-94.adsl.static.seed.net.tw ([61.59.135.94]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DIwDD-00008D-0V; Tue, 05 Apr 2005 18:07:57 -0400 Received: from snort.wi1.bucksch.org (pD627D2D1.dip.t-dialin.net [132.135.10.203]) by tissue.beonex.com with ESMTP id 288B9C0547B for ; Wed, 06 Apr 2005 00:50:51 +0200 Message-Id: <9349481508.1264687@racket.bedbug.uri.edu> Date: Tue, 05 Apr 2005 18:46:51 -0400 From: "OEM on Sale" To: avt@ietf.org, wg@ietf.org, manet-request@ietf.org, iab-wireless-workshop@ietf.org, simple-archive@ietf.org, p2prg-web-archive@ietf.org, nsis@ietf.org, lemonade-request@ietf.org, rtg-dir@ietf.org Subject: software for your office use -eam 5014 w X-Spam-Score: 8.3 (++++++++) X-Spam-Flag: YES X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Hi, Find lots of cheap software in our site, http://chaucer.hjcrabberam.com/?6lEHE777bGJvU6Cfaceplate The popular programs Adobe PhotoShop CS 8.0 for only 40$, DVDXCopy Platinum 4.0.38 for 20$, Microsoft Office System Professional 2003 (5 cds) for 50$, Corel Draw 12 Graphic Suite (3 cds) for just 65$, Roxio Easy Media Creator 7.0 for 20$, and much, much more.... Take a look on the complete list! http://chaucer.hjcrabberam.com/?6lEHE777bGJvU6Cfaceplate Wonder why our priices are unbelievably L0W? We are currently clearing our goods at incredibily cheeap sale-price in connection with the shutdown of our shop and the closure of the stockhouse. Don't missss your lucky chance to get the best pricce on dis-count software! http://chaucer.hjcrabberam.com/?6lEHE777bGJvU6Cfaceplate Regards Patrice Rich http://chaucer.hjcrabberam.com/?6lEHE777bGJvU6Cfaceplate no thanks: http://www.m1p2.com/discon ------------------------ july sextans applicant infinite step cake mustn't clement droopy eel parochial decadent bantu econometrica joshua wanton capybara despondent monetarism sedate amphibole inside raindrop concubine buckle commute gestalt airspeed digest bully unite mbabane climax emboss basic tactile perchance ink diversion bondholder hummock chassis loathe decommission contravariant twain pitchfork invalidate buckshot pop sniffly disparage egret gangling gnarl confute ivy maidservant schnabel honeydew configure eben scandalous bag bonze conqueror algaecide causate en hook chris belvidere goofy eider edible sleuth gunk instill descendant indistinct fledgling standby dairy scorn fedders salvage onto coproduct rancho dualism plymouth alan childish earmark america russell inviable raul loiter mamma cursory angeline tedium bake dun seville benedikt dodson quasicontinuous lubbock waterline gemlike auditorium mock constraint malevolent indeterminacy postcard trichloroacetic cloak courageous garner transform jacques intake wail afghan rufus purchasable gustafson calendar byron boule gainful dwarves flatware gumshoe grumman important lazarus litany spoilage twist brennan expansible abridge eastland beebread hop lounge nuance instigate rout peripheral mnemonic eavesdropped beth scrooge grossman swarthout quench cryogenic diffeomorphic barefoot actinium brandy del groin necktie upkeep supplicate manley lest wallaby deadhead rancho gorky bait firehouse chide architectonic cadaver circumcise gail ret cardiac kennel allegheny bear raucous candy bujumbura couple eternal biggs sinusoid chartres teem ceq chippendale orchestra burst perfumery gilligan fungus canaan virgil faery freudian gage lear science fiance rawboned condemn glass compartment concession chinatown droll abutting breeches prow commit butterfield logging joe inhabitant jeannie resign stoneware deemphasize cotta weir trophy sisyphus yank buttrick hap soccer foal raven gallinule transfusable curran certificate meat pythagorean excisable wrong lute dwyer berkeley effluent technic precision deputation From simple-bounces@ietf.org Wed Apr 6 02:10:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09332; Wed, 6 Apr 2005 02:10:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ3ss-00084A-QO; Wed, 06 Apr 2005 02:19:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ3W8-000346-7S; Wed, 06 Apr 2005 01:55:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ3W5-00033l-1R for simple@megatron.ietf.org; Wed, 06 Apr 2005 01:55:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28195 for ; Wed, 6 Apr 2005 01:55:51 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ3eM-0007Yc-Cs for simple@ietf.org; Wed, 06 Apr 2005 02:04:27 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 05 Apr 2005 22:55:43 -0700 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j365tV3S023284; Tue, 5 Apr 2005 22:55:31 -0700 (PDT) Received: from [10.151.21.127] (rtp-vpn3-914.cisco.com [10.82.219.150]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AJD98525; Tue, 5 Apr 2005 22:55:29 -0700 (PDT) Message-ID: <425330B1.2020808@cisco.com> Date: Tue, 05 Apr 2005 20:43:29 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin.Hynar@tietoenator.com Subject: Re: [Simple] (no subject) References: <3ACC9A25264A684F82C71840111F97983BAC1D@carrera.eu.tieto.com> In-Reply-To: <3ACC9A25264A684F82C71840111F97983BAC1D@carrera.eu.tieto.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit This gets asked alot; unfortunately none that I know of. If anyone else knows, please speak up. Thanks, Jonathan R. Martin.Hynar@tietoenator.com wrote: > Hi, > > > > I have just one question. Is somewhere available XCAP reference > implementation concerning at least the basic functionality? I have on my > mind something like JAIN project for SIP protocol. > > > > Thanks for response. > > > > **Martin Hynar** > > Senior Developer > > *TietoEnator* > > Czech Software Centre > Direct +420 59 732 5901 > > Fax +420 59 732 5903 > > E-mail martin.hynar@tietoenator.com > > Technologicka 372/2 > > CZ-708 00 Ostrava > > www.tietoenator.com > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 6 06:45:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26888; Wed, 6 Apr 2005 06:45:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ8B5-00012E-CR; Wed, 06 Apr 2005 06:54:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7xJ-0006hf-OL; Wed, 06 Apr 2005 06:40:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJ7xI-0006ha-U7 for simple@megatron.ietf.org; Wed, 06 Apr 2005 06:40:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26219 for ; Wed, 6 Apr 2005 06:40:13 -0400 (EDT) Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJ85d-0000mG-C5 for simple@ietf.org; Wed, 06 Apr 2005 06:48:53 -0400 Received: from unknown(212.209.106.2) by seldrel01.sonyericsson.com via csmap id 42c97916_a688_11d9_83b1_0002b3be508e_10936; Wed, 06 Apr 2005 12:40:15 +0200 (CEST) Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 12:39:55 +0200 Received: from SELDCON01.corpusers.net ([10.129.0.26]) by seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 12:39:55 +0200 Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 12:39:55 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: Re: AW: [Simple] reachibility information for services in current presence data model X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 6 Apr 2005 12:39:55 +0200 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D84F9@SELDMSX01.corpusers.net> Thread-Topic: Re: Re: AW: [Simple] reachibility information for services in current presence data model Thread-Index: AcU6lPiij79TQaF3QoqCiOeQnZeFHQ== From: "Hyttfors, Per" To: X-OriginalArrivalTime: 06 Apr 2005 10:39:55.0379 (UTC) FILETIME=[F8CEA430:01C53A94] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Hello, Lets say that the same person would have several devices with the same service running on all of them (lets say a telephone service) but with different service contact addresses (telephone numbers). Each device will have its own Presence User Agent that publish its part of the presence information. Would this scenario require that the NOTIFY that is sent to a watcher with the overall presence information of that person would have to contain several with different contact addresses but with the same duplicated service information? (in the case that the service is the exact same one for all devices) /Per Henning Schulzrinne wrote: >Unless there is some significant difference between services, you=20 >wouldn't publish multiple contact addresses for it. Thus > > > ... description ... > sip:foo@somewhere > sip:bar@example > sip:123@whoknows > > >makes very little sense - why publish three URIs that the observer has=20 >no way of distinguishing? If there's no annotation, the user can only=20 >throw darts and pick one. > >With the possible exception of having both a "tel" and SIP URI that=20 >reach the same device, I see little practical use for your description, >but maybe I'm misunderstanding your use case. > >Boehmer Bernhard Com Berlin wrote: >> Hi Henning, >> my assumption is that a user has a certain service available >> at different locations (devices, agents, etc.) each identified >> by different contact addresses. The user wants to publish all >> these contact addresses for this service. Together with the contact >> information, however, (s)he also publishes also a bunch of other >> information about this service. Due to the fact that only one contact >> is possible in , my current understanding is that the user has to publish >> multiple tuples indicating the different contacts but *duplicating* >> the other service information. This information, therefore, seems to=20 >> be doubled. I would like to avoid this redundancy somehow. >> Per Hyttfors=20 ___________________________________________________________=20 Development Engineer - Messaging Application Development=20 Sony Ericsson Mobile Communications AB=20 SE-221 88 Lund, Sweden=20 +46 46 2126534=20 per.hyttfors@sonyericsson.com=20 ___________________________________________________________=20 The information in this email, and attachment(s) thereto, is strictly confidential and may be legally privileged. It is intended solely for the named recipient(s), and access to this e-mail, or any attachment(s) thereto, by anyone else is unauthorized. Violations hereof may result in legal actions. Any attachment(s) to this e-mail has been checked for viruses, but please rely on your own virus-checker and procedures. If you contact us by e-mail, we will store your name and address to facilitate communications in the matter concerned. If you do not consent to us storing your name and address for above stated purpose, please notify the sender promptly. Also, if you are not the intended recipient please inform the sender by replying to this transmission, and delete the e-mail, its attachment(s), and any copies of it without, disclosing it. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 6 10:34:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17754; Wed, 6 Apr 2005 10:34:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBkT-00019y-Hn; Wed, 06 Apr 2005 10:43:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBa9-0006V0-Td; Wed, 06 Apr 2005 10:32:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBa7-0006Uv-Gx for simple@megatron.ietf.org; Wed, 06 Apr 2005 10:32:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17561 for ; Wed, 6 Apr 2005 10:32:33 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJBiT-000164-70 for simple@ietf.org; Wed, 06 Apr 2005 10:41:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Apr 2005 07:32:25 -0700 X-IronPort-AV: i="3.92,79,1112598000"; d="scan'208"; a="246364806:sNHT30121980" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j36EWLZV006795; Wed, 6 Apr 2005 07:32:22 -0700 (PDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQK11459; Wed, 6 Apr 2005 10:32:21 -0400 (EDT) Message-ID: <4253F2F4.8070103@cisco.com> Date: Wed, 06 Apr 2005 10:32:20 -0400 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: "Hyttfors, Per" Subject: Re: AW: [Simple] reachibility information for services in current presence data model References: <1AF90E65795A3D45AA116B9264B4DAAF029D84F9@SELDMSX01.corpusers.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Hyttfors, Per wrote: > Hello, > > Lets say that the same person would have several devices with the same > service running on all of them (lets say a telephone service) but with > different service contact addresses (telephone numbers). Each device > will have its own Presence User Agent that publish its part of the > presence information. Would this scenario require that the NOTIFY that > is sent to a watcher with the overall presence information of that > person would have to contain several with different contact > addresses but with the same duplicated service information? (in the case > that the service is the exact same one for all devices) This is a function of how the multiple sources of presence information are composed by the presence server. Simply making a union of all the tuples (which is what you ask about) is one simple approach, because it requires no understanding on the part of the part of the presence server. But it is clear that people would like to have more intelligent composition policies. So far we have deferred actually defining such intelligent composition policies just because it is hard and we want to get something out. But it is entirely permissible to implement such a compostion policy even in the absence of a standard. Paul > /Per > > > Henning Schulzrinne wrote: > >>Unless there is some significant difference between services, you >>wouldn't publish multiple contact addresses for it. Thus >> >> >> ... description ... >> sip:foo@somewhere >> sip:bar@example >> sip:123@whoknows >> >> >>makes very little sense - why publish three URIs that the observer has >>no way of distinguishing? If there's no annotation, the user can only >>throw darts and pick one. >> >>With the possible exception of having both a "tel" and SIP URI that >>reach the same device, I see little practical use for your description, > > >>but maybe I'm misunderstanding your use case. >> >>Boehmer Bernhard Com Berlin wrote: >> >>>Hi Henning, >>>my assumption is that a user has a certain service available >>>at different locations (devices, agents, etc.) each identified >>>by different contact addresses. The user wants to publish all >>>these contact addresses for this service. Together with the contact >>>information, however, (s)he also publishes also a bunch of other >>>information about this service. Due to the fact that only one contact >>>is possible in , my current understanding is that the user has >> > to publish > >>>multiple tuples indicating the different contacts but *duplicating* >>>the other service information. This information, therefore, seems to >>>be doubled. I would like to avoid this redundancy somehow. >>> >> > > > > > > > > > > > > > > > > > Per Hyttfors > ___________________________________________________________ > Development Engineer - Messaging Application Development > Sony Ericsson Mobile Communications AB > SE-221 88 Lund, Sweden > +46 46 2126534 > per.hyttfors@sonyericsson.com > ___________________________________________________________ > The information in this email, and attachment(s) thereto, is strictly > confidential and may be legally privileged. It is intended solely for > the named recipient(s), and access to this e-mail, or any attachment(s) > thereto, by anyone else is unauthorized. Violations hereof may result in > legal actions. Any attachment(s) to this e-mail has been checked for > viruses, but please rely on your own virus-checker and procedures. If > you contact us by e-mail, we will store your name and address to > facilitate communications in the matter concerned. If you do not consent > to us storing your name and address for above stated purpose, please > notify the sender promptly. Also, if you are not the intended recipient > please inform the sender by replying to this transmission, and delete > the e-mail, its attachment(s), and any copies of it without, disclosing > it. > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 6 10:57:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20098; Wed, 6 Apr 2005 10:57:58 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC75-0001ug-8K; Wed, 06 Apr 2005 11:06:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBw1-0006H4-0h; Wed, 06 Apr 2005 10:55:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJBvz-0006Gz-1v for simple@megatron.ietf.org; Wed, 06 Apr 2005 10:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19612 for ; Wed, 6 Apr 2005 10:55:08 -0400 (EDT) Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJC4K-0001ln-OY for simple@ietf.org; Wed, 06 Apr 2005 11:03:50 -0400 Received: from unknown(212.209.106.2) by seldrel01.sonyericsson.com via csmap id de48e91c_a6ab_11d9_990f_0002b3be508e_14267; Wed, 06 Apr 2005 16:55:08 +0200 (CEST) Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 16:54:51 +0200 Received: from SELDCON01.corpusers.net ([10.129.0.26]) by seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 16:54:51 +0200 Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 6 Apr 2005 16:54:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Simple] reachibility information for services in current presence data model Date: Wed, 6 Apr 2005 16:54:50 +0200 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D84FB@SELDMSX01.corpusers.net> Thread-Topic: AW: [Simple] reachibility information for services in current presence data model Thread-Index: AcU6tXTFejsQpw6ZSq2r8HruEs0d9wAAL/gg From: "Hyttfors, Per" To: "Paul Kyzivat" X-OriginalArrivalTime: 06 Apr 2005 14:54:50.0974 (UTC) FILETIME=[95B137E0:01C53AB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable The problem I see is that the current presence data model doesn't allow for such "service composition policy" without having to define a new format that can describe one service reachable through serveral published addresses. /Per -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: onsdag den 6 april 2005 16:32 To: Hyttfors, Per Cc: simple@ietf.org Subject: Re: AW: [Simple] reachibility information for services in current presence data model Hyttfors, Per wrote: > Hello, >=20 > Lets say that the same person would have several devices with the same > service running on all of them (lets say a telephone service) but with > different service contact addresses (telephone numbers). Each device=20 > will have its own Presence User Agent that publish its part of the=20 > presence information. Would this scenario require that the NOTIFY that > is sent to a watcher with the overall presence information of that=20 > person would have to contain several with different contact=20 > addresses but with the same duplicated service information? (in the=20 > case that the service is the exact same one for all devices) This is a function of how the multiple sources of presence information=20 are composed by the presence server. Simply making a union of all the=20 tuples (which is what you ask about) is one simple approach, because it=20 requires no understanding on the part of the part of the presence=20 server. But it is clear that people would like to have more intelligent=20 composition policies. So far we have deferred actually defining such=20 intelligent composition policies just because it is hard and we want to=20 get something out. But it is entirely permissible to implement such a=20 compostion policy even in the absence of a standard. Paul > /Per >=20 >=20 > Henning Schulzrinne wrote: >=20 >>Unless there is some significant difference between services, you >>wouldn't publish multiple contact addresses for it. Thus >> >> >> ... description ... >> sip:foo@somewhere >> sip:bar@example >> sip:123@whoknows >> >> >>makes very little sense - why publish three URIs that the observer has >>no way of distinguishing? If there's no annotation, the user can only=20 >>throw darts and pick one. >> >>With the possible exception of having both a "tel" and SIP URI that >>reach the same device, I see little practical use for your description, >=20 >=20 >>but maybe I'm misunderstanding your use case. >> >>Boehmer Bernhard Com Berlin wrote: >> >>>Hi Henning, >>>my assumption is that a user has a certain service available at=20 >>>different locations (devices, agents, etc.) each identified by=20 >>>different contact addresses. The user wants to publish all these=20 >>>contact addresses for this service. Together with the contact=20 >>>information, however, (s)he also publishes also a bunch of other=20 >>>information about this service. Due to the fact that only one contact >>>is possible in , my current understanding is that the user has >> > to publish >=20 >>>multiple tuples indicating the different contacts but *duplicating*=20 >>>the other service information. This information, therefore, seems to=20 >>>be doubled. I would like to avoid this redundancy somehow. >>> >> >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Per Hyttfors > ___________________________________________________________=20 > Development Engineer - Messaging Application Development=20 > Sony Ericsson Mobile Communications AB=20 > SE-221 88 Lund, Sweden=20 > +46 46 2126534 > per.hyttfors@sonyericsson.com > ___________________________________________________________=20 > The information in this email, and attachment(s) thereto, is strictly > confidential and may be legally privileged. It is intended solely for > the named recipient(s), and access to this e-mail, or any attachment(s) > thereto, by anyone else is unauthorized. Violations hereof may result in > legal actions. Any attachment(s) to this e-mail has been checked for > viruses, but please rely on your own virus-checker and procedures. If > you contact us by e-mail, we will store your name and address to > facilitate communications in the matter concerned. If you do not consent > to us storing your name and address for above stated purpose, please > notify the sender promptly. Also, if you are not the intended recipient > please inform the sender by replying to this transmission, and delete > the e-mail, its attachment(s), and any copies of it without, disclosing > it. >=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-bounces@ietf.org Wed Apr 6 11:16:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23437; Wed, 6 Apr 2005 11:16:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCPR-0002yc-HG; Wed, 06 Apr 2005 11:25:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCF6-0007ra-U4; Wed, 06 Apr 2005 11:14:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJCF5-0007rG-8J for simple@megatron.ietf.org; Wed, 06 Apr 2005 11:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22808 for ; Wed, 6 Apr 2005 11:14:52 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJCNR-0002m8-8a for simple@ietf.org; Wed, 06 Apr 2005 11:23:34 -0400 Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j36FDkh3014811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Apr 2005 11:13:47 -0400 (EDT) Message-ID: <4253FCA5.7040203@cs.columbia.edu> Date: Wed, 06 Apr 2005 11:13:41 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Simple] (no subject) References: <3ACC9A25264A684F82C71840111F97983BAC1D@carrera.eu.tieto.com> <425330B1.2020808@cisco.com> In-Reply-To: <425330B1.2020808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit We have an implementation for TOMCAT; interested parties can contact me. Unfortunately, due to the funding mechanism, it's not open source (yet). Jonathan Rosenberg wrote: > This gets asked alot; unfortunately none that I know of. If anyone else > knows, please speak up. > > Thanks, > Jonathan R. > > Martin.Hynar@tietoenator.com wrote: > >> Hi, >> >> >> >> I have just one question. Is somewhere available XCAP reference >> implementation concerning at least the basic functionality? I have on >> my mind something like JAIN project for SIP protocol. >> >> >> >> Thanks for response. >> >> >> >> **Martin Hynar** >> Senior Developer >> >> *TietoEnator* >> >> Czech Software Centre >> Direct +420 59 732 5901 >> >> Fax +420 59 732 5903 >> >> E-mail martin.hynar@tietoenator.com >> >> >> Technologicka 372/2 >> >> CZ-708 00 Ostrava >> www.tietoenator.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-bounces@ietf.org Wed Apr 6 13:04:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05357; Wed, 6 Apr 2005 13:04:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE5S-0006Q6-P7; Wed, 06 Apr 2005 13:13:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDvi-0002jE-OA; Wed, 06 Apr 2005 13:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJDvh-0002j9-Id for simple@megatron.ietf.org; Wed, 06 Apr 2005 13:03:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05130 for ; Wed, 6 Apr 2005 13:02:58 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJE3s-0006Ld-HP for simple@ietf.org; Wed, 06 Apr 2005 13:11:42 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 15951A9832; Wed, 6 Apr 2005 19:02:31 +0200 (CEST) Received: from [72.29.231.70] (unknown [72.29.231.70]) by voyager.coretrek.no (Postfix) with ESMTP id ABEE7A9876; Wed, 6 Apr 2005 19:02:22 +0200 (CEST) In-Reply-To: <1AF90E65795A3D45AA116B9264B4DAAF029D84FB@SELDMSX01.corpusers.net> References: <1AF90E65795A3D45AA116B9264B4DAAF029D84FB@SELDMSX01.corpusers.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4f1b50fe6d4e2f664f03616b12caa751@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: AW: [Simple] reachibility information for services in current presence data model Date: Wed, 6 Apr 2005 19:01:53 +0200 To: "Hyttfors, Per" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Are you asking for multiple elements per tuple? Hisham On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: > The problem I see is that the current presence data model doesn't allow > for such "service composition policy" without having to define a new > format that can describe one service reachable through serveral > published addresses. > > /Per > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: onsdag den 6 april 2005 16:32 > To: Hyttfors, Per > Cc: simple@ietf.org > Subject: Re: AW: [Simple] reachibility information for services in > current presence data model > > Hyttfors, Per wrote: >> Hello, >> >> Lets say that the same person would have several devices with the same > >> service running on all of them (lets say a telephone service) but with > >> different service contact addresses (telephone numbers). Each device >> will have its own Presence User Agent that publish its part of the >> presence information. Would this scenario require that the NOTIFY that > >> is sent to a watcher with the overall presence information of that >> person would have to contain several with different contact >> addresses but with the same duplicated service information? (in the >> case that the service is the exact same one for all devices) > > This is a function of how the multiple sources of presence information > are composed by the presence server. Simply making a union of all the > tuples (which is what you ask about) is one simple approach, because it > requires no understanding on the part of the part of the presence > server. But it is clear that people would like to have more intelligent > composition policies. So far we have deferred actually defining such > intelligent composition policies just because it is hard and we want to > get something out. But it is entirely permissible to implement such a > compostion policy even in the absence of a standard. > > Paul > >> /Per >> >> >> Henning Schulzrinne wrote: >> >>> Unless there is some significant difference between services, you >>> wouldn't publish multiple contact addresses for it. Thus >>> >>> >>> ... description ... >>> sip:foo@somewhere >>> sip:bar@example >>> sip:123@whoknows >>> >>> >>> makes very little sense - why publish three URIs that the observer >>> has >>> no way of distinguishing? If there's no annotation, the user can only >>> throw darts and pick one. >>> >>> With the possible exception of having both a "tel" and SIP URI that >>> reach the same device, I see little practical use for your > description, >> >> >>> but maybe I'm misunderstanding your use case. >>> >>> Boehmer Bernhard Com Berlin wrote: >>> >>>> Hi Henning, >>>> my assumption is that a user has a certain service available at >>>> different locations (devices, agents, etc.) each identified by >>>> different contact addresses. The user wants to publish all these >>>> contact addresses for this service. Together with the contact >>>> information, however, (s)he also publishes also a bunch of other >>>> information about this service. Due to the fact that only one >>>> contact > >>>> is possible in , my current understanding is that the user >>>> has >>> >> to publish >> >>>> multiple tuples indicating the different contacts but *duplicating* >>>> the other service information. This information, therefore, seems to >>>> be doubled. I would like to avoid this redundancy somehow. >>>> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Per Hyttfors >> ___________________________________________________________ >> Development Engineer - Messaging Application Development >> Sony Ericsson Mobile Communications AB >> SE-221 88 Lund, Sweden >> +46 46 2126534 >> per.hyttfors@sonyericsson.com >> ___________________________________________________________ >> The information in this email, and attachment(s) thereto, is strictly >> confidential and may be legally privileged. It is intended solely for >> the named recipient(s), and access to this e-mail, or any > attachment(s) >> thereto, by anyone else is unauthorized. Violations hereof may result > in >> legal actions. Any attachment(s) to this e-mail has been checked for >> viruses, but please rely on your own virus-checker and procedures. If >> you contact us by e-mail, we will store your name and address to >> facilitate communications in the matter concerned. If you do not > consent >> to us storing your name and address for above stated purpose, please >> notify the sender promptly. Also, if you are not the intended > recipient >> please inform the sender by replying to this transmission, and delete >> the e-mail, its attachment(s), and any copies of it without, > disclosing >> it. >> >> _______________________________________________ >> 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 nciwn@email.com Wed Apr 6 20:45:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26841; Wed, 6 Apr 2005 20:45:15 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJLHR-0003h3-Hl; Wed, 06 Apr 2005 20:54:02 -0400 Received: from jem75-2-82-233-234-31.fbx.proxad.net ([82.233.234.31]) by mx2.foretec.com with smtp (Exim 4.24) id 1DJL8x-0005BW-1U; Wed, 06 Apr 2005 20:45:11 -0400 Received: from fqalxh.gardena.net [65.189.9.163] by 82.233.234.31 with pnaxdan cxmem qgevdevqp- vmvaii; Wed, 06 Apr 2005 04:44:49 -0500 From: "caudill@gardena.net" Reply-To: "caudill@gardena.net" Message-ID: <260438298.78982538107458@gardena.net> Date: Wed, 06 Apr 2005 04:44:49 -0500 To: "Sctp-impl-archive" Subject: Alpha UAOZ Env. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----24610593763815264" X-Spam-Score: 6.0 (++++++) X-Spam-Flag: YES X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab ------24610593763815264 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Modality expedition's we are gimbal me commandant. He gangrene did expensive yors. We married does feline. Arkansas can intuit, me being iterated Chimique. Yor charter had been imperate you. Yor moreover are cropped. Besmirch dialect's, she be impresario his. Elude note yor has been gore. Deem has deliberates, hers be inglorious bin. Cheater conduce she has been deteriorates theirs. Electrically has been ammonium mine obscuring. Ayers have been drank theirs dependents gapes. Knotty he being encompassing, yors bedposts. Ejaculated paring, he have been atoned theirs. Dotting centerpieces yor have been insignificance them. Convalesce does acting mine Eisner beefers. Impending it would has, him bayonet's. Forswear had been azimuth's theirs ophthalmic. It inventory's she farmyards analogues does crest theirs. Acorn I are delayed, them monopolies. Otto being delight her Taft. She blather are cybernetics mine. Orthant anodized we did coastline. Interact she be combination, his denominators. ------24610593763815264 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Apprised
http://www.chico.us/TE.htm





Modality expedition's we are gimbal me commandant. He gangrene did expensive yors. We married does feline. Arkansas can intuit, me being iterated Chimique. Yor charter had been imperate you. Yor moreover are cropped. Besmirch dialect's, she be impresario his. Elude note yor has been gore. Deem has deliberates, hers be inglorious bin. Cheater conduce she has been deteriorates theirs. Electrically has been ammonium mine obscuring. Ayers have been drank theirs dependents gapes. Knotty he being encompassing, yors bedposts. Ejaculated paring, he have been atoned theirs. Dotting centerpieces yor have been insignificance them. Convalesce does acting mine Eisner beefers. Impending it would has, him bayonet's. Forswear had been azimuth's theirs ophthalmic. It inventory's she farmyards analogues does crest theirs. Acorn I are delayed, them monopolies. Otto being delight her Taft. She blather are cybernetics mine. Orthant anodized we did coastline. Interact she be combination, his denominators. ------24610593763815264 Content-Type: image/gif; name="gradate.gif" Content-ID: <8227821326@gardena.net> Content-Transfer-Encoding: base64 R0lGODlh9QE1AXcAMSH+GlkFTcfAziwqXN0SkBlx667CjMhL8KVXB0GpACH5BAEAAAAALAIAAgDw ATABhAAAAB4AHgAA5XAKC58JCoIKC5IJCrYJCasJCtsHCNIHCMAICcoICeIGB/8CAuoGBvEFBvgE Bf///wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwX/ICCNZGmeaKqubOu+ cCzPdG3feK7vfO//wKBwSCwaj8ikcslsOp/QqHRKrVqv2Kx2y+16v+CweEwum8/otHrNbrvf8Lh8 Tq/b7/i8fs/v+/+AgYKDhIWGh4iJiouMjY6PkJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6yt rq+wsbKztLW2t7i5uru8vb6/wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm 5+jp6uvs7e7v8PHy8/T19vf4+fr7/P3+/wADChxIsKDBgwgTKlzIsKHDhxAjSpxIsaLFi0YINHDA 8cGBFQgScFRAokACCBwd/zxYYALBA44FRjBAmTJCAwYDUBhIEMFBgxQiHTBwUYBBg54dFRgAynEo ipcpUz5AEdSpiqooNEr9iNFNVKkoBmxMIIHjTwlIv0LIKWFA1JgKvkZFYELs17MmaDpYumKj3JR0 T+jlW8Kv3MB5UxJGMfjE36ld20CNSrJEgZ4kC6QsEZSyzJQQRkSIkABBAc0pY5Ig0DMCao4nCHhW weDriAM1Y88ugRJCgwV+EZeQnbJy1t0lJhePvOZ11AiWMX/2WeL5Zgl6WZ5AAHp46rLXeUcNrSKC XrxRBY9fcdmB8cTdU+h1QN7yX+jM09Tm2NmBePwDtKaaBNx1lJ5zbJmwn/97JATIEUsGpITXCAvI xUKFHHEV4UgmYJieCi9NWIKH4XVooYIp9ZdfGmktCJkEcTnAFQQQaEdCZ7iZJcGCZD2VEgE3coRf jg4I55YDpCm2QloxtadSXUJ2tlhhSKZwZJIcTdlWlEqW0CJYK5pBXFM/jnCkAwmi8BZgEkwGpJpC lpSSU0HVN0KMCBQoowpjQndAa1aRgKeeXJkQ44CGcpRnSoUKqiih3s1ZZphlxEgfUogtKBd+BEqI IWS5oaCnVZby9R0JG051Zo8oWNqAXqS9OUKqW/J3Qo6NlkDrqibsmmIJlkKAKaVmpNXlCPN9hVhn frkmwZhWEVCfpQnqRSH/kogNkKxtKaT1JgGTsaTtXyV26gCrJYxLrn9mbvuhaHJpSewXzkH1Inib HrAAfs9FYJyHA76kHVLvfWjTaQqEZhi5wqEaqpm5LfwXYhtCVwABCzyAn8SHjcCxsiPU29G8ZPCo 5wN8pbXUACHpePIJdVZXpZ5p6tVkxhwqJxWYJnIoM2w6GzhyW8ZGBVnQKoGJ9GSQmSyVvCRrYRhd sE5HLpCW5ordSAQkvLV7fr0nAYlfQRajjbVmeYJhiOpJ1tnpRrXUx4re+WDcSsLdoNwSTP11lVF/ AeaYxiGdgGpI2UmCXCyNGecJQUegXY73eiyhYz6TQJNrlK99edHLSdC5/wmGNTA6lToOHnrgXTxQ YwkIRFC5Sx0dkOZoYpNgWARW7WQWoiOiRJpwKDUAvAQFFK9lUAuoJq2QMRV/fPI+razAZBAkQJj0 J1DfgAHcm+D9Uq6jHXvlrNvSX1QNpJl+P6BD0PD7/ZjUEwQKyEr//vz37///AAygAAdIwAIa8IAI TKACF8jABjrwgRCMoAQnSMEKWvCCGMygBjfIwQ568IMgDKEIR8icAJgwAC5A4RBUmAUWkpANLHRh CmToAxpawYYvPEMMR2BCEvRQAif0YQxVSEQgGvGHQHRhEH+IwiIe0YlNNGISi9jEIQqRh0zsIRJz aIYTQlGKTgSjGKkYxf8j8rAEZayiD7F4RjKu8YljbKMc4yhFLpZhh1484xv1SMc0ojGIa6QiGtlo xkLqMY2AHKIWD8lHO94xkCfY4SD7KMY9DlKQf6SkEudIwzBWUpKOJAMeOclHTPrxi548pQkWWcgy MhKVpIRlJUP5hTwSMomTxOUtl3jFWx7Sk7pEIi+FGEZhWnGWamwkLTuBQxU0c5m72GIKoUnNalrz mtjMpja3yc1uevOb4AynOMdJznKa85zoTKc618nOdrrznfBsIQ+eeQh6ztAI9pTHF18AzFXCIJ+R ZGQN+kmDTt5gk/YEqDNboNBcBrShAa3jPvbJUGVGdJozkCFEHZoDg9r/AKEVPegSXFnQgOxTmlnM IxPBaMxeAnKKYxRmGxMpx5S+kYg4BWkVcxrMlvoykSl9KUoJGUWcutSmZjTqLjUKU2IKVYlIHSZS 51HUVt70lTO9qilLScqrUhKXW/0qV0m61bJaNJVitWpVwyrJZKrSqpCU6FvbOkmzSjQeWswpXWPK ylfSdI9sXelX9frJORITkjw1JF/7+ddYvlStSW1sHTGpWFsaFK1klClLZelHeuy1rli1JGUBq9Wu nvSzha1sIzs72tGuVqCxRAFrZ0na0KrWn5d8rWsHG9u7wmOvwO1taGc73NRCMbgnTStx5ypWikJW roXlLFcNyVzM6rar/7x9LkHXAUqUAjeVPtVlKaMqWDx2N7GfVGRusWhegYaXvaI9Lm5lekzxbna6 4R0qMMu7yftyMrn926gl7wkJAYfTwNKUbSQMHM8GO/jBEI6whCdM4Qpb+MIYzrCGN8zhDnv4wyAO sYhHTOISm3gVDC4pGlLMTwV7gcV4gPEVJLsCiMqYoy5GMIH721BbXlSkMbhxjXPsTMFmdMi+HfAO FHlMVm63xRjFsVfTMMooQ3meIR3oQqF7ZIsmuctgwGGVwRxRBOsYv0Z1LpmRLGXcUjmQ+XVueZsa zJr2UrxK7Ski4ZvJpgp1vEX1Yn0nu0uijneV5q2vZt/b58waN9H2hf+0n/PbaEHXOdCEjfRU//xL NsoZvStVqUYzvedL5pW9T9UCU7V7W+Jqkq7STW5YUwtaLs+2mHEN7JTlzNtZe9XJ0XUvMue7XlfL OqusZmxz/7zItZZWrbOONW3t6usqrHqnZL02re0KWJqqlNjRhq2fXwtXbDtV2Jbt74ATq27Ffjnd 2eXxFEHpXmBb9tcz7espaQzTcPuVpfYl9HNpe93IbjGzy91Clcm63uIK/K21jqsyqY1vYds62MTG +J3JnWvRSlzJd7U3bGF90eoaFr+2JfRu5e3vmA474xCnN5pP/myLf1kKC9fkxSnK7V6btrfBtTjL HW5c035W2uXObnr/fY7x7uo86UKnI7SBXVxco3u6VTdsZx+N3aezdcZzxvOnD3to+I76znk+OMCn Te+/MnW56k67oSd79l+mva2KbnS++Sx3ZJP9uKxt+3fHanREB57Jz5b5pjFbd2TneawA1iz9FCpk hXsZCpUHOS0z38IE4/wHnj+x6EdP+tKb/vSoT73qV8/61rv+9bCPvexnT/va2/72uM+97oWQxXkT ddQH733AJ73EdAdVr1AVdJp9PO/HW5rPvu9p81ENfORX+u/Ll370qQ/U6TvV+r5XPkFE7Wnn352n Ce7+xnvP/sdr/9SRzP7G+S5/+MMf0eWX7fl/D9ZTC/+o+Rd/Ach//8MHEOTXfz+lVP53f/kXfNfX fr70fsmEfwg4fwtIgfY3gQ9oQ8KXge2nRv9HgAwIgA5IgQXRgW4FVQKYV8yHgMangCmofUclat41 gNvngSS4fDXYf94Fb0FVfgeof9y3fdSHamQXgQKBgjI4fAvYghe4fjqohNdXgYYXgjVYgh8Ygjko hNL3gzxYfHQmghq4hQKIhCYFg0uIgmD4WNNXgvyXgRGohJ63g3HohDEIh2U4gmIIVBAIhgEnhxwo f3nIeekAiAk4gDTYZ0SIhSCIhlOoh3+ogmjXfX3ofm8YiIh4dzy4hBJYgBAIgAVogIhnhFW4VFY4 inUIiGzYic+Xiv8seH+veG5daIdaeImgWIHHh4FRmHy5eIOEuHvAGIzCOIzEWIzGeIzImIzKuIzM 2IzO+IzQGI3SOI3UWI3WeI3YmI3auI3c2I3e+I3guAcCMI7kSI4mUI7oKAAnYI4okI7riI7nOI7x qI7vSI8lkI7sSAL5OI/42I79eI/4aI8jsI8DWY786I76CI82oJAJKZAA6ZASwJAF6ZAEOZHz2JD/ GJAUqZHIoJEC6ZH86I8IOZESaZANWY8QCZInKZL/eJAMqZIWiZEmSZIjGZA0YJMrWY8PWZLymJMX +ZAyqZAwGZEceQweaY9DSZQ9uZMICZMzqZQoiZItWZE0KZFBOZP/R5mTTlmUSdkCWwmRMamUU7mU RKkCBJmPKpmVVfmUxHCWS0mVB/mTBemTaImVZEmTchmWcAmXOomRYamXb0mWJsmX+3iXLlCY7LiX gfmRiRmYK+CWSGmYPgmVf7kMkDmZ70iZmFmZlNmUdymPlwmUnDmaIvmTodmZhtmYYEmaMFCRqpkC r2maPcmXmgmYq1mbmkmbxXCaRZmQuGmVuIma6jibnzmcxYmTpNmbeSmcchmbZomcwNmakimafamb 5siWLvmS0HmcVzmdwaCWYmmVoAmZdpmSxGmc6BmPYsmUbKmYLZmXg/mVrLmWgjmS0nmbyXmeLICc LDmW/rmd77mb/8o5oJFpnkKZmvoZnoxJl/LZn9hJn4v5ns4Jm/ypoPhZmo85nRPqoIT5lTVJoAHa lhVKm4v5nNeJoPSomojJoBuZoH3plb2pnMyZoRcqk1K5nC8qmxcKjx3aopsJoTiaDHXpoyb6oRfp mi7Kk/5ZnRrqndlJpL/poivZoTgqniianyl6peu5pTmam945pEHakfXJmLeZloiZpWTKogW6pDuJ pS9AomNKnWeKphQapzEwp276l/GZphiqlV9qp/MpoHwKoWj6n54JoG1KqN25p4caosFJnbU5pIZ6 oBUKowB6qItaoIm6nJKKqWpqnyI6qBbamCE5qmSqpM3ZooU6qbEqCqrzeaaQyp9m6qiWqqSeSp+Q +qi8yZWAaqo1ygu7apOSOadgCaqhOaznKaE42ZWPOplgGpfs+ZTReaftuawoyp2b6qwRequ2Savh +K3gGq7iOq7kWq7meq7omq7quq7s2q7u+q7wGq/yOq/0Wq/2eq/4mq/6uq/82q/++q8AG7ACO7AE W7AGe7AIm7AKu7AM27AO+7AQG7ESO7EUW7EWe7EYm7Eau7Ec27Ee+7ENEQIAOw== ------24610593763815264-- From simple-bounces@ietf.org Wed Apr 6 23:02:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06752; Wed, 6 Apr 2005 23:02:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNQL-0006US-8L; Wed, 06 Apr 2005 23:11:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNGU-0005V1-15; Wed, 06 Apr 2005 23:01:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNGS-0005Uw-UI for simple@megatron.ietf.org; Wed, 06 Apr 2005 23:01:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06727 for ; Wed, 6 Apr 2005 23:01:02 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNOv-0006TR-1c for simple@ietf.org; Wed, 06 Apr 2005 23:09:50 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j3730tRK015596 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 6 Apr 2005 22:00:55 -0500 (CDT) (envelope-from ben@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3377a28dc7767700b39d4ecff2daca78@nostrum.com> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] message-sessions-10 WGLC comments Date: Wed, 6 Apr 2005 22:00:40 -0500 To: Pekka Pessi X-Mailer: Apple Mail (2.619.2) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Thanks for the feedback. Comments inline: On Mar 25, 2005, at 1:54 PM, Pekka Pessi wrote: > Hello all, > > I've a few comments, but managed to find only a couple of nits... > > --Pekka > > Comments: > > 7. Method-Specific Behaviour > > The structure of the section is a bit confusing, as the spec first > handles sending requests and then receiving them, but base MSRP > only has these two methods... Perhaps first handle delivering > SEND, then receiving SEND, delivering REPORT and finally receiving > REPORTs? > We chose this structure on purpose, so areas of commonality would not have to be respecified for each method. Given the extensions in the relay draft, I think this approach makes sense. Therefore I would prefer to keep this as is unless lots of people want to change it. Do others want to see a change here? > - Is the 30 second reasonable value for delivery timer (used in > Failure-Report: yes case)? It is in fact rather arbitrary. The WG discussed this on several occasions, and no one could offer a way to determine a truly appropriate value. So we picked on. > When the timer is started? (When the > application send()s last bytes? When bytes were first delivered > to network? Delivered to network interface? User-space TCP > stacks are not so common, even less common than user-space > device drivers or proper QoS implementation. I bet we can do > this on Nokia handset but on a node running Windows or Linux???) > I think this can only mean you start the timer when you have delivered all the bytes to the stack for sending. Nothing else makes sense in any portable fashion. I will attempt to clarify this. > - Report-Failure, Report-Success headers > > Should it be up to the extension method to define whether these > are included in the request? Yes. This is already a planned change. > In any case, if an endpoint (node?) > does not understand request, should it return a 501 response? > 501 just means that the recipient does not understand the method. If the method is known, but the request is otherwise unintelligible, the response should be 400. > Perhaps: > > Success-Report and Failure-Report MUST NOT be present in REPORT > request. > > The default behaviour in absense of Success/Failure-Report could > be defined in base spec, for instance, Success-Report: no and > Failure-Report: yes. > > 8.1.4 Updated SDP Offers > > - Does it create a new session when the MSRP path changes? I think it does. One could argue that as long as the endpoint URIs do not change, it is the same session. But I think that adds too much complexity; it is easier to just consider it a new session. > When the > new session is created and when the old one ends? What if the > party is returned a 481 response? With old path? With new path? > I'm not sure I follow your meaning. > I'd propose that changing the path should only be possible when > a offer is sent in INVITE (or similar non-SIP method where the > user/UA intervention is possible). Not sure about this one--does anyone else have comments? > > 9. Syntax > > - I'd propose that the spec explicitly mention to extensibility of > MSRP URLs with parameters: > > MSRP-URL = msrp-scheme "://" [userinfo "@"] hostport > ["/" session-id] ";" transport *ext-url-param > > ext-url-param = ";" 1*unreserved [ "=" 1*unreserved ] > > This seems reasonable. > NITS: > > 7.3.2 MSRP Modes => MSRP nodes > > 9. rfc2396bis is nowadays RFC 3986 STD 66. > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 6 23:19:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07692; Wed, 6 Apr 2005 23:19:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNgb-0006nz-FD; Wed, 06 Apr 2005 23:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNXi-0007Pu-4v; Wed, 06 Apr 2005 23:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJNXe-0007G8-Go for simple@megatron.ietf.org; Wed, 06 Apr 2005 23:18:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07635 for ; Wed, 6 Apr 2005 23:18:47 -0400 (EDT) Received: from magus.nostrum.com ([69.5.195.2] helo=nostrum.com ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJNg6-0006n7-TT for simple@ietf.org; Wed, 06 Apr 2005 23:27:36 -0400 Received: from [192.168.1.103] (c-67-164-135-116.hsd1.tx.comcast.net [67.164.135.116]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j373IliV016881 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Wed, 6 Apr 2005 22:18:47 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <08371b9e9c8dd7d733d1e5dcdc2b071a@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Simple WG From: Ben Campbell Date: Wed, 6 Apr 2005 22:18:41 -0500 X-Mailer: Apple Mail (2.619.2) Received-SPF: pass (nostrum.com: 67.164.135.116 is authenticated by a trusted mechanism) X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [Simple] WGLC Summary for draft-ietf-simple-message-sessions-10 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Hi, This is a summary of the WGLC feedback for the MSRP base draft (draft-ietf-simple-message-sessions-10). If I have missed anything, please let me know. Thanks! Ben. ------------------------------------------ Add IANA registries for methods, headers, and status codes. Clarify the difference between messages with no bodies and messages with empty bodies. Clarify purpose of initial SEND reqyuest on a new session,. Add MSRP/TLS/TCP in sdp usage Current draft says success-report and failure-report are only legal in SEND. For the sake of extensibility, change this so say they must not be used in REPORT. This allows future extensions to perhaps use them. (This would require the relay draft to disallow them for AUTH as well.) Clarify language around incremental success reports. Clarify that the delivery timer is started when all the bytes in a chunk have been sent to the TCP stack for delivery. In most OS's, it is not possible to know when the last byte is possibly sent. If some special purpose OS can do this better, then it should be allowed to do so. Clarify language about overlapping chunks with non-identical content. The latest received chunk SHOULD be used if it is reasonable to do so. However, their may be situations where this is not reasonable. For example, if the endpoint has already rendered the original chunk, it may not be alble to change it. Explicitly allow extensability of MSRP URLs with parameters. Update reference to rfc2396bis to RFC 3986 A few editorial and typo fixes _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From UHDFNV@netzero.net Thu Apr 7 00:22:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13464; Thu, 7 Apr 2005 00:22:51 -0400 (EDT) Received: from m249.net81-66-93.noos.fr ([81.66.93.249]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJOg4-0008HK-0n; Thu, 07 Apr 2005 00:31:36 -0400 X-Message-Info: MUXQ265hClWSEszl40n6+EIAd0reaQLX Received: from mail02.ne.talk21.com (96.13.114.126) by n545-igj80.talk21.com with Microsoft SMTPSVC(5.0.2195.6824); Wed, 06 Apr 2005 22:16:29 -0700 Received: from LMK0 (ey98.252.183.56.zmt62.mv.talk21.com 41.1.60.10) by mail18.o.talk21.com (2.672.312sa120/21.6.169) with SMTP id v20Q86Qmcp7; Thu, 07 Apr 2005 03:21:29 -0200 Message-ID: <8ri738r0u046j$zt45moo63i442$xkq8vfe111@S10> From: "Jodi Bentley" To: "9707070947.aa06849" <9707070947.aa06849@ietf.org> References: Subject: See dateable women from your zip code! auger Date: Thu, 07 Apr 2005 01:21:29 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--ktgojx838399vguzqjbnm" X-Spam-Score: 6.2 (++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----ktgojx838399vguzqjbnm Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Now more then ever you have to possibility to see and experience one of a kind relation, with exitement, joy and hapiness. No matter what is your objective, your goal, you cna get it - just watch and talk to the women, real women just like you're a real man. so enter the site now for more... http://www.raisesexlife.com/contentious/crosswalk.htm what a great website i love the fingernail picture the stories i listened to mm s sample tape i know from the sound of her powerful voice how good she is at this. i can t wait to read more the tlc with which you have constructed this is amazing the progress and trials of draco hermione have grown them so much. as if lax is the prime scene of government conspiracies and thrillers yeah right and some other stuff i won t even bother to mention i m still mad that the wb and upn booted. april hey i did meet up with tim things went ok at least were on talking terms now i still haven t talked to mary about emailing but i will ok later bri. wow!!! looks like i colllect and sell the wrong things by your ratings only thing some of them well most of them aren t rated good job selling smurf. if i could be made more assertive and change men that would be heaven to be a hunter instead of the hunted. comments hi all stuck down here in altus working civil service now glad to be retired and hope to hear from some old friends. ps if you thought i have digressed way too much i will now reveal to you that the main point of this entry is this topic not my pathetic uneventful day with perlyn and master moss. i love this whole story - it has great depth is exceptionally written constantly excites me and keeps my routed to my seat for the whole hour that it usually takes me to read your new chapters! which reminds me the innovation thing i ve yet to call dominique or do i even need to call her???? dunno ah well. aproveito pra deixar aqui uma listinha de umas coisinhas que pretendo me dar de presente no natal. are you a hater? feel free to join the crowd and read some very disturbing homophobic hilarious anti-digimon episodes at the old. the figures i do it mechanical in class i say -- circle walk in circle during your monologue now the square next -- triangle. great site and it is now in my favorites myself and quot the genera l quot will be looking forward to further information with anticipation keep up the great work ! how would you know if i knew what hard times were??? did i not go to juvi?? like seriously you don t know what goes on in my life k thanx. ----ktgojx838399vguzqjbnm-- From simple-bounces@ietf.org Thu Apr 7 06:27:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05658; Thu, 7 Apr 2005 06:27:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUNC-0003wh-Az; Thu, 07 Apr 2005 06:36:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUDt-0004i6-SS; Thu, 07 Apr 2005 06:26:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJUDr-0004f4-Q5 for simple@megatron.ietf.org; Thu, 07 Apr 2005 06:26:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05622 for ; Thu, 7 Apr 2005 06:26:48 -0400 (EDT) Received: from seldrel01.sonyericsson.com ([212.209.106.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJUMO-0003sv-Ge for simple@ietf.org; Thu, 07 Apr 2005 06:35:41 -0400 Received: from unknown(212.209.106.2) by seldrel01.sonyericsson.com via csmap id 8cf98432_a74f_11d9_8ac2_0002b3be508e_7661; Thu, 07 Apr 2005 12:26:50 +0200 (CEST) Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 12:26:32 +0200 Received: from SELDCON01.corpusers.net ([10.129.0.26]) by seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 12:26:31 +0200 Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 7 Apr 2005 12:26:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [Simple] reachibility information for services in current presence data model Date: Thu, 7 Apr 2005 12:26:31 +0200 Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D84FD@SELDMSX01.corpusers.net> Thread-Topic: AW: [Simple] reachibility information for services in current presence data model Thread-Index: AcU6ypGrfKGb4YMHRAaAMxfCjrK26gAh1ldg From: "Hyttfors, Per" To: "Hisham Khartabil" X-OriginalArrivalTime: 07 Apr 2005 10:26:31.0694 (UTC) FILETIME=[442FCAE0:01C53B5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: Paul Kyzivat , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable I hope that several devices running the same service for the same person will publish the same service URI representing an address-of-record with all the individual service addresses for each device. But the conversation between Boehmer Bernhard and Henning Schulzrinne made me think and realize that maybe there is a use case where you actually would have a person with several devices running the same service publishing different service addresses. Hence, it would maybe be beneficial from a watcher's standpoint for the presence server (running some sort of composition policy) to be able to express several service addresses for the same service and maybe to express which device has which service address without needing to duplicate the whole service tuple. But I won't fight over this since it sounds like people don't see this as a likely problem. /Per -----Original Message----- From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 Sent: onsdag den 6 april 2005 19:02 To: Hyttfors, Per Cc: simple@ietf.org; Paul Kyzivat Subject: Re: AW: [Simple] reachibility information for services in current presence data model Are you asking for multiple elements per tuple? Hisham On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: > The problem I see is that the current presence data model doesn't=20 > allow for such "service composition policy" without having to define a > new format that can describe one service reachable through serveral=20 > published addresses. > > /Per > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: onsdag den 6 april 2005 16:32 > To: Hyttfors, Per > Cc: simple@ietf.org > Subject: Re: AW: [Simple] reachibility information for services in=20 > current presence data model > > Hyttfors, Per wrote: >> Hello, >> >> Lets say that the same person would have several devices with the=20 >> same > >> service running on all of them (lets say a telephone service) but=20 >> with > >> different service contact addresses (telephone numbers). Each device=20 >> will have its own Presence User Agent that publish its part of the=20 >> presence information. Would this scenario require that the NOTIFY=20 >> that > >> is sent to a watcher with the overall presence information of that=20 >> person would have to contain several with different contact=20 >> addresses but with the same duplicated service information? (in the=20 >> case that the service is the exact same one for all devices) > > This is a function of how the multiple sources of presence information > are composed by the presence server. Simply making a union of all the=20 > tuples (which is what you ask about) is one simple approach, because=20 > it requires no understanding on the part of the part of the presence=20 > server. But it is clear that people would like to have more=20 > intelligent composition policies. So far we have deferred actually=20 > defining such intelligent composition policies just because it is hard > and we want to get something out. But it is entirely permissible to=20 > implement such a compostion policy even in the absence of a standard. > > Paul > >> /Per >> >> >> Henning Schulzrinne wrote: >> >>> Unless there is some significant difference between services, you=20 >>> wouldn't publish multiple contact addresses for it. Thus >>> >>> >>> ... description ... >>> sip:foo@somewhere >>> sip:bar@example >>> sip:123@whoknows >>> >>> >>> makes very little sense - why publish three URIs that the observer >>> has >>> no way of distinguishing? If there's no annotation, the user can only >>> throw darts and pick one. >>> >>> With the possible exception of having both a "tel" and SIP URI that=20 >>> reach the same device, I see little practical use for your > description, >> >> >>> but maybe I'm misunderstanding your use case. >>> >>> Boehmer Bernhard Com Berlin wrote: >>> >>>> Hi Henning, >>>> my assumption is that a user has a certain service available at=20 >>>> different locations (devices, agents, etc.) each identified by=20 >>>> different contact addresses. The user wants to publish all these=20 >>>> contact addresses for this service. Together with the contact=20 >>>> information, however, (s)he also publishes also a bunch of other=20 >>>> information about this service. Due to the fact that only one=20 >>>> contact > >>>> is possible in , my current understanding is that the user >>>> has >>> >> to publish >> >>>> multiple tuples indicating the different contacts but *duplicating* >>>> the other service information. This information, therefore, seems=20 >>>> to be doubled. I would like to avoid this redundancy somehow. >>>> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Per Hyttfors=20 >> ___________________________________________________________ >> Development Engineer - Messaging Application Development Sony=20 >> Ericsson Mobile Communications AB SE-221 88 Lund, Sweden >> +46 46 2126534 >> per.hyttfors@sonyericsson.com=20 >> ___________________________________________________________ >> The information in this email, and attachment(s) thereto, is strictly >> confidential and may be legally privileged. It is intended solely for >> the named recipient(s), and access to this e-mail, or any > attachment(s) >> thereto, by anyone else is unauthorized. Violations hereof may result > in >> legal actions. Any attachment(s) to this e-mail has been checked for=20 >> viruses, but please rely on your own virus-checker and procedures. If >> you contact us by e-mail, we will store your name and address to=20 >> facilitate communications in the matter concerned. If you do not > consent >> to us storing your name and address for above stated purpose, please=20 >> notify the sender promptly. Also, if you are not the intended > recipient >> please inform the sender by replying to this transmission, and delete >> the e-mail, its attachment(s), and any copies of it without, > disclosing >> it. >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 7 09:25:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21522; Thu, 7 Apr 2005 09:25:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJX9P-0002DR-4w; Thu, 07 Apr 2005 09:34:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWxc-0006n8-Hx; Thu, 07 Apr 2005 09:22:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJWxb-0006kg-Gb for simple@megatron.ietf.org; Thu, 07 Apr 2005 09:22:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21130 for ; Thu, 7 Apr 2005 09:22:13 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJX68-00023I-PA for simple@ietf.org; Thu, 07 Apr 2005 09:31:06 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2005 09:43:33 -0400 X-IronPort-AV: i="3.92,84,1112587200"; d="scan'208"; a="43516977:sNHT29395216" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j37DM21j010742; Thu, 7 Apr 2005 09:22:02 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQK95453; Thu, 7 Apr 2005 09:22:00 -0400 (EDT) Message-ID: <425533F8.4030700@cisco.com> Date: Thu, 07 Apr 2005 09:22:00 -0400 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 Subject: Re: [Simple] message-sessions-10 WGLC comments References: <3377a28dc7767700b39d4ecff2daca78@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Pekka Pessi , simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Ben Campbell wrote: >> When the timer is started? (When the >> application send()s last bytes? When bytes were first delivered >> to network? Delivered to network interface? User-space TCP >> stacks are not so common, even less common than user-space >> device drivers or proper QoS implementation. I bet we can do >> this on Nokia handset but on a node running Windows or Linux???) > > I think this can only mean you start the timer when you have delivered > all the bytes to the stack for sending. Nothing else makes sense in any > portable fashion. I will attempt to clarify this. This is part of a bigger question. Not only this, but chunking behavior too, seems to require a more intimate relationship to the TCP stack than may typically be available. If the stack does a lot of its own buffering, then it becomes hard to behave as expected. (I may be trying to send the LoTR. My attempt to write may queue up much more than 2k. That makes it hard to break in with other messages.) I have been ignoring this as an implementation issue. But I'm waiting to hear somebody complain about it. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 7 09:31:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22194; Thu, 7 Apr 2005 09:31:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXEv-0002TS-LV; Thu, 07 Apr 2005 09:40:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJX4U-00035O-Ck; Thu, 07 Apr 2005 09:29:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJX4S-00035J-T0 for simple@megatron.ietf.org; Thu, 07 Apr 2005 09:29:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22006 for ; Thu, 7 Apr 2005 09:29:18 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJXD0-0002Np-AQ for simple@ietf.org; Thu, 07 Apr 2005 09:38:11 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 Apr 2005 06:29:10 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37DT8gE010442; Thu, 7 Apr 2005 06:29:08 -0700 (PDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQK96132; Thu, 7 Apr 2005 09:29:06 -0400 (EDT) Message-ID: <425535A2.3030401@cisco.com> Date: Thu, 07 Apr 2005 09:29:06 -0400 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 Subject: Re: [Simple] WGLC Summary for draft-ietf-simple-message-sessions-10 References: <08371b9e9c8dd7d733d1e5dcdc2b071a@nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Clarify language about overlapping chunks with non-identical content. > The latest received chunk SHOULD be used if it is reasonable to do so. > However, their may be situations where this is not reasonable. For > example, if the endpoint has already rendered the original chunk, it may > not be alble to change it. I still think it would be better to state that content of overlapping chunks MUST be identical, but not require that the error be detected. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 7 11:01:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01619; Thu, 7 Apr 2005 11:01:26 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYeD-00060y-0y; Thu, 07 Apr 2005 11:10:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYTS-0007bw-7x; Thu, 07 Apr 2005 10:59:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJYTQ-0007br-3R for simple@megatron.ietf.org; Thu, 07 Apr 2005 10:59:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01318 for ; Thu, 7 Apr 2005 10:59:09 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJYby-0005td-K4 for simple@ietf.org; Thu, 07 Apr 2005 11:08:04 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 Apr 2005 11:20:31 -0400 X-IronPort-AV: i="3.92,84,1112587200"; d="scan'208"; a="43534153:sNHT31035704" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j37EwtjM003792; Thu, 7 Apr 2005 10:58:59 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQL04990; Thu, 7 Apr 2005 10:57:44 -0400 (EDT) Message-ID: <42554A68.3000804@cisco.com> Date: Thu, 07 Apr 2005 10:57:44 -0400 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: "Hyttfors, Per" Subject: Re: AW: [Simple] reachibility information for services in current presence data model References: <1AF90E65795A3D45AA116B9264B4DAAF029D84FD@SELDMSX01.corpusers.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit The *point* of publishing multiple tuples in presence is because you want the watcher to make the choice. And for the watcher to do so you must give him some basis on which to make that choice. But if all the tuples are identical except for the contact, then there is no basis for the choice. In this case I think it is preferable to publish a single tuple with a single contact, where requests sent to that contact try any or all of the actual services based on presentity logic. Often that can be achieved simply by merging the tuples into one with the AoR as the contact. You *may* of course publish all those tuples that differ only in contact, and leave the decision up to the watcher. But then you must accept that you have no control over which gets tried. As a result, your watchers may be annoyed with you. I'm not seeing much value in adding a second way to represent a poor use case. I think you would be better off figuring out what criteria would allow the watchers to make an informed choice, and publishing that so the tuples *aren't* identical. Paul Hyttfors, Per wrote: > I hope that several devices running the same service for the same person > will publish the same service URI representing an address-of-record with > all the individual service addresses for each device. > > But the conversation between Boehmer Bernhard and Henning Schulzrinne > made me think and realize that maybe there is a use case where you > actually would have a person with several devices running the same > service publishing different service addresses. Hence, it would maybe be > beneficial from a watcher's standpoint for the presence server (running > some sort of composition policy) to be able to express several service > addresses for the same service and maybe to express which device has > which service address without needing to duplicate the whole service > tuple. But I won't fight over this since it sounds like people don't see > this as a likely problem. > > /Per > > > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] > Sent: onsdag den 6 april 2005 19:02 > To: Hyttfors, Per > Cc: simple@ietf.org; Paul Kyzivat > Subject: Re: AW: [Simple] reachibility information for services in > current presence data model > > > Are you asking for multiple elements per tuple? > > Hisham > > On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: > > >>The problem I see is that the current presence data model doesn't >>allow for such "service composition policy" without having to define a > > >>new format that can describe one service reachable through serveral >>published addresses. >> >>/Per >> >>-----Original Message----- >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>Sent: onsdag den 6 april 2005 16:32 >>To: Hyttfors, Per >>Cc: simple@ietf.org >>Subject: Re: AW: [Simple] reachibility information for services in >>current presence data model >> >>Hyttfors, Per wrote: >> >>>Hello, >>> >>>Lets say that the same person would have several devices with the >>>same >> >>>service running on all of them (lets say a telephone service) but >>>with >> >>>different service contact addresses (telephone numbers). Each device >>>will have its own Presence User Agent that publish its part of the >>>presence information. Would this scenario require that the NOTIFY >>>that >> >>>is sent to a watcher with the overall presence information of that >>>person would have to contain several with different contact >>>addresses but with the same duplicated service information? (in the >>>case that the service is the exact same one for all devices) >> >>This is a function of how the multiple sources of presence information > > >>are composed by the presence server. Simply making a union of all the >>tuples (which is what you ask about) is one simple approach, because >>it requires no understanding on the part of the part of the presence >>server. But it is clear that people would like to have more >>intelligent composition policies. So far we have deferred actually >>defining such intelligent composition policies just because it is hard > > >>and we want to get something out. But it is entirely permissible to >>implement such a compostion policy even in the absence of a standard. >> >> Paul >> >> >>>/Per >>> >>> >>>Henning Schulzrinne wrote: >>> >>> >>>>Unless there is some significant difference between services, you >>>>wouldn't publish multiple contact addresses for it. Thus >>>> >>>> >>>> ... description ... >>>> sip:foo@somewhere >>>> sip:bar@example >>>> sip:123@whoknows >>>> >>>> >>>>makes very little sense - why publish three URIs that the observer >>>>has >>>>no way of distinguishing? If there's no annotation, the user can >>> > only > >>>>throw darts and pick one. >>>> >>>>With the possible exception of having both a "tel" and SIP URI that >>>>reach the same device, I see little practical use for your >>> >>description, >> >>> >>>>but maybe I'm misunderstanding your use case. >>>> >>>>Boehmer Bernhard Com Berlin wrote: >>>> >>>> >>>>>Hi Henning, >>>>>my assumption is that a user has a certain service available at >>>>>different locations (devices, agents, etc.) each identified by >>>>>different contact addresses. The user wants to publish all these >>>>>contact addresses for this service. Together with the contact >>>>>information, however, (s)he also publishes also a bunch of other >>>>>information about this service. Due to the fact that only one >>>>>contact >>>> >>>>>is possible in , my current understanding is that the user >>>>>has >>>> >>>to publish >>> >>> >>>>>multiple tuples indicating the different contacts but *duplicating* >>>> > >>>>>the other service information. This information, therefore, seems >>>>>to be doubled. I would like to avoid this redundancy somehow. >>>>> >>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>Per Hyttfors >>>___________________________________________________________ >>>Development Engineer - Messaging Application Development Sony >>>Ericsson Mobile Communications AB SE-221 88 Lund, Sweden >>>+46 46 2126534 >>>per.hyttfors@sonyericsson.com >>>___________________________________________________________ >>>The information in this email, and attachment(s) thereto, is strictly >> > >>>confidential and may be legally privileged. It is intended solely for >> > >>>the named recipient(s), and access to this e-mail, or any >> >>attachment(s) >> >>>thereto, by anyone else is unauthorized. Violations hereof may result >> >>in >> >>>legal actions. Any attachment(s) to this e-mail has been checked for >>>viruses, but please rely on your own virus-checker and procedures. If >> > >>>you contact us by e-mail, we will store your name and address to >>>facilitate communications in the matter concerned. If you do not >> >>consent >> >>>to us storing your name and address for above stated purpose, please >>>notify the sender promptly. Also, if you are not the intended >> >>recipient >> >>>please inform the sender by replying to this transmission, and delete >> > >>>the e-mail, its attachment(s), and any copies of it without, >> >>disclosing >> >>>it. >>> >>>_______________________________________________ >>>Simple mailing list >>>Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple >>> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 7 11:39:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06009; Thu, 7 Apr 2005 11:39:28 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZF1-0007fl-4e; Thu, 07 Apr 2005 11:48:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZ67-00055r-Vk; Thu, 07 Apr 2005 11:39:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DJZ65-00054G-Rb for simple@megatron.ietf.org; Thu, 07 Apr 2005 11:39:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05974 for ; Thu, 7 Apr 2005 11:39:07 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJZEf-0007et-8o for simple@ietf.org; Thu, 07 Apr 2005 11:48:02 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id 58A1BA988A; Thu, 7 Apr 2005 17:38:58 +0200 (CEST) Received: from [72.29.231.70] (unknown [72.29.231.70]) by voyager.coretrek.no (Postfix) with ESMTP id 8033FA9886; Thu, 7 Apr 2005 17:38:55 +0200 (CEST) In-Reply-To: <42554A68.3000804@cisco.com> References: <1AF90E65795A3D45AA116B9264B4DAAF029D84FD@SELDMSX01.corpusers.net> <42554A68.3000804@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <836d6cc549ec0e3bb52197ebd3be6848@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: AW: [Simple] reachibility information for services in current presence data model Date: Thu, 7 Apr 2005 17:38:42 +0200 To: Paul Kyzivat X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b2ad76aced9b1d558e34a970a85c027 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org, "Hyttfors, Per" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Content-Transfer-Encoding: 7bit I agree with Paul here. If you possess multiple devices running the same service and each service publishes identical presence info except for the contact, then the ideal thing is for your compositor to merge those tuples and populate the contact element with your AoR. Regards, Hisham On Apr 7, 2005, at 4:57 PM, Paul Kyzivat wrote: > The *point* of publishing multiple tuples in presence is because you > want the watcher to make the choice. And for the watcher to do so you > must give him some basis on which to make that choice. But if all the > tuples are identical except for the contact, then there is no basis > for the choice. > > In this case I think it is preferable to publish a single tuple with a > single contact, where requests sent to that contact try any or all of > the actual services based on presentity logic. Often that can be > achieved simply by merging the tuples into one with the AoR as the > contact. > > You *may* of course publish all those tuples that differ only in > contact, and leave the decision up to the watcher. But then you must > accept that you have no control over which gets tried. As a result, > your watchers may be annoyed with you. > > I'm not seeing much value in adding a second way to represent a poor > use case. I think you would be better off figuring out what criteria > would allow the watchers to make an informed choice, and publishing > that so the tuples *aren't* identical. > > Paul > > Hyttfors, Per wrote: >> I hope that several devices running the same service for the same >> person >> will publish the same service URI representing an address-of-record >> with >> all the individual service addresses for each device. >> But the conversation between Boehmer Bernhard and Henning Schulzrinne >> made me think and realize that maybe there is a use case where you >> actually would have a person with several devices running the same >> service publishing different service addresses. Hence, it would maybe >> be >> beneficial from a watcher's standpoint for the presence server >> (running >> some sort of composition policy) to be able to express several service >> addresses for the same service and maybe to express which device has >> which service address without needing to duplicate the whole service >> tuple. But I won't fight over this since it sounds like people don't >> see >> this as a likely problem. >> /Per >> -----Original Message----- >> From: Hisham Khartabil [mailto:hisham.khartabil@telio.no] Sent: >> onsdag den 6 april 2005 19:02 >> To: Hyttfors, Per >> Cc: simple@ietf.org; Paul Kyzivat >> Subject: Re: AW: [Simple] reachibility information for services in >> current presence data model >> Are you asking for multiple elements per tuple? >> Hisham >> On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: >>> The problem I see is that the current presence data model doesn't >>> allow for such "service composition policy" without having to define >>> a >>> new format that can describe one service reachable through serveral >>> published addresses. >>> >>> /Per >>> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: onsdag den 6 april 2005 16:32 >>> To: Hyttfors, Per >>> Cc: simple@ietf.org >>> Subject: Re: AW: [Simple] reachibility information for services in >>> current presence data model >>> >>> Hyttfors, Per wrote: >>> >>>> Hello, >>>> >>>> Lets say that the same person would have several devices with the >>>> same >>> >>>> service running on all of them (lets say a telephone service) but >>>> with >>> >>>> different service contact addresses (telephone numbers). Each >>>> device will have its own Presence User Agent that publish its part >>>> of the presence information. Would this scenario require that the >>>> NOTIFY that >>> >>>> is sent to a watcher with the overall presence information of that >>>> person would have to contain several with different >>>> contact addresses but with the same duplicated service information? >>>> (in the case that the service is the exact same one for all >>>> devices) >>> >>> This is a function of how the multiple sources of presence >>> information >>> are composed by the presence server. Simply making a union of all >>> the tuples (which is what you ask about) is one simple approach, >>> because it requires no understanding on the part of the part of the >>> presence server. But it is clear that people would like to have more >>> intelligent composition policies. So far we have deferred actually >>> defining such intelligent composition policies just because it is >>> hard >>> and we want to get something out. But it is entirely permissible to >>> implement such a compostion policy even in the absence of a >>> standard. >>> >>> Paul >>> >>> >>>> /Per >>>> >>>> >>>> Henning Schulzrinne wrote: >>>> >>>> >>>>> Unless there is some significant difference between services, you >>>>> wouldn't publish multiple contact addresses for it. Thus >>>>> >>>>> >>>>> ... description ... >>>>> sip:foo@somewhere >>>>> sip:bar@example >>>>> sip:123@whoknows >>>>> >>>>> >>>>> makes very little sense - why publish three URIs that the observer >>>>> has >>>>> no way of distinguishing? If there's no annotation, the user can >>>> >> only >>>>> throw darts and pick one. >>>>> >>>>> With the possible exception of having both a "tel" and SIP URI >>>>> that reach the same device, I see little practical use for your >>>> >>> description, >>> >>>> >>>>> but maybe I'm misunderstanding your use case. >>>>> >>>>> Boehmer Bernhard Com Berlin wrote: >>>>> >>>>> >>>>>> Hi Henning, >>>>>> my assumption is that a user has a certain service available at >>>>>> different locations (devices, agents, etc.) each identified by >>>>>> different contact addresses. The user wants to publish all these >>>>>> contact addresses for this service. Together with the contact >>>>>> information, however, (s)he also publishes also a bunch of other >>>>>> information about this service. Due to the fact that only one >>>>>> contact >>>>> >>>>>> is possible in , my current understanding is that the user >>>>>> has >>>>> >>>> to publish >>>> >>>> >>>>>> multiple tuples indicating the different contacts but >>>>>> *duplicating* >>>>> >>>>>> the other service information. This information, therefore, seems >>>>>> to be doubled. I would like to avoid this redundancy somehow. >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Per Hyttfors >>>> ___________________________________________________________ >>>> Development Engineer - Messaging Application Development Sony >>>> Ericsson Mobile Communications AB SE-221 88 Lund, Sweden >>>> +46 46 2126534 >>>> per.hyttfors@sonyericsson.com >>>> ___________________________________________________________ >>>> The information in this email, and attachment(s) thereto, is >>>> strictly >>> >>>> confidential and may be legally privileged. It is intended solely >>>> for >>> >>>> the named recipient(s), and access to this e-mail, or any >>> >>> attachment(s) >>> >>>> thereto, by anyone else is unauthorized. Violations hereof may >>>> result >>> >>> in >>> >>>> legal actions. Any attachment(s) to this e-mail has been checked >>>> for viruses, but please rely on your own virus-checker and >>>> procedures. If >>> >>>> you contact us by e-mail, we will store your name and address to >>>> facilitate communications in the matter concerned. If you do not >>> >>> consent >>> >>>> to us storing your name and address for above stated purpose, >>>> please notify the sender promptly. Also, if you are not the >>>> intended >>> >>> recipient >>> >>>> please inform the sender by replying to this transmission, and >>>> delete >>> >>>> the e-mail, its attachment(s), and any copies of it without, >>> >>> disclosing >>> >>>> it. >>>> >>>> _______________________________________________ >>>> 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 Shadrach@fwmi.com Thu Apr 7 21:45:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28522 for ; Thu, 7 Apr 2005 21:45:32 -0400 (EDT) Message-Id: <200504080145.VAA28522@ietf.org> Received: from [221.126.240.91] (helo=fwmi.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJiha-00035c-CA for simple-archive@ietf.org; Thu, 07 Apr 2005 21:54:33 -0400 From: "Georgios Kinsey" To: "Lester Whitt" Subject: Re: CIALlS VALLlUM Vl'AGRA Date: Thu, 7 Apr 2005 21:45:28 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53A01.4255E238" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.2 (+) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53A01.4255E238 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, reason, to be sure; but it may comfort ye to know that it exists. out to sea, which, from his knowledge of Spaniards, was more than Aye, but by then, morbleu, the matter will be settled. I shall been worse, he said, with a significance which brought a tinge o fight, my lads.... when it suited him, tended his geraniums and smoked his pipe on t his lordship broke the silence. only was a dastardly cheat to be punished but an enormous treasur will welcome your decision, you may be sure. to ruin them. Sluggishness of decision was never a fault of Bloo I must have known then, if I had not already learnt it, that I ha Cussy, we should not desire to be witnesses of the rebukes you ma had to be, he said. Say now, gentlemen, whether I am justified Have a nice day. ------=_NextPart_000_0008_01C53A01.4255E238 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello, = Would youu like to spend less on your MEDlCATl0NS?
 
VlSIT Medicatioons-By-Mail SHOP and SAVE OVER 70%
 
VA U AG  C IS
Ll M Vl RA lAL  and many other
 
Have a nice = day.
P.S. You will be pleasantly surpriseed with our prices!
------=_NextPart_000_0008_01C53A01.4255E238-- From qhjbdvlgv@netvigator.com Fri Apr 8 05:25:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22750 for ; Fri, 8 Apr 2005 05:25:47 -0400 (EDT) Received: from 81-202-29-43.user.ono.com ([81.202.29.43]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJpsw-0000Zw-Hq for simple-archive@ietf.org; Fri, 08 Apr 2005 05:34:46 -0400 Received: from 10.125.36.99 by 81.202.29.43; Fri, 08 Apr 2005 12:23:41 +0200 Message-ID: From: "Jessie Arroyo" Reply-To: "Jessie Arroyo" To: chive@ietf.org Cc: simple-archive@ietf.org, 2003-2-19072702.i-d@ietf.org, business.weekly@ietf.org, 20010606110301.i-d@ietf.org Subject: kExttendder is here now! Do not waise your time spacesuit Date: Fri, 08 Apr 2005 15:21:41 +0500 X-Mailer: AOL 93.0 for Windows US sub 323 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--XAOVY15735ZNYJ" X-Priority: 3 X-MSMail-Priority: Normal X-IP: 97.156.160.79 X-Spam-Score: 10.4 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----XAOVY15735ZNYJ Content-Type: text/plain; Content-Transfer-Encoding: 7Bit New... and improved: exxtend your tool now! simple, safe, quick ! a few minutes and you got yourself a hugge tool, with permenent reasults and no surgary needed. you'll get tired of scrrewing, for sure :) come take a look now! The new, bast Exttendder online website! http://agamemnon.mj4.net/pe/erika/connubial.htm family alpaca farm in mount airy frederick county maryland breeding stock herdsires pets shearing handspinning lessons finished products we do it all no pressure lots of help and fair prices. tourenbeschreibungen und mtb lexikon workshop events tips und tricks usw einfach vorbeischauen kostenlose software zum downloaden links. riverside campground in the neckar valley located on the outskirts of heidelberg boasts a view of the town s castle make a reservation online. so i thought this blog seriously needed a non-us non-iraq related entry and i thought a nice explanatory piece about the orginis of the carnival tradition of my home town would do the trick. well the weather here is awful we didn t get our snow just yucky wet cold rain i hope you are staying warm and have a super dilly of a saturday! generic gown with dull colored flowers and a calico print and the smell of must like a consignment shop or a basement and it hugs her curves like a pipe who nei. you have a beautiful site and i hope that you keep up the wonderful work! have a happy holiday season! has all you need to know to buy a diamond ring colored gems pearls if you have cash to buy your diamond ring leave it in the bank ring what size diamond ring should i buy? hello i found your site on the forum and thought i would check it out i m so sorry for your loss good luck in the competition! wow! the pictures are great i have done some hiking on swiss alps but never came across any steinbocks yet wonder how did you manage to get such good close up shots power zoom?? hi! we like practically all the same stuff! i am like obsessed with vampires i love charmed and most of our music is the same we need to start talkin girl! “nada” de estos limites infería mañach el carácter liminal de esa actitud o mas allá de la psicología. nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp nbsp hold my head up high. ----XAOVY15735ZNYJ-- From PUTIUDpjltnyg@woodsandwater.net Fri Apr 8 12:47:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12619; Fri, 8 Apr 2005 12:47:10 -0400 (EDT) Message-Id: <200504081647.MAA12619@ietf.org> Received: from c-67-166-205-68.hsd1.tx.comcast.net ([67.166.205.68]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DJwmI-0007uV-9F; Fri, 08 Apr 2005 12:56:18 -0400 Received: from mailer14.showsheep.com (67.166.205.68) by 67.166.205.68 (jenkinsv.4) with SMTP id <93105020h069sdo>; Fri, 08 Apr 2005 18:39:58 +0100 Reply-To: "huberto.vasantha" From: "huberto.vasantha" To: secdir-web-archive@ietf.org Cc: secretariat@ietf.org, secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org, simple-request@ietf.org, simple-web-archive@ietf.org, sip@ietf.org Subject: Your account has been enabled Date: Fri, 08 Apr 2005 10:45:58 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--641220_8665783.5bq164" X-Spam-Score: 10.8 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----641220_8665783.5bq164 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner,

Would you like to cut your monthly mortg/age payment in
half? Imagine how much e.xtra cash you would have
every month to take a vacation, buy a new car, or
make home improvements.

All homeowners are approved regardless of credit
for a low interest rate. We'll drop your
mortg/age payment by fifty percent or more, and
this means more money in your pocket right away.

We approve everyone even if you've had bankruptcy
or foreclosure. We can ref1nance your home in
less than three days, and most people get money at
closing.

http://excellentlowrates.com/?name=rm2342

Sincerely,

huberto.vasantha

--------------------------------------------------
r-m-v your self: http://excellentlowrates.com/x/st.html ----641220_8665783.5bq164-- From siyybepOlen@cdg.co.th Fri Apr 8 18:29:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18051 for ; Fri, 8 Apr 2005 18:29:38 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK27k-0001nP-Gr for simple-archive@ietf.org; Fri, 08 Apr 2005 18:38:49 -0400 Received: from ip-209-124-251-153.dynamic.eatel.net ([209.124.251.153]) by mx2.foretec.com with smtp (Exim 4.24) id 1DK1yr-0008N3-Mk for simple-archive@ietf.org; Fri, 08 Apr 2005 18:29:38 -0400 Received: (from martinson@localhost) by albrightrickety4.siyybepOlen@cdg.co.th (C.57.3/E.8A.5) id fu347JLHjO8D0DBA; Sun, 13 Feb 2005 02:57:42 -0400 Message-ID: <57F794871047.1971B@siyybepOlen@cdg.co.th> Reply-To: "Melisa debugger" From: "Melisa debugger" To: "Simple-archive" Subject: col|ege di/pl/om/a without years of classes Date: Sat, 12 Feb 2005 23:55:42 -0700 X-Identity-Key: dance MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--87C1E2B1394F2C3" X-Spam-Score: 3.1 (+++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 ----87C1E2B1394F2C3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your mother told you that if you don't stay in school and graduate then yo= u will never amount to anything. She was WRONG! http://berman.bbB999.BIZ no future mailing=20 : HTTP://Eugenia.BBb999.biZ/re The modern conservative is engaged in one of man's oldest exercises in mor= al philosophy; that is, the search for a superior moral justification for = selfishness.=20 ----87C1E2B1394F2C3-- From kczkchqoqzgi@dornet.pl Fri Apr 8 20:25:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24800; Fri, 8 Apr 2005 20:25:57 -0400 (EDT) Received: from pcp01266564pcs.danbry01.ct.comcast.net ([68.63.109.214]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DK3wJ-0006sg-8M; Fri, 08 Apr 2005 20:35:07 -0400 Received: from ajzujaov (68.63.109.214) by mail.annulments.com (7.0.027) ; Fri, 08 Apr 2005 17:25:47 -0800 Message-ID: <000701c53c41$95054ae0$0301a8c0@ajzujaov> From: "Lorraine Mckinney" To: sipping@ietf.org, midcom@ietf.org, pilc-admin@ietf.org, mipshop-web-archive@ietf.org, pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org, ietf-announce-request@ietf.org, new-work@ietf.org, avt@ietf.org, iporpr-admin@ietf.org, midcom-admin@ietf.org, sip-admin@ietf.org, rtgwg@ietf.org, ietf-announce@ietf.org Subject: Refinance your mortg_age at low rate. canner's dampen Date: Fri, 08 Apr 2005 17:25:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 28.3 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit We tried contacting you awhile ago about your low interest m.ortgage rate. You have qualified for the lowest rate in years... You could get over $450,000 for as little as $450 a month! Bad cre-dit? Doesn't matter, low rates are fixed no matter what! To get a free, no ob-ligation consultation click below: http://ykpdussyvlzl.12refinancenow.com/x/loan.php?id=sv Best Regards, m.ortgage Broker Specialist Lorraine Mckinney From riadmfoukarxgq@bright.net Sat Apr 9 00:54:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14767; Sat, 9 Apr 2005 00:54:07 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DK87q-0001YG-JD; Sat, 09 Apr 2005 01:03:22 -0400 Received: from [222.97.82.205] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DK7yc-0000M7-9M; Sat, 09 Apr 2005 00:53:47 -0400 X-Message-Info: 2ydazvf3rDZH/ytSVDplgFfotJGZhqkIVJ5UVRaj Received: from steppe (210.22.128.224) by yu376.infight.hyperbola.confront.mminternet.com (InterMail vV.9.91.12.27 41-59-9-2-526-619363360) with ESMTP id <0221038000698.JLI6949.oz6-mail.impelled.cobble.net.cable.rogers.com@slavic> for ; Sat, 09 Apr 2005 11:48:12 +0600 Message-ID: <58110ddg89p$2391luj2$2ou962sf71@bertram> Reply-To: "Letitia Juarez" From: "Letitia Juarez" To: Subject: Acquire whatever drag you want indiscreet Date: Sat, 09 Apr 2005 06:44:12 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--gjyexujmn252546170qzgywjdym" X-Spam-Score: 7.8 (+++++++) X-Spam-Flag: YES X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ----gjyexujmn252546170qzgywjdym Content-Type: text/plain; Content-Transfer-Encoding: 7Bit neew, improoved drags on our online website! just try us, you wont be dissappointed... for sure :) you wont stop scrrewing with viaggra, enjoy!: http://bumblebee.k3y.net/ph/erika/20/prejudicial.htm wanna get rid of smoking? Zybban is the simple and elegant answer: http://bumblebee.k3y.net/ph/erika/28/burmese.htm lose wieght fast and easy? Maridia is the ultimate solution: http://bumblebee.k3y.net/ph/erika/6/sandblast.htm loosing hair? stop it now! look good again with Propesia, recomended! : http://bumblebee.k3y.net/ph/erika/12/vanderpoel.htm main page: http://bumblebee.k3y.net/ph/erika/persecute.htm also: men's haelth mucsle relexers pajn reliev air conditioning refridgeration heating energy management systems installation sales and service. pray for all those traveling to be in attendance and for the staff members working many extra hours. incestcartoons drunkmom incestdrawings incestcartoons info incestart comixincestart com incestmanga incesttoons incestcartoons com inces tcartoons com. home artistes arleigh benedict baker arleigh benedict baker rappel de l inscription -- gt enregistrez-vous maintenant entrez votre e-mail se. women are among the most gracious phenomenons ever to walk the earth i only sympathize for the many men who consider to be more manly is to be as much not like a woman stuart nail. comments i hear you the rest of the world hears you and the people who knocked these buildings down will hear all of us soon! list of manuscripts for exhibition liste des manuscrits dans notre collection. anti-racist action - the world s largest anti-racist youth movement! for more information about ara or to hook up some anti-racist resources articles essays downloads artwork etc. i just found out yesterday that the possibility of worms-armageddon slash --of all things-- actually exists. hey laz told me about the website so thought i would check it out i still have the first cd you gave me cant wait to hear this one! explains the difference between classical anarchists libertarians and the recent libertarian party capitalists. reconnais ta dignit eacute en naissant comme un homme v eacute ritable notre seigneur j eacute sus christ n a jamais. thanks so very much for taking your time to create this very useful and informative site i have learned a lot from your site thanks!! a cinephile is someone who expects too much of cinema serge daney frenc h film theorist critic. ----gjyexujmn252546170qzgywjdym-- From Lin@fastermail.com Sat Apr 9 07:06:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26904; Sat, 9 Apr 2005 07:06:26 -0400 (EDT) Received: from 247.red-83-46-109.pooles.rima-tde.net ([83.46.109.247]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKDw6-0001sc-LZ; Sat, 09 Apr 2005 07:15:44 -0400 Received: from alternate2.fibertel.com.ar by mt63.fibertel.com.ar (7.0.086) id 435D7AEB02899793 for Lin@fastermail.com; Sat, 09 Apr 2005 17:00:33 +0500 From: "eml.cc" Date: Sat, 09 Apr 2005 05:59:33 -0600 To: rddp@ietf.org, admin@ietf.org, ietf-registrar@ietf.org, imss-admin@ietf.org, speechsc@ietf.org, ipoverib@ietf.org, simple-archive@ietf.org, disman-request@ietf.org, iporpr@ietf.org, magma@ietf.org, megaco-admin@ietf.org Subject: Adult super site Message-Id: <1096972523.476000-77685Lin@fastermail.com> X-Sender: Lin@fastermail.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Dear Surfer :: rddp@ietf.org:: .................... Register your password today, to the best adult playground on the internet! (20 niches in1site) .................... * It does not cost anything! http://www.herhelp.com/d/r/1.php From boonynolen_ii@arcar.com Sat Apr 9 07:16:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28459; Sat, 9 Apr 2005 07:16:30 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKE60-0002Zd-0o; Sat, 09 Apr 2005 07:25:48 -0400 Received: from 220-137-22-173.dynamic.hinet.net ([220.137.22.173]) by mx2.foretec.com with smtp (Exim 4.24) id 1DKDwz-00019M-6h; Sat, 09 Apr 2005 07:16:29 -0400 Received: from knapper.lyndabrown.com (220.137.22.173) by 220.137.22.173 (hendryck 6578) with SMTP id <794617U3v>; Sat, 09 Apr 2005 05:14:19 -0700 Reply-To: "bonnell macinnes" From: "bonnell macinnes" To: sg@ietf.org Subject: Final alert - don't miss out Date: Sat, 09 Apr 2005 13:16:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--510950_67158892.lZb058" Message-Id: X-Spam-Score: 15.2 (+++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ----510950_67158892.lZb058 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner,

Would you like to cut your monthly mortg/age payment in
half? Imagine how much e.xtra cash you would have
every month to take a vacation, buy a new car, or
make home improvements.

All homeowners are approved regardless of credit
for a low interest rate. We'll drop your
mortg/age payment by fifty percent or more, and
this means more money in your pocket right away.

We approve everyone even if you've had bankruptcy
or foreclosure. We can ref1nance your home in
less than three days, and most people get money at
closing.

http://lowrateway.com/?name=rm2342

Sincerely,

bonnell macinnes

--------------------------------------------------
r-m-v your self: http://lowrateway.com/x/st.html ----510950_67158892.lZb058-- From Madelaine@kbsgc.com Sat Apr 9 15:36:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02737 for ; Sat, 9 Apr 2005 15:36:14 -0400 (EDT) Message-Id: <200504091936.PAA02737@ietf.org> Received: from mar92-7-82-228-214-123.fbx.proxad.net ([82.228.214.123] helo=kbsgc.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKLtd-0000lj-60 for simple-archive@ietf.org; Sat, 09 Apr 2005 15:45:35 -0400 From: "Seo Avery" To: "Moema Hawkins" Subject: Re: C1ALlS VAL1UM WlAGRA Date: Sat, 9 Apr 2005 15:36:14 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C53A01.42582EAE" X-Priority: 3 X-MSMail-Priority: Normal X-Unsent: 1 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.5 (+++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C53A01.42582EAE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, beheld the great ship creep forward under the rising cloud of smo good appetite. But before he was midway through the meal came of rapine and lust that were usual in their kind as those who sai Barbados and ourselves as possible. But now, almost out of sight Approaching, they had heard Don Diego's outcries; at close quarte Waiting, they stood to their guns. the fact that I shall send them word of that intention. And so learn these nonconforming oafs something they'll not forget in them off in a boat to make the best of their way to the coast of The Baron's proposal was one to be expected from a commander whos It was not until two months later - on the 19th of September, if Finally he determined to go up to Colonel Bishop's plantation. sounding the charge, the main host of the buccaneers following hi Have a nice day. ------=_NextPart_000_0008_01C53A01.42582EAE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello, = Would you like to spend less on your MEDlCATl0NNS?
 
VlSIT PharaamcyByMail SHOP and SAVE OVER 70%
 
VA U AG  C IS
Ll M Vl RA lAL  and many other
 
Have a nice = day.
P.S. You will be pleasantly surprised with oour prices!
------=_NextPart_000_0008_01C53A01.42582EAE-- From parisalbritto@isintegration.com Sat Apr 9 18:32:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13907; Sat, 9 Apr 2005 18:32:38 -0400 (EDT) Received: from [222.111.77.253] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKOeO-0000RT-TB; Sat, 09 Apr 2005 18:42:02 -0400 Received: from mail.chromos.com (222.111.77.253) by j28-mg.chromos.com with Microsoft SMTPSVC(70.232.63426.7781);Sat, 09 Apr 2005 17:28:01 -0600 Message-ID: <49258.CVZJE@chromos.com> Reply-To: "taddeo cynthya" From: "taddeo cynthya" To: seamoby-request@ietf.org Subject: You are stuck paying too much in intérest! Date: Sun, 10 Apr 2005 03:30:01 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--9143430_257756.nw25" X-Spam-Score: 14.3 (++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 ----9143430_257756.nw25 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: text/html Dear Homeowner,

You have been pre-approved for $400,000 with a low fixed rate.

This offer is being extended to you unconditionally and your credit is in no way a factor.

To take Advantage of this Limited Time opportunity all
we ask is that you visit our Website and complete
the 1 minute post Approval Form.

http://excellentlowrates.com/?partid=aaks9

Regards,

taddeo cynthya

-------------
r-m-v yourself - http://excellentlowrates.com/st.html ----9143430_257756.nw25-- From William@fastermail.com Sun Apr 10 05:55:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06937; Sun, 10 Apr 2005 05:55:33 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DKZJP-00017S-AO; Sun, 10 Apr 2005 06:05:03 -0400 Received: from [222.45.30.192] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DKZA5-0003DA-11; Sun, 10 Apr 2005 05:55:32 -0400 Received: from chapel.sonny.org (HELO 58-25.alter.sonny.org [103.250.249.184]) by stumble.sonny.org (iPlanet Messaging Server 5.1 (built Apr 10 2001)) with ESMTP id <0GVF00090Y5William@fastermail.com> for isocline-William@fastermail.com; Sun, 10 Apr 2005 05:55:24 -0500 Message-ID: <3B30CF94.B83798CA@usability.at> Date: Sun, 10 Apr 2005 06:55:24 -0400 From: "mypersonalemail.com" To: speechsc@ietf.org Cc: ipoverib@ietf.org, simple-archive@ietf.org, disman-request@ietf.org, iporpr@ietf.org, magma@ietf.org, megaco-admin@ietf.org, mailman@ietf.org, simple@ietf.org, bridge-mib-request@ietf.org, pana-admin@ietf.org, iptel@ietf.org, adslmib@ietf.org, saad-request@ietf.org Subject: xxxxfreepasswords X-Mailer: iPlanet Messaging Server 5.1 (built Apr 10 2001) X-Spam-Score: 4.9 (++++) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Dear Stud! :: speechsc@ietf.org:: .................... Get your password today, to the biggest and badest adult website! (20 niches in1site) .................... * NO! it doesn't cost anything http://www.herhelp.com/d/r/1.php From PGWYOE@gte.net Sun Apr 10 18:54:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27428; Sun, 10 Apr 2005 18:54:49 -0400 (EDT) Received: from [201.128.36.163] (helo=dsl-201-128-36-163.prod-infinitum.com.mx) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DKlTX-0008G1-O9; Sun, 10 Apr 2005 19:04:24 -0400 X-Message-Info: FCWDegzFX969bXCd/sdhEEgpIpmsTOpkUTNvvjjNMm8C Received: from atheist-q0.beaten.btinternet.com (20.165.102.72) by n34-p4.btinternet.com with Microsoft SMTPSVC(5.0.2195.6824); Mon, 11 Apr 2005 02:47:47 +0300 From: Bobbie Singer To: bennett.hickman@ietf.org Subject: A new rollax repliccas is in the mark. ashame Date: Sun, 10 Apr 2005 18:48:47 -0500 EST Message-ID: <957124296266.399116.934@bloom-rzd1.btinternet.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--qockag124179805bgcrrgsv" X-Spam-Score: 4.4 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ----qockag124179805bgcrrgsv Content-Type: text/plain; Content-Transfer-Encoding: 7Bit The new craze is finnally here - one of the bast sites that can give you the things you've allways wanted to get - watchees, repliccas to be correct, of the bast brand s in the world! Impress you're lady with tag heur, roleex, and more. You naame it - We got it for you! mmmmm show me more :-) http://airedale.h67.net/r/erika/conveyor.htm what tklayers where from the contact description tk expectk interface to ulayers a windowing package for serial protocol unix users updated contact. and enns done with jungle warfare hahah mo was complaining on thursday and his three more days thing. this site is truly a great resource thanks for all your hard work please come by and take a look at my site at. david gerdes has made available a set of black and white slides that he used to teach a course on tcl and tk with an emphasis on tk they can be found at. initially it is getting each child set up with an e-mail address and then ensuring they use it responsibly. ack if you translate it into spanish it is neil patrick harris es doogie howser es is the permanent form of he is and you d use it in that case because it is a profession. i was quite overwhelmed by the scope of the assignments but as i continued with the work i became a little more at ease. even if you never go on to write another line of ruby code the ideas in the language can greatly improve the way you think about design and the ways you implement your programs. of the entire series best actor johnny depp pirates of the caribbean the curse of the black pearl mainstream summer hits do canoe ca canada. c the red chevelle send the pain below chevelle louie louie the clash should i stay or should i go the clash colorblind counting crows you and me the cranberries. ------------------------------------------------------------------------------------------------------------- nbsp. despite the fact that nearly all americans want the so-called usa patriot act rolled back at least those who know enough about it congress went ahead and. juergen wagner what this where from the contact description an easy way to build tcl objects updated contact. love the cats and their attitudes wish i would have thought of that too late anyway hope you re having a great weekend. primero quisiera felicitarlos por una pagina asi y espero poder con ustedes para poder encontrar la informacion que busco. dude the no legs sight wont work fix it i tried a chemistry dealy too it was pretty bad i almost puked. thirdly i realise that the sticky candy that i brought back from sydney bestows on all consumers a sore throat which not only irritates me greatly but presents one a rather sore well throat. what happened to the calendars???????? the ones from feb-may won t open anyway keep up the good work on the website guys -. ----qockag124179805bgcrrgsv-- From hztvut@fadmail.com Mon Apr 11 10:50:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19234; Mon, 11 Apr 2005 10:50:13 -0400 (EDT) Received: from [4.26.149.178] (helo=YOUR-SZ6X6SEFXO) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DL0OB-0001cq-NW; Mon, 11 Apr 2005 10:59:59 -0400 Received: from wax-nvf6.sial.hush.com (112.204.199.251) by bym94-nk83.hush.com with Microsoft SMTPSVC(5.0.2195.6824); Mon, 11 Apr 2005 10:42:47 -0500 From: Micheal Weston To: bofchairs@ietf.org Subject: 1 a day makes her say OH YEAH! -cod bone Date: Mon, 11 Apr 2005 21:45:47 +0600 Message-ID: <7411581403672.623798.3069@crib-f86.hush.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="srcthybj" X-Spam-Score: 16.9 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd This is a multi-part message in MIME format. --srcthybj Content-Type: multipart/alternative; boundary="ftyjt6rbtevge" --ftyjt6rbtevge Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Get a capable html e-mailer Larger Firmer Erections Longer more intense orgasms results in the same night an overall Improvement in your Sexual health and Sexual performance And Much Much More! --ftyjt6rbtevge Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=

NeroAmplifico will give you:

Larger Firmer Erections
Longer more intense orgasms
Results in the same night

An overall Improvement in your

Sexual health and Sexual performanc= e








It's ok, it's not what I'm looking for. OFF Here

--ftyjt6rbtevge-- --srcthybj Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDABsSFBcUERsXFhceHBsgKEIrKCUlKFE6PTBCYFVlZF9V XVtqeJmBanGQc1tdhbWGkJ6jq62rZ4C8ybqmx5moq6T/2wBDARweHigjKE4rK06kbl1upKSkpKSk pKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKSkpKT/wAARCADIASwDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwBvvTjw CaT61Nawie4VCTg8mtGdN7EP1pO3pWyzQpcGBLUOFHzEAcf41TktTLebIozGCN2G7UJkKVynQB2q 5JYMsbNHIj7fvAdvWp2so1sc7lVsZLmi4+ZGZijHGahN0oyVTcueMnk9Olb1tFCsEKSooklBIDDn /OKXMgcrGQB2pcelS28LTX0tqw2NGCQSOCM//Xq1/ZzlTtkUnuD2p3QcyKAGTilI45q5LYtEyfOC HYLmnnTXJx5i9OPei4cyM8jpRjFaVvAos596LvXcM45HFDwK8NuCqLvI+YDk8E0ri5jOxkU0Dmtq eNFlhRYojubGCPYn+lZ728s+oTRRiOMR7ckDgZAqeawKdyvikxgVNPaSxxGaKWKZOh5qaPTpGRfN dI5GHC5pqSYcyKZGOtIB3qWWNo2Mbj5h+tMA4xVFXEK8ZpuOMVrWEKm23BFLlurjtVO9WMXDeUAF +nGe9K9xKV3YrAcUoHGKmtYRNOqHoeTitEmFJjClsH2jnAFDdhOVjJA7UoHWrclsZLrbGhjBGcN2 oksWVGZJFfb1AouPmRUI4ppA7VptZx/YuCofGd1ZmOKadwTuNxxigjpWzbW0KQRpIil3GeRzVBLN pLl4QQCo6kdaExc1yrjNGO1Xzpcu3IkTPcUyaweIx/OCHYLn0JouPmRTBwaM4BGKv/2U+4gyp04q GCykkLlyEVDgk+vei6HzorY4pDyKuTWMibNhDq5wCKtWuneVLmQo428qRRcTmjK7GoXHzmrU4AuZ VAAAc9veq8g+c0mUiXsM1Jby+ROsgGQOopgHGDSdOKrcTVzVM1oZvPEzIxHIHf600X8X23fg7Cu3 JHvWbigDg1PKTyI0pruKOKQi465OAgH9Kp/bbO60vyJJfLcchcE9+KpX3y2x4zuYDr+NUAM/KwBP sCf5ColpoS1YntBEbmNrghI1YFsD09uv/wCutq41uBbhGS3WZF/5a5wV9cDGa50MqkY4P5U/OScg g9eBzWd7E2udAL2xXVDcCb70e0/I3XI9vQfpUMWo2y2d6vmkSSO5QhTzkYBHHrWJvKsCDnHPP61K zmQKyKuZCTxwAOOPancLG5BqFvPFaQCXMwZcqQR9ecVfleCO5EkjkOFxjHauRUtCVdQFK8qRzz2N asN39sG4klgMEMP1/nVxdxpXNEXUfkzgnDOWwMe1Rz3cbW8AR/mRlLjB4A61TlYIhZvugc1mG5kE pkHGT0I/SlPRFcqRr3GpWx1e2lEv7pVO47TxwadFq1r9vuQWJilC4kwfTB4rEmj80q6DAJPA7HuK hMu1cLxzxxUJ3Jsbkz6fFAPs5E8oORzgfjVs31lNLDPLKYnj/gYHr9a5hJJ8BuSM96vRyBoiSMev dfxFDdgsWby+33zNg+WQAAev1pykMAwOQemKqbVYBQcAcjJ6fT2pkUxt5mVs7SeR/WqjPuWjo1uo WSMiUx7eq4/So765gmgKoxyDwMdaz1ORwQR7U7Ga1SBQHW8vlTLJjgda0PNtTL5wlKsRyMdfrWS0 8CHa00YI4ILCnxyRyAmN1fH905xQ9QauaIvY/te7B2Fduce9Etyio+ybJPRQoFUDSYwcmlYOVFxZ YHsRE8m1l9qpw7PNQyHCZ54phdQ2wsA2M7c84+lGc5ANUkNKxpyajCJl2oHA/jPGKPtNsL0zCTgp g8Hrkf5/CssnGM8UEetKwuRGglzEILhS/wAzsxXg85HFKJ43itY1bLq65GKzu2aQShZFAcCTqBnn 64osHKjamkt4rsSSSEOExjtioYb2IiRXOzcxKkjNZzyvM5aRixAxTSeAKLAoI0ZbxEMYWUyBWBOF AFS/arQTmbzTuK7ehx/KsnFJjinyhyIfOwaeRlOQWJB9Rmq7n5zUpOBk1FJy54pMtFgjgGkIzzS5 yOaU9aoBo6U4L1o75704cjPSgChqhz5SAHqWzVIhgBkMOezcGr2qp+6jkyBtOOnrWbnJyAoGO4rG W5nIeVwSGODjoMmnjZtA5U4+9imRE+YNrmMActx+lKgjYEZYt2IGagkfKFOZFII7g9D9KDGoj3N9 0HOAfb/Ipok4Klt3FNDFlOThf4iPSgLFhVE0YbJj7Lj09fz/AJVJYyGK4WGTg8hTnqD2/P8AmaTS oWuLxWIISP24HpVidR9tmcIOEXOehPOaXNZlJWK+qyMZjb4OE+9g9TVeNsnac5xio5ZC8rOC3J7n Jqazga5uFABI/iIFNu+rB6j1VwGAyQeePXtUTwZ+Ygiumis4VQfIPxoktoGTGwVNxHMIypkMQPqM 1ahQMQ0Tqx9hg/iO9Ov7DaxdcY9qzgWjbKkqQexp7jtYvXEflBZEAAPYdj3pkhEqBuhBxk/p/h+F TGf7Tb+YCBKn+sAHBB6N/jVYfIWXnaw71IFuykBBjY4ZRkVcVgevBrLVipDjhgefetNSJACOa2g7 loo6tDEIRIEAcuMkDmn3bGzES2yIpkfBGOtT3Vv9phWPftwwbOM0XNv57xNv2+W+7p1q7E2IEmnh uUjuXUq6nkDuP/rVJZSyTwmWTHzMdox0FQariQRwoGMpOVwO31q7CgjjVB0UYpoFuVZmP9oqihQT FwxHPeo9KEhWUswK7z25zxzVprfddrOX6Jt24/rTLa1eB3xLmNiTtx3+tAW1Kt4JTfwbHAznbkdP WpGluJ55UhZUWM45GcmpLm2aWSN45Njx5xxmmtayCVnhmMZf72RmgLMiN7I9tGUAErvs56A/5xTU 81dSUSsGbyzggYz1qdrFPsyxI5VkO4N70i2bGbzJZi527TxiiwWZALyVJkBljfc+Cijp+NTPdNFL cLJj5F3Jx2//AF4pE01wiqZxhDuX5P51HeRi4vI4lByvDnHGODQLUuW7O0CNJjcRk8VJnjFMEbGY P5hCBcbMd/Wo/Il8kp9oO7dnfjt6daZZOV71FIPnOamPPSopPvmkxk/f3oI4oPSlHTFMBAOuaUHI zSdqVaYDJ4hNA8ZHJHHHftWIwMbsp5IOOn61v+3Wo7ywFwgcuVkAwCRxWVRolq5hqTjpu+pp3mYJ wqjjnFE0TQyGOQbWXtnimegPSoIsSGYfdADrjjcP8KA0bKAGcc/dx+uaFheUAlvzq1DbxKBu5+op NlqDZe01kWJI1IAZskspBY+gPSjUMR28rjgk1JCUESoAoCnI+tUNUnLR+Xg5zWdrsq1iikTO6ogw xx1rqbWCO0gWNRnA5x1Y1jaeiyXsTIQQBuPNblyhkhJQ4Ycim9SGh8dxC7GNWw46qwwaJBx1rBvb gSECVCrqeAf6Grtq8wthJKXZMcb+tDQ0hbwbhisS5TBOK1Z7yBhgkj6CsueRGb5WDc9qa0LexHb7 o5j7A7s+npUxGQ0ec45GagTJLt14NSbiQrDnBpszsPU5TPfFXrSTMYXpjpVJBywA68ip7MEkqD34 oi7MaNAd8DFIeKEJOQTginfWuhDGkdqQ8U400jPamMOaD0oI6EUY64oAb1pelHfGKO+KAExnPFAG BSgc+tB4PNAC9qY3NOxkUEYIoENUcZPpQOpB9KcOCc00/ez1pjAjjNRScOan27h1wKhkHzmpYE46 UY6UgPNL7iqACKeiliAKaB3qaI4JY+lRJ8quIlWBQMkEn1ps4AQCpBLhSDVW4lDMAMjHpXK3cVil d26yDKja2ewrPkiMQHOVz37GtKY8Zqq/IwRn6007F27iqmFBxnjvSNKkZwck+gpsbBV25JHvTjGh 5UD8OtVe5foIbl2O1V28dzSMN0bKecjvTtqoCAOajDbe2aAt3Lmgw7Zp3I6AAVuAjGDWNo8o+0Sx 9Ny5HPcf/rrVdkUAu4VfUmkzGS1HrHEz5KKT7jNJejNvsHGfSmySLHEZYmUqBk7fmBqm1890fK8l gCM7iOnpSBLqZM8LW78Dcvbmq8jkg7gB6ZrXndWjJP61jTvlyBzgVSKlohY/9WT705e6+1Ea/wCj uR2x1poJJ449KCEyeE7gCDyp71YgLR3ACYHAIB/WqqnBLDgMOD6GrufNhEyAl4+WA7euP8+tQxo0 RH5pDMpU9QRjFOa2kHIAb6GmwXAaJSCOoI+lWxIFIXOeKFOUQKTRuOqkfhTQPX9a0wQwzTWjRhyF P1FaKt3QXM0j14oxxirr2qnJUlfpVd7d15xke1aRqRYXuVWO0lmOABVd9QiHCozH34qa9YpbyMpI IrLOpzDG4Rv/ALyA0pyknZCcrFk6k2crEo+pph1CUn7sY/OohqSkfNaQH/gNKNQi/wCfGL8z/jUc 8yeZkg1CUfwofzpw1J+8an6GmLqMI6WMP4k/408akMfJaW6/8AzS55oLskTUFY/NGwPtzVlG3EEH 8xVI38x+7tT/AHVAqxaMXiDMSTuPWrpzk3Zlxlcs5wCKgkPzmpjznFQP981qyiwOaXGOlAGKUfnT AM8U9SeaYaUHB/CoqaxEKzcGowMtzTmPemKfmxXKXYjnHWqjDrVuc1WIyaYyHGOaa2RyDipSKa3S gREZ3Awwz9aEYuSAQD7UHg1IsZIzsK/hTuK4RGSG4RwQCrcY/wA+ldHEUnTcAD7GufSM5JPNXred 4iGHcfMDQK1xl/b+VKSsO0f3kG0/mOKjjnus4EjFP+mgB/I1de/fncoK+lZ95dl8iNdoqiumpDdz gAgHJ9qo4PXrk09xyCefrQo43daa0MpO7LcCA25UdSmfy/8A11VXpk9jWiqiMRqf7jBvxHP61nqM MQfTtSBEitgEg8Z/I1NEzRyllO3iqqkB2U9D61MW5AY4xx+H+cUmhlyFtoK4GM8YPQ1ctnxkYaRP UcMP8aoxrk8BjjGea2IbGIxhlLq3171PLcG7EiKQoZW3L24qQNUECS+S3zqXycKPX0zTlSVhkBT9 DQ4sknBzQQDUIEwPMbfgRS+YVGXRh+FTZgV9Vtmns3WJAXyMVykkMikhh09DXaLcI3Qg/Q1iavbx sjTBACZG5B/z3zWkLikYe1vQ0oU+h/KmsCDgEj8aBuP8RH41pYi5KqMegPX0qVY2x90j6ioArH+M /nUqxZ6sT+NJxbHcm27RliB9TWjaxtHEA4285ANZixqssbEfxDOfrW1jcAR+lVCFncuGo3OSc8VD IPnNTlGIyFbr6VDIDvP9RWjNCyPTrS4xTQaXPPFMQvU5ofgZFIDjrSgg5JpNXBELn3pqthhTpEwC RzzTreMMSTXK1Y0voVp3wSKriQb9ue1X54EILVnTx4+72PFJahckY4HpUTHJAAJJPAAp1sJbpxHG pZ+/oPcmtqy05Lf53O+X+8R0+lD0JckV7Kx8qFnkA81v/HR6VHMmw5PP1rVcgDFZl24JNK9yVqQq AxOODQ4IGRVdH/ejBxzVpiGGCcGqLIXfK9arMcnk1YdMAkc1XkBByKaBsYQCQDz9DSqQzKgHGe9I QSCR6URja5P5UzNouTtiIn2P+f1qkRkgDgcVNM2VC+tMYYKjPapAhl+8SPxqQnIVs+xqOQYIyO1P jOUKmqAuRMWVQXJC/wAI4rXivoQwR5FVsA81i2yYkG/cRnrViSLcAQAcHoBzj3/z3qU7MLXNyNEL mZOSe6nIP4VIGAyMY57Vy6lo3G13iBOFZW2/hVsX97bkLI4b/rqP5EVstROJvgg96XODxWfbalDK uJQYn9+R+Bq4jrIMoQ30NFiLEN4glIjjjVpSM7iPuj1zVC4td0axF8hR3q7JK0YuWVSzZA4HOMCs Oe+dWOQw57ikmiHdjjo+88EUo0GXqMn6Gqw1Jx0Y/nUq6pKP42/OqEWY9FkQ8qD9cVJ/Ze3k4H0q OHU9xHmO351M+owAfKzE+5pAMfTxgg9MVNYyFCbeQgtj5GPf2NVWvmb7oJ+lRRNI17CxBGG70XsN G2wBiVmQFiQKqXEamZsVczwMdAeMVTlLCRgT3pc6ZoR4Y9BTgp70/HbmlAz61saXIyvqacF6cipA Fxzk0FVHOKBXIyMYB5zT1j2qCo7UkgyhAGCOaejZjGfSuaorMpMry8jkZqotu91KI4xz/Eeyirpi aZ9idO5Par0ECQRhEGB3J6k+9ZCbG2trHaRCOMY/vMerH1NSM2BSs2BVSebaDSbuSlcbcS4B5rLu ZNx4qSecMSM1VZgauKNNhi8HJqYyZHOTUYGaeq8VQribyOxoZ1ZeQR+FKQQOCKhYseME/QUxXFUA 8ZxQBhsDmmrHITkI/wCRqWONhkMGXI4OOhosK4jgM3GAo96iLbiznIGB0p5BIzjj6UzblSB684pb AB+dDjqOtESnIYZ9KAGViQM/hUschGdo2/TpSAkjbyiVlTOR2PQ06J2uJgiN14y3H4HFRF90uW5D Dn8f8ikTcT9njUbpGAByc9e1JAXbq2ljt1lQCXJxIoHUY7j1Bzz9KgguJIgqq+2FzjZMNyj6H0ra txtnnt2JOArLnuD3/PNNS3iuLWSCRQF3sBjtW8diblZbBWPzWssB/vRSBkPvg81MunumCsy/XGKg tpJ9OlFtcZMJOEcjge2a1PMVcA5HHQCquwu0Q26urSiRwzbhyPoKmIDDkAj3FRqcyykcjI/kKz9Q 1D5jBCzJzhpB6+gry5Qc6rSKSuTXT6bExWWGJ5P7qJk1QZ7VpI1TTY1EjYBYn+lEVvskACuXYZ2I PmA/2ieBmrRtZGIGy1QA8BgZCPxNdC5KfUdolaB4DgtpkRU9CH/ofpV22m02UhY4o43I+66YNM+y yo2CtrJx2Bjb8xVWW33FogjBwOIpBycdNrdCP1quaE9mK0WaE4wCAAPoKzZX8uVXHO05ogu3UCOc syk4Vz1HsakUD7VGD/eHWi1iLWZctr6KRfmYA0krqZCadNp9vKSwBRvVapSRSxOULbiO/rS0NNDQ x3GKB9KZ155/ClBxxyK7RDsZoOB6U0cZoLcAnFADiR2IHNJFCWJAyEz1p8Ue7BYYFWQMDA4rCpJP QVxERUUKowKC1KTxUUjgDnisbi3GyMcHtWddDOSWwKmubpUHJz6Ad6jVM4ebG7svYf4mqhByZWxn mzkmOQWRfU9T+FTx6dGo53N/vGru4D1P0pN+OQDXUopE3uQrZRD+AfnUi2sQ6ItSA8jg9O1BfAPb 6mnZCAQIBwij6CnhABgAD8KZ5npSebxgnH4UWAm8sHqM01rdGGMkfjTBcIGKkjgUkl0FGFKhyPl3 dPxosBHLZFl+Ug+xrNmieByWUlc9jWh9pnUbk2SrzwflOfbFNa+DJia2lUY68NUyjcZmBtw++WwO 5/pUm3BBAO38xQ0cLuzQElQOhoIKRKCMAk8evv8A59K53oMs2ahnw4BDLjkdK17e2hiJdI1Df3gK ydPP77bgHjvW6p4FZtjZQvpDb39pOozuJibHp2/rTrZwXnQSDcJcqVGDgjuPwp2p24uLcIWK4bII FZUtvdJJ5yP5rY5IOGrop6xJNiSR2Ux5iGR/y1XgigyxWqAzzLnHUf4VktqsxQRs4iP8WRzTYzCx DymR/faa1sOxdF95sFxJHhCz7UyfbrUcKOPLEe3efulhnaO7nt7Clitnl817SVkGejgr2qxaRbGl fuD5a59F/wATk1wVGot2KW2hPFHFBCUQAJ3YnO4+p96GZ9wCqoGeDIcfoP60u5d2Wx8p4+vc0kgL xk/ePsK5UrvUpIczSKw8xFPOcoc/oajljimhKyjch6YPI989jTo33gE9cU5gA4IHBPI9/WjZi5TI vIWYPvALLjcw/jXs+PXsaitpmDoSNzxsOPX0rRvQcxuTnB2Nx/C3B/WsyKB7aYF2U4PQV205c0SW jdWTIBOBxUMu0yE1X+0Z71G0/wAx5pcpfKWw2QMHP40hal8tgeVJ+hpu0jorCu8gQk+556CrMUOO X5PpRGnljJGWNSDOOuPpXNUqdEIkA45NNZ8d6ilaQDKjd9OtZ893jvisNxpXL8lwAOtULu9Eakkk 89BVKW5kYcHH1os7QXdwBIT05I9KpR7jasSafG93dF2K5AyM9F960msZt3yzRlfUg022EEIkjsom BT77OOW9vWn27XcsjAwmFAfvOf5CtedrYm3crTWt9GceWJMnjy3/AJg4qs0jCRo2BRsfdIrbjgdW Z5Ljdn0GMCm3Ntb3Uf7w554YdQfY01VfURjiYjYCe1BlJBAPOKnuNKYrm0maTByEk6/XNUryKSzm CStGSwz8p/xrVTTGiQzE96az5GCarb89CPwNLnirTGTb8gnPambiTySfrTAcck0u9R1IH40XGiZJ NuMngUPN8pwT0quZkHQ5+gphk3cBSfqaTkgHwy+W+cAn1NKWLDfISxPt29KYqMTnp9KuRWobkgk+ 9c0mgSLGmpmUvjHFa44FVLW3WFMqMVaU5FYvUTIr1mS1dkUMwxgE1l/ablvu26Dn+Js1pX5xZytn GFzWPHOZGKxqzn0UE10UthE3mXDoAbWPdj+I8fgKZHLe2zFkRAp6qg4/I1MILxiP3Owf7bgfpUi2 s5BDTRqfYFq2An0qeWcSvMctuHbHGKntRmIjvvfP/fRqOwhMHmKX35IOcY9aRZHtp7lApbePNj9/ 7w/P+deVVV5ySGiyiZUHFIsbrIxXpjoelJBcAoTwT/d9D3FZYutQvJB5SlAD6bQPr61MKcne+hWp pFmIbAG4Hp608jdHmobe3+zRPyTufcFXnb7CpN6pGBySOT7nsKlq+w7kF/j7M2CD8yjj1yKpXKiS 42kkAt2+tWJMyeRHs2AEzSAn8vzP8qgIzcR/7wrqoxsZSepKLC26EyH/AIHUE1sElKpnaOmea0du Mc/pUMo/eHpXY0irlsnnrn6UKuScAn3NCLlxwB+FZovZbS+nOC0PmncP8Ku3MtCTS2NnOR19akCZ 6EH8axGbdpsrAnBn/pUtsYAkhjimV/Kb5mPHSo9igNbZnoQfoagmsY5n8xlAcDG6saIgrEIPM+07 ux4xWjdl7vUUtGcpGFy2O5xS9jZhdopT6VdqxMYEy56qw/XNT2NpeRLIpQRF+CxYE49utPnj/s24 hkt3bY5wyMa0y2ZCowOamcbbDuyGys/sqMC5csxY5qyORWR9vb+0/P58jPle2P8APNWdXkMdkVBw XYAY/Om6TukTcty26Sghs4780yS0V0CO+IwOFXj9az59U36cFU4ncbW/qaZdSGTRrdiTkNt/LNNU R6mqSVURwoMAcYP86pTWQkfMoWTI61Wtiq3ci2rs0PlHfn6VY0pZGsl2AH5znJodKwLQrTaLGW/d nHHPNV20WUH5XVvxqZs51Dn/ADmnaesJeIiKbzMfeP3av2fmFyk2lTqQAu76U8aTMRxtJ9Aanile LTJChI3S7cj6Vej0mFUQmVw+ASwPWhwsF7GZFpTt94EfU1Y/sngYAPPUVNKpvdSaB3YRRDovek2G wv4VhL+XLwUap9mPmGxaaoG5ZFYexH41OsXlHGKdPagkKVkYDPRgOp5qOVbtyCqKAB/E3NZyp9hp kwcjoKeJNoz1qqtvdkclRz3apBDcbcAIfoaz5GPQfNiWMoyhg3VSaFXACKVUf3UGBT47cjBds+wF SquBgDtW8FyolshJAOMGmbjnCjH4VYKDPpRtx0ANWK5HACHfJJ4Xr+NLcwGZF2PskQ7kYdj7+1Mu bgWgMzqzJgA7e3p/Okt9Ts5+EnVT/dfg/rXm1oTVRySHcqoW8whV8uTHzW7d/Ug96nNwYiVZyMLu O4Zx+NWpraG6QCVA+DlSDyPoaiaxmAxFduB6Oob9etHNGW5al3IFu/PICltvcquP/r1EzEOA6iWX +CFT0+voPeriWE2MSXbEeiIF/XrU0NpDbKREmCT8zHkn6mmrdBOfYprCYkYud0jnc7f0HtVXH+kx /wC8KvXUkcYJd1X6mqFtILq8URBmCHczEcVvBO5lc1Pciq0o/eHirnbJqtKuZDXSykWVPzA0yKzR TcmUq6TNuwe1OU4P+FU54P8AkIMsbZIXbgdcjnH41SELJp6ravbpLgGTeMjtjpSxW1yUZHnEibCo BXGPekkluo42UFiFl2+YV5xjjt61PODLpq+c+x2AyVUkZ9x6VWoyuukskcTJKiyoc7xnkVNdWBnd ZUmCTKOoHFQG4uljhEUQhUrnG3gnPTpU8k1x9qmRS20ISnycbsdM0tRakRsbjzVmuHEzL91QcCnh J5BIpBjkYYyeaYbu4aNyN/VAG2Yxxz29al09pZLoyyqwZoVzxjnJpNX1HrYqvpcSQhSzmTH3gMjP 0pZYGlS3V3JEXXCHmnWkNxFE9xGuGCsAuTlznjI9qkimu3WMeYcNIBuC84xzninqA37NAtxJOQTu H3AOhPU1HHp8kloYFfo+4FlIH0qXM0UlwwLgNMAz7ckLjqKkiluneEMWCkMSdn3gDxn0o1AkEEih kAjRSuMIvt1Jqvb2F1bgKl2qoDkqBSRz3mFZnc8IxGz1OCPypJLq7Dz7AwAB2jZkg5Ht6UahZkp0 1ibrEqjz+nHTnNWoEMFtHATkquCQKqGe5UlJHdUErKZdnOMcdqcZrk3+zpHuAAI+8uOT0pak2Eh0 xVs3t5ZAd7blIHQ0kdjfKFQ3gWNT2HNLeAC/icKZTwpQqeBn7wPSmGa5fejbiSriRCnCDnGD3p6j JrqxaWcXFtL5c2OT2NNgsXW5E91MJZQPlA7VFFPcKYoQXUZjA+T+HHPOPWmwm5jijZVZ5NkhG5ec 5o1CxoFSTkikIx1qoJ7lgFR3ZDIg8wpg89eMVYtmd7VHlzv5ByMdzUtAO6jIpQfSgDBIox3pALnF IT6UUfWgA4PejGOnFFFACFVYFWAYEcgism70COUl4JPLJ/hYZFa5FGaAOWbTdTtjhFkI/wCmb0qn WE6G7H/fRrqAc0UrImxzQl1ojk3f5GlEOrSnBFwf958V0lIOCQRRyrsFjEh0WZ/muJgvsvzH861r a3itogkQwO+ep+pqYjFIOlMdgHJqCUfvDU/0qCThzSZSHiRcdfyFOE4HAaiilcdg+0f7VN+0c8Nj 8KKKdwshTcY6En60C49XP5UUUrhZC/aOfvH8qUzg9WooouKyE84E53fpTvP9W/Siii4+VAJx/e/S l88f3v0ooouHKgM/H3qQ3GP4s0UUXFZALjJ5agz8feooouFkHn4GA36UfaOB81FFFwsgE/8AtfpS +eP71FFFw5UHnj+9TDKCck5/Ciii4JB5i5zn9KPMXpn9KKKLjsLvT1/SkEi9Cf0ooouFg8xfXP4U eYvr+lFFFwsBkX1/SgSLjr+lFFFwsHmKD1/SjzF9f0ooouFg8xfX9KPMX1/Siii4rB5inPP6Ub19 f0ooouOwm9fWonILEiiilcLH/9k= --srcthybj-- From simple-bounces@ietf.org Mon Apr 11 12:29:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26849; Mon, 11 Apr 2005 12:29:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1w5-0005Sc-RI; Mon, 11 Apr 2005 12:38:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1fT-0000W0-Jt; Mon, 11 Apr 2005 12:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL1fR-0000Uf-Hd for simple@megatron.ietf.org; Mon, 11 Apr 2005 12:21:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26333 for ; Mon, 11 Apr 2005 12:21:30 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1oh-0005Fm-Mo for simple@ietf.org; Mon, 11 Apr 2005 12:31:17 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 11 Apr 2005 09:21:21 -0700 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3BGLIgS005337; Mon, 11 Apr 2005 09:21:19 -0700 (PDT) Received: from 10.32.131.100 ([10.32.131.100]) by vtg-um-e2k4.sj21ad.cisco.com ([171.70.93.57]) with Microsoft Exchange Server HTTP-DAV ; Mon, 11 Apr 2005 16:21:56 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 10 Apr 2005 20:48:56 -0600 From: Cullen Jennings To: Miguel Garcia Message-ID: In-Reply-To: <42305B76.9030003@nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , "Khartabil Hisham \(Nokia-TP-MSW/Helsinki\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , Brian Rosen , Paul H Kyzivat , "simple@ietf.org" Subject: [Simple] Re: Chat Nicknames X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Ok - that makes sense to me. Do we need to change anything in the MSRP drafts to reflect any of this? On 3/10/05 8:36 AM, "Miguel Garcia" wrote: > Inline. > > > Cullen Jennings wrote: > >> I might be missing the boat here but let me ask a question that separates >> stuff. >> >> Is there a requirement to be able to change you nickname on every message or >> would it be acceptable to set up a new session if you want to change you >> nickname? > > I guess when you say "setup up a new session" really means a re-INVITE, > not an additional session. I believe it is possible, but perhaps a > lighter mechanism should be desirable. > > This is perhaps the reason why the chat draft went for an approach where > the nickname is composed of a Display-Name, which is freely changable on > a message by message basis, and a URN (could queally be a URI), that is > something more permanent, negotiated (or assigned by) the MSRP > switch/conference focus. > > This allows a user to change the display-name part of the nickname, > still having some sort of unique identifier within the conference. > >> >> It seems that the name could be set when you set up the session. If this is >> the case, then the display name of the From is very clear you can put any >> alias you want in it. The chat controller can tell you that name is not >> acceptable thought, in practice, there is no fundamental reason you can't >> have people with the same nickname and just have the conf server append >> something to make them unique. > > The name could be set when you set up the session, but it could also > change during such session, and even remain "allocated" for your usage > after the session. > > I think we agree that there are two components of the name, one is set > by the user, the other by the conference server. In the chat draft we > propose the former to be a display-name, the latter a URN, but I am fine > with any other proposal that keeps this property. > >> >> RTP/RTCP had different requirements for this because you could join a >> multicast session with effectively no signaling with all the participants so >> there was a need to continuously and adaptively flow the name information as >> the conference changed. Since this this centralized conferencing, you can >> get the names from the centralized thing. > > Agree. > >> >> Say two people joined with nick name of anon. The chat mixer may identify >> them as anon1 and anon2 in the session and you can send a private message to >> one of them by sending to location for anon2 (which would be an anonymous >> perhaps on the same box as the mixing was happening on). > > Agree too. If we use the approach of the chat draft, the two From header > (in Message/CPIM) would be: > > From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1 > From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2 > > >> >> Cullen >> >> > > /Miguel _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From vocabzx@british-hills.co.jp Mon Apr 11 13:15:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01070; Mon, 11 Apr 2005 13:15:25 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2et-0006yy-Ki; Mon, 11 Apr 2005 13:25:13 -0400 Received: from 68-113-19-116.wa.charter.com ([68.113.19.116]) by mx2.foretec.com with smtp (Exim 4.24) id 1DL2VL-0006tr-HU; Mon, 11 Apr 2005 13:15:23 -0400 Message-ID: <003f01c53e04$b33c9350$0301a8c0@ynzsoomsn> From: "Dillon Perez" To: "Dillon Perez" Subject: veikoden kodeyne and others Date: Mon, 11 Apr 2005 10:18:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 16.3 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Dotcors Answers to FAQ http://wcecdfuzwujg8kwk60hirgez1y.mhdla.com/ From simple-bounces@ietf.org Mon Apr 11 13:17:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01359; Mon, 11 Apr 2005 13:17:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2gV-00071Q-DI; Mon, 11 Apr 2005 13:26:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Vo-00015d-Nd; Mon, 11 Apr 2005 13:15:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DL2Vn-000150-7W for simple@megatron.ietf.org; Mon, 11 Apr 2005 13:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01124 for ; Mon, 11 Apr 2005 13:15:35 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL2f4-0006zU-1N for simple@ietf.org; Mon, 11 Apr 2005 13:25:23 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 11 Apr 2005 13:15:29 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3BHFPjI002704; Mon, 11 Apr 2005 13:15:25 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQN24073; Mon, 11 Apr 2005 13:15:23 -0400 (EDT) Message-ID: <425AB0AB.70701@cisco.com> Date: Mon, 11 Apr 2005 13:15:23 -0400 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: Cullen Jennings References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: Brian Rosen , Jonathan Rosenberg , "Khartabil Hisham \(Nokia-TP-MSW/Helsinki\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , Miguel Garcia , "simple@ietf.org" Subject: [Simple] Re: Chat Nicknames X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: 7bit Hmm, This discussion raises a question in my mind. Consider the following: Alice --\ /-- Carol \ / > F1 ------ F2 < / \ Bob ----/ \-- Dave In the F1 conference F2 is a surrogate participant for Carol and Dave, and in the F2 conference F1 is a surrogate participant for Alice and Bob. (At least I think that is how it would work.) One would hope that individual names for the participants could still make it end to end, rather than having having all messages from Carol and Dave appear to Alice and Bob as having come "from" F2. I believe audio mixers are capable of achieving this. Any effort to have the foci (or corresponding mixers/relays) help Alice address a message to Dave (if the address alice has for dave isn't directly usable for routing messages to him) is going to have problems in this topology. It presumes that the focus you send to understands all the mapping of nicknames to names, but that is not the case here. Paul Cullen Jennings wrote: > Ok - that makes sense to me. Do we need to change anything in the MSRP > drafts to reflect any of this? > > On 3/10/05 8:36 AM, "Miguel Garcia" wrote: > > >>Inline. >> >> >>Cullen Jennings wrote: >> >> >>>I might be missing the boat here but let me ask a question that separates >>>stuff. >>> >>>Is there a requirement to be able to change you nickname on every message or >>>would it be acceptable to set up a new session if you want to change you >>>nickname? >> >>I guess when you say "setup up a new session" really means a re-INVITE, >>not an additional session. I believe it is possible, but perhaps a >>lighter mechanism should be desirable. >> >>This is perhaps the reason why the chat draft went for an approach where >>the nickname is composed of a Display-Name, which is freely changable on >>a message by message basis, and a URN (could queally be a URI), that is >>something more permanent, negotiated (or assigned by) the MSRP >>switch/conference focus. >> >>This allows a user to change the display-name part of the nickname, >>still having some sort of unique identifier within the conference. >> >> >>>It seems that the name could be set when you set up the session. If this is >>>the case, then the display name of the From is very clear you can put any >>>alias you want in it. The chat controller can tell you that name is not >>>acceptable thought, in practice, there is no fundamental reason you can't >>>have people with the same nickname and just have the conf server append >>>something to make them unique. >> >>The name could be set when you set up the session, but it could also >>change during such session, and even remain "allocated" for your usage >>after the session. >> >>I think we agree that there are two components of the name, one is set >>by the user, the other by the conference server. In the chat draft we >>propose the former to be a display-name, the latter a URN, but I am fine >>with any other proposal that keeps this property. >> >> >>>RTP/RTCP had different requirements for this because you could join a >>>multicast session with effectively no signaling with all the participants so >>>there was a need to continuously and adaptively flow the name information as >>>the conference changed. Since this this centralized conferencing, you can >>>get the names from the centralized thing. >> >>Agree. >> >> >>>Say two people joined with nick name of anon. The chat mixer may identify >>>them as anon1 and anon2 in the session and you can send a private message to >>>one of them by sending to location for anon2 (which would be an anonymous >>>perhaps on the same box as the mixing was happening on). >> >>Agree too. If we use the approach of the chat draft, the two From header >>(in Message/CPIM) would be: >> >>From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1 >>From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2 >> >> >> >>>Cullen >>> >>> >> >>/Miguel > > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From faisal55990weilin@tendecade.com Tue Apr 12 01:54:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06485; Tue, 12 Apr 2005 01:54:34 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEVb-0005Au-Pz; Tue, 12 Apr 2005 02:04:26 -0400 Received: from [220.70.58.76] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1DLDcS-0002Bx-Lz; Tue, 12 Apr 2005 01:07:25 -0400 Received: from amigo.birdwelljanke.com (220.70.58.76) by novorols-861ZMMR.birdwelljanke.com with Microsoft SMTPSVC(8.899.73129.2);Tue, 12 Apr 2005 05:50:09 -0100 Message-ID: Reply-To: "liber alexina" From: "liber alexina" To: listadm@ietf.org Cc: simple-archive@ietf.org, urn-ietf@ietf.org, bridge-mib-admin@ietf.org, rserpool@ietf.org, vwg@ietf.org, dhcwg@ietf.org, rnet-drafts@ietf.org, meeting-scheduler@ietf.org, bridge-mib-request@ietf.org, edu-team@ietf.org, rmt-admin@ietf.org, tsvwg-request@ietf.org, rohc@ietf.org, ans-research@ietf.org, urn-archive@ietf.org, ssm-admin@ietf.org, ans-research-admin@ietf.org, sg@ietf.org Subject: Final Approval Notice Date: Tue, 12 Apr 2005 09:55:09 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--86271_557548.6mO785" X-Spam-Score: 8.4 (++++++++) X-Spam-Flag: YES X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a ----86271_557548.6mO785 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner,

We tried contacting you awhile ago about your low interest mortga/ge rate.
You have qualified for the lowest rate in years.
You could get over $602,000 for as little as $410 a month!
Have Ba/d credit?..Not a Problem! Low rates are guaranteed.

To get a free, no obliga/tion consultation click below:
http://hotrefinance.com/?name=rm2342
(please allow up to 30 seconds for the website to load)

Best Regards,
liber alexina

---------------------------
to be re -mov(ed: http://japp.hotrefinance.com/st.html ----86271_557548.6mO785-- From simple-bounces@ietf.org Tue Apr 12 02:11:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19433; Tue, 12 Apr 2005 02:11:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEmL-0005e8-AZ; Tue, 12 Apr 2005 02:21:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEVm-0004ft-SL; Tue, 12 Apr 2005 02:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLEVD-0004ct-3H for simple@megatron.ietf.org; Tue, 12 Apr 2005 02:03:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11721 for ; Tue, 12 Apr 2005 02:03:49 -0400 (EDT) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLEeb-0005Qn-Cw for simple@ietf.org; Tue, 12 Apr 2005 02:13:41 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3C63hO14225; Tue, 12 Apr 2005 09:03:43 +0300 (EET DST) X-Scanned: Tue, 12 Apr 2005 09:02:03 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j3C623eQ011685; Tue, 12 Apr 2005 09:02:03 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00pGXcW5; Tue, 12 Apr 2005 09:01:30 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3C61UU22097; Tue, 12 Apr 2005 09:01:30 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Apr 2005 09:00:54 +0300 Message-ID: <425B6414.7010300@nokia.com> Date: Tue, 12 Apr 2005 09:00:52 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 06:00:54.0154 (UTC) FILETIME=[FCBCEEA0:01C53F24] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Cc: Jonathan Rosenberg , "Khartabil Hisham \(Nokia-TP-MSW/Helsinki\)" , "Niemi Aki \(Nokia-NRC/Helsinki\)" , Brian Rosen , Paul H Kyzivat , "simple@ietf.org" Subject: [Simple] Re: Chat Nicknames X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit I think there aren't immediate actions to the MSRP drafts. /Miguel Cullen Jennings wrote: > Ok - that makes sense to me. Do we need to change anything in the MSRP > drafts to reflect any of this? > > On 3/10/05 8:36 AM, "Miguel Garcia" wrote: > > >>Inline. >> >> >>Cullen Jennings wrote: >> >> >>>I might be missing the boat here but let me ask a question that separates >>>stuff. >>> >>>Is there a requirement to be able to change you nickname on every message or >>>would it be acceptable to set up a new session if you want to change you >>>nickname? >> >>I guess when you say "setup up a new session" really means a re-INVITE, >>not an additional session. I believe it is possible, but perhaps a >>lighter mechanism should be desirable. >> >>This is perhaps the reason why the chat draft went for an approach where >>the nickname is composed of a Display-Name, which is freely changable on >>a message by message basis, and a URN (could queally be a URI), that is >>something more permanent, negotiated (or assigned by) the MSRP >>switch/conference focus. >> >>This allows a user to change the display-name part of the nickname, >>still having some sort of unique identifier within the conference. >> >> >>>It seems that the name could be set when you set up the session. If this is >>>the case, then the display name of the From is very clear you can put any >>>alias you want in it. The chat controller can tell you that name is not >>>acceptable thought, in practice, there is no fundamental reason you can't >>>have people with the same nickname and just have the conf server append >>>something to make them unique. >> >>The name could be set when you set up the session, but it could also >>change during such session, and even remain "allocated" for your usage >>after the session. >> >>I think we agree that there are two components of the name, one is set >>by the user, the other by the conference server. In the chat draft we >>propose the former to be a display-name, the latter a URN, but I am fine >>with any other proposal that keeps this property. >> >> >>>RTP/RTCP had different requirements for this because you could join a >>>multicast session with effectively no signaling with all the participants so >>>there was a need to continuously and adaptively flow the name information as >>>the conference changed. Since this this centralized conferencing, you can >>>get the names from the centralized thing. >> >>Agree. >> >> >>>Say two people joined with nick name of anon. The chat mixer may identify >>>them as anon1 and anon2 in the session and you can send a private message to >>>one of them by sending to location for anon2 (which would be an anonymous >>>perhaps on the same box as the mixing was happening on). >> >>Agree too. If we use the approach of the chat draft, the two From header >>(in Message/CPIM) would be: >> >>From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1 >>From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2 >> >> >> >>>Cullen >>> >>> >> >>/Miguel > > -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 12 03:05:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01896; Tue, 12 Apr 2005 03:05:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLFcB-0006nw-5M; Tue, 12 Apr 2005 03:15:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLFPN-0007iq-0T; Tue, 12 Apr 2005 03:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLFPK-0007hV-PQ for simple@megatron.ietf.org; Tue, 12 Apr 2005 03:01:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01641 for ; Tue, 12 Apr 2005 03:01:48 -0400 (EDT) Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLFYi-0006jG-Jo for simple@ietf.org; Tue, 12 Apr 2005 03:11:42 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3C6stJ05525; Tue, 12 Apr 2005 09:54:55 +0300 (EET DST) X-Scanned: Tue, 12 Apr 2005 09:47:20 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j3C6lKrk022147; Tue, 12 Apr 2005 09:47:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00LYbMyO; Tue, 12 Apr 2005 09:47:03 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3C69FU02057; Tue, 12 Apr 2005 09:09:15 +0300 (EET DST) Received: from [127.0.0.1] ([172.21.39.90]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 12 Apr 2005 09:09:06 +0300 Message-ID: <425B6601.4050305@nokia.com> Date: Tue, 12 Apr 2005 09:09:05 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Paul Kyzivat References: <425AB0AB.70701@cisco.com> In-Reply-To: <425AB0AB.70701@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 06:09:06.0488 (UTC) FILETIME=[22312380:01C53F26] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "simple@ietf.org" , Hisham Khartabil , "Niemi Aki \(Nokia-NRC/Helsinki\)" Subject: [Simple] Re: Chat Nicknames X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: 7bit Paul: The use case you raise is really interesting. One way to solve this poblem would be based on the following. Assume the URN in nicknames have some hierarchy that points to a particular focus. For example F1 and F2 name spaces could be urn:ietf:params:msrp:names:com:example:f1 and urn:ietf:params:msrp:names:org:example:f2 respectively Nicknames allocated to Alice and Bob could be: urn:ietf:params:msrp:names:com:example:f1:alice urn:ietf:params:msrp:names:com:example:f1:bob and to Carol and Dave urn:ietf:params:msrp:names:org:example:f2:carol urn:ietf:params:msrp:names:org:example:f2:dave The next thing that is required is that F1 and F2 exchange their root namespace at the time they establish the MSRP session. On doing so F1 will learn the prefix that F2 will allocate to nicknames of its participants, and F2 will do the same with respect F1. Things will get complicated when more foci are cascaded, like F1--F2--F3. This will require further delivery of URN prefixes. Any other idea? /Miguel Paul Kyzivat wrote: > Hmm, > > This discussion raises a question in my mind. Consider the following: > > Alice --\ /-- Carol > \ / > > F1 ------ F2 < > / \ > Bob ----/ \-- Dave > > In the F1 conference F2 is a surrogate participant for Carol and Dave, > and in the F2 conference F1 is a surrogate participant for Alice and > Bob. (At least I think that is how it would work.) One would hope that > individual names for the participants could still make it end to end, > rather than having having all messages from Carol and Dave appear to > Alice and Bob as having come "from" F2. I believe audio mixers are > capable of achieving this. > > Any effort to have the foci (or corresponding mixers/relays) help Alice > address a message to Dave (if the address alice has for dave isn't > directly usable for routing messages to him) is going to have problems > in this topology. It presumes that the focus you send to understands all > the mapping of nicknames to names, but that is not the case here. > > Paul > > Cullen Jennings wrote: > >> Ok - that makes sense to me. Do we need to change anything in the MSRP >> drafts to reflect any of this? >> >> On 3/10/05 8:36 AM, "Miguel Garcia" wrote: >> >> >>> Inline. >>> >>> >>> Cullen Jennings wrote: >>> >>> >>>> I might be missing the boat here but let me ask a question that >>>> separates >>>> stuff. >>>> Is there a requirement to be able to change you nickname on every >>>> message or >>>> would it be acceptable to set up a new session if you want to change >>>> you >>>> nickname? >>> >>> >>> I guess when you say "setup up a new session" really means a re-INVITE, >>> not an additional session. I believe it is possible, but perhaps a >>> lighter mechanism should be desirable. >>> >>> This is perhaps the reason why the chat draft went for an approach where >>> the nickname is composed of a Display-Name, which is freely changable on >>> a message by message basis, and a URN (could queally be a URI), that is >>> something more permanent, negotiated (or assigned by) the MSRP >>> switch/conference focus. >>> >>> This allows a user to change the display-name part of the nickname, >>> still having some sort of unique identifier within the conference. >>> >>> >>>> It seems that the name could be set when you set up the session. If >>>> this is >>>> the case, then the display name of the From is very clear you can >>>> put any >>>> alias you want in it. The chat controller can tell you that name is not >>>> acceptable thought, in practice, there is no fundamental reason you >>>> can't >>>> have people with the same nickname and just have the conf server append >>>> something to make them unique. >>> >>> >>> The name could be set when you set up the session, but it could also >>> change during such session, and even remain "allocated" for your usage >>> after the session. >>> >>> I think we agree that there are two components of the name, one is set >>> by the user, the other by the conference server. In the chat draft we >>> propose the former to be a display-name, the latter a URN, but I am fine >>> with any other proposal that keeps this property. >>> >>> >>>> RTP/RTCP had different requirements for this because you could join a >>>> multicast session with effectively no signaling with all the >>>> participants so >>>> there was a need to continuously and adaptively flow the name >>>> information as >>>> the conference changed. Since this this centralized conferencing, >>>> you can >>>> get the names from the centralized thing. >>> >>> >>> Agree. >>> >>> >>>> Say two people joined with nick name of anon. The chat mixer may >>>> identify >>>> them as anon1 and anon2 in the session and you can send a private >>>> message to >>>> one of them by sending to location for anon2 (which would be an >>>> anonymous >>>> perhaps on the same box as the mixing was happening on). >>> >>> >>> Agree too. If we use the approach of the chat draft, the two From header >>> (in Message/CPIM) would be: >>> >>> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1 >>> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2 >>> >>> >>> >>>> Cullen >>>> >>>> >>> >>> /Miguel >> >> >> -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 12 04:04:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05542; Tue, 12 Apr 2005 04:04:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGXi-0008S0-3N; Tue, 12 Apr 2005 04:14:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGIL-0000Ro-ER; Tue, 12 Apr 2005 03:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLGIA-0000QF-Vh for simple@megatron.ietf.org; Tue, 12 Apr 2005 03:58:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05160 for ; Tue, 12 Apr 2005 03:58:28 -0400 (EDT) Received: from smtp7.clb.oleane.net ([213.56.31.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLGRZ-0008Gx-Gh for simple@ietf.org; Tue, 12 Apr 2005 04:08:22 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp7.clb.oleane.net with ESMTP id j3C7wJxo016491 for ; Tue, 12 Apr 2005 09:58:19 +0200 Message-Id: <200504120758.j3C7wJxo016491@smtp7.clb.oleane.net> From: "Chantal Ladouce" To: Date: Tue, 12 Apr 2005 09:58:12 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU/NWAHbXmKBN4DQeWHT/Xz0eMeMw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [Simple] WiFi Voice Conference - Paris - France X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1858531307==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 This is a multi-part message in MIME format. --===============1858531307== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C53F46.2426CB70" This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C53F46.2426CB70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Only four weeks left before the starting of the second edition of the WiFi Voice conference to be held in Paris next 10-13 May. Experts and service providers will address all the technical issues related to VoWLAN. Registration is still open. Please get all details at: http://www.upperside.fr/wifi05/wifivoice2005intro.htm ------=_NextPart_000_0021_01C53F46.2426CB70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

Only four weeks left before the starting of = the second edition of the WiFi Voice conference to be held in = Paris next = 10-13 May.

Experts and service providers will address all = the technical issues related to VoWLAN.

Registration is still open.

Please get all details at:

http://www.upperside.fr/wifi05/wifivoice2005intro.htm=

 

------=_NextPart_000_0021_01C53F46.2426CB70-- --===============1858531307== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1858531307==-- From simple-bounces@ietf.org Tue Apr 12 09:33:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28946; Tue, 12 Apr 2005 09:33:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLfd-0000mn-KW; Tue, 12 Apr 2005 09:43:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLLPh-00012h-36; Tue, 12 Apr 2005 09:26:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLLPf-00011k-Hh for simple@megatron.ietf.org; Tue, 12 Apr 2005 09:26:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28652 for ; Tue, 12 Apr 2005 09:26:33 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLZ7-0000bU-Pt for simple@ietf.org; Tue, 12 Apr 2005 09:36:30 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2005 09:26:26 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3CDQMUJ016979; Tue, 12 Apr 2005 09:26:23 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQN86556; Tue, 12 Apr 2005 09:26:22 -0400 (EDT) Message-ID: <425BCC7D.6010609@cisco.com> Date: Tue, 12 Apr 2005 09:26:21 -0400 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: Miguel Garcia References: <425AB0AB.70701@cisco.com> <425B6601.4050305@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "simple@ietf.org" , Hisham Khartabil , "Niemi Aki \(Nokia-NRC/Helsinki\)" Subject: [Simple] Re: Chat Nicknames X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Miguel, What you suggest is troublesome because it requires a particular form of URN and URN usage. I'm not very knowledgable about RTP, but I believe RTP mixers exchange their full lists of participant identifiers via RTCP. Doing that - exchanging the full list of participants - is an alternative to just disclosing a root in the nickname namespace. But that is still not very appealing to me. In fact, the whole notion of replicating roster info in the media stream seems questionable to me, when there are specific mechanisms being defined for managing rosters that are not media specific. I still think that a better solution is simply to use the same identities the focus uses to identify participants at the signaling level. If participants want anonymity then they should use an anonymizer for participating in the conference as a whole - but an anonymizer that permits limited forms of callback to the anonymous id. Paul Miguel Garcia wrote: > Paul: > > The use case you raise is really interesting. One way to solve this > poblem would be based on the following. Assume the URN in nicknames have > some hierarchy that points to a particular focus. For example F1 and F2 > name spaces could be urn:ietf:params:msrp:names:com:example:f1 and > urn:ietf:params:msrp:names:org:example:f2 respectively > > Nicknames allocated to Alice and Bob could be: > > urn:ietf:params:msrp:names:com:example:f1:alice > urn:ietf:params:msrp:names:com:example:f1:bob > > and to Carol and Dave > > urn:ietf:params:msrp:names:org:example:f2:carol > urn:ietf:params:msrp:names:org:example:f2:dave > > The next thing that is required is that F1 and F2 exchange their root > namespace at the time they establish the MSRP session. On doing so F1 > will learn the prefix that F2 will allocate to nicknames of its > participants, and F2 will do the same with respect F1. > > Things will get complicated when more foci are cascaded, like > F1--F2--F3. This will require further delivery of URN prefixes. > > Any other idea? > > /Miguel > > Paul Kyzivat wrote: > >> Hmm, >> >> This discussion raises a question in my mind. Consider the following: >> >> Alice --\ /-- Carol >> \ / >> > F1 ------ F2 < >> / \ >> Bob ----/ \-- Dave >> >> In the F1 conference F2 is a surrogate participant for Carol and Dave, >> and in the F2 conference F1 is a surrogate participant for Alice and >> Bob. (At least I think that is how it would work.) One would hope that >> individual names for the participants could still make it end to end, >> rather than having having all messages from Carol and Dave appear to >> Alice and Bob as having come "from" F2. I believe audio mixers are >> capable of achieving this. >> >> Any effort to have the foci (or corresponding mixers/relays) help >> Alice address a message to Dave (if the address alice has for dave >> isn't directly usable for routing messages to him) is going to have >> problems in this topology. It presumes that the focus you send to >> understands all the mapping of nicknames to names, but that is not the >> case here. >> >> Paul >> >> Cullen Jennings wrote: >> >>> Ok - that makes sense to me. Do we need to change anything in the MSRP >>> drafts to reflect any of this? >>> >>> On 3/10/05 8:36 AM, "Miguel Garcia" wrote: >>> >>> >>>> Inline. >>>> >>>> >>>> Cullen Jennings wrote: >>>> >>>> >>>>> I might be missing the boat here but let me ask a question that >>>>> separates >>>>> stuff. >>>>> Is there a requirement to be able to change you nickname on every >>>>> message or >>>>> would it be acceptable to set up a new session if you want to >>>>> change you >>>>> nickname? >>>> >>>> >>>> >>>> I guess when you say "setup up a new session" really means a re-INVITE, >>>> not an additional session. I believe it is possible, but perhaps a >>>> lighter mechanism should be desirable. >>>> >>>> This is perhaps the reason why the chat draft went for an approach >>>> where >>>> the nickname is composed of a Display-Name, which is freely >>>> changable on >>>> a message by message basis, and a URN (could queally be a URI), that is >>>> something more permanent, negotiated (or assigned by) the MSRP >>>> switch/conference focus. >>>> >>>> This allows a user to change the display-name part of the nickname, >>>> still having some sort of unique identifier within the conference. >>>> >>>> >>>>> It seems that the name could be set when you set up the session. If >>>>> this is >>>>> the case, then the display name of the From is very clear you can >>>>> put any >>>>> alias you want in it. The chat controller can tell you that name is >>>>> not >>>>> acceptable thought, in practice, there is no fundamental reason you >>>>> can't >>>>> have people with the same nickname and just have the conf server >>>>> append >>>>> something to make them unique. >>>> >>>> >>>> >>>> The name could be set when you set up the session, but it could also >>>> change during such session, and even remain "allocated" for your usage >>>> after the session. >>>> >>>> I think we agree that there are two components of the name, one is set >>>> by the user, the other by the conference server. In the chat draft we >>>> propose the former to be a display-name, the latter a URN, but I am >>>> fine >>>> with any other proposal that keeps this property. >>>> >>>> >>>>> RTP/RTCP had different requirements for this because you could join a >>>>> multicast session with effectively no signaling with all the >>>>> participants so >>>>> there was a need to continuously and adaptively flow the name >>>>> information as >>>>> the conference changed. Since this this centralized conferencing, >>>>> you can >>>>> get the names from the centralized thing. >>>> >>>> >>>> >>>> Agree. >>>> >>>> >>>>> Say two people joined with nick name of anon. The chat mixer may >>>>> identify >>>>> them as anon1 and anon2 in the session and you can send a private >>>>> message to >>>>> one of them by sending to location for anon2 (which would be an >>>>> anonymous >>>>> perhaps on the same box as the mixing was happening on). >>>> >>>> >>>> >>>> Agree too. If we use the approach of the chat draft, the two From >>>> header >>>> (in Message/CPIM) would be: >>>> >>>> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon1 >>>> From: "anonymous" urn:ietf:params:msrp:names:com:example:switch:anon2 >>>> >>>> >>>> >>>>> Cullen >>>>> >>>>> >>>> >>>> /Miguel >>> >>> >>> >>> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From alyxegzxpvqqnj@vestibulares.br Tue Apr 12 09:56:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00500; Tue, 12 Apr 2005 09:56:43 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLM2J-0001P4-KM; Tue, 12 Apr 2005 10:06:40 -0400 Received: from c-67-173-52-111.hsd1.il.comcast.net ([67.173.52.111]) by mx2.foretec.com with smtp (Exim 4.24) id 1DLLsc-0004lq-Uz; Tue, 12 Apr 2005 09:56:39 -0400 Message-ID: <000701c53f36$85d5c390$0301a8c0@lijqahmy> From: "Tad Bain" To: "Tad Bain" Subject: Get the next generation...not expensive Date: Tue, 12 Apr 2005 07:00:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 12.1 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Save a bunch with us http://vyirtujlmauxcrx5yvuvw5ukydc.fgavshargj.com/ From simple-bounces@ietf.org Tue Apr 12 10:32:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04445; Tue, 12 Apr 2005 10:32:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMat-0002QX-Io; Tue, 12 Apr 2005 10:42:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLMJo-0001En-PU; Tue, 12 Apr 2005 10:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLMJm-0001Dt-Ny for simple@megatron.ietf.org; Tue, 12 Apr 2005 10:24:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03778 for ; Tue, 12 Apr 2005 10:24:32 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLMTE-0002BY-C9 for simple@ietf.org; Tue, 12 Apr 2005 10:34:30 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3CEOMOW011532 for ; Tue, 12 Apr 2005 16:24:31 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 16:24:30 +0200 Received: from EGE1U003CT8QJ4F.ki.sw.ericsson.se ([147.214.118.71]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Apr 2005 16:24:26 +0200 From: Ignacio =?ISO-8859-1?Q?M=E1s?= "Ivars (KI/EAB)" To: SIMPLE mailing list Content-Type: text/plain Date: Tue, 12 Apr 2005 16:24:33 +0200 Message-Id: <1113315873.16273.3.camel@Caliope> Mime-Version: 1.0 X-Mailer: Evolution 2.1.6 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2005 14:24:26.0730 (UTC) FILETIME=[54D62CA0:01C53F6B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [Simple] message-sessions-10 WGLC: unique message ID and failed connections? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi all: I still have some doubts about the unique message ID when a connection fails. Right now, the draft specifies that an endpoint MAY attempt to recreate a failed session, and then it MUST use a new SDP exchange. If the session is recreated the endpoints can resend non-confirmed content, using the same message ID. But what happens if the sender does not want to resend the non-confirmed content and still chooses to start a new session? In principle the receiver will be holding on to the partial or non-confirmed messages, waiting for the sender to recreate the session, and then it will open a new session which, according to the draft, can contain messages with the same message ID as the ones in the failed session. Since B does not know whether A wants to still recreate the failed session, it can't discard those messages, which will be overwritten by the ones with the same message ID in the new session... I principle, there is a way to differentiate those messages since the ones being resent come from a REINVITE or UPDATE... but what happens if a possible new session fail? Then there would be two 'partial' sessions and there would be no way to identify the partial messages from each session. I might be overlooking something, but that looks to me as a problem. Wouldn't it be more reliable to have the same requirements for the message ID as the ones in SMTP? SMTP and other previous protocols require a uniqueness of the message-ID over time and space that refers to a particular version of a particular message and is guaranteed by the host that generates it. Why does MSRP deviate from this definition by just asking uniqueness over the current and previous session? ======================rfc2822 The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it. This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. ======================rfc2822 Perhaps there is an obvious answer to that problem, but I have not found it so far, so comments are greatly appreciated! /Ignacio _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 12 11:35:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08756; Tue, 12 Apr 2005 11:35:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLNZq-0004Ec-SY; Tue, 12 Apr 2005 11:45:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNLB-0003Bu-NP; Tue, 12 Apr 2005 11:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLNLA-0003Ae-DS for simple@megatron.ietf.org; Tue, 12 Apr 2005 11:30:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08239 for ; Tue, 12 Apr 2005 11:30:01 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLNUZ-00044d-Tr for simple@ietf.org; Tue, 12 Apr 2005 11:39:57 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2005 08:29:50 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3CFTmpT008632; Tue, 12 Apr 2005 08:29:48 -0700 (PDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQN99528; Tue, 12 Apr 2005 11:29:46 -0400 (EDT) Message-ID: <425BE969.70107@cisco.com> Date: Tue, 12 Apr 2005 11:29:45 -0400 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: =?ISO-8859-1?Q?=22Ignacio_M=E1s_=5C=22Ivars_=28KI/EAB=29=5C=22=22?= Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and failed connections? References: <1113315873.16273.3.camel@Caliope> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA08239 Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable It would be bad to reinvite and establish a replacement session, and=20 then send new messages with message ids that match incomplete messages=20 from the prior session. The "simple" answer is that in such a case the new messages should have=20 unique ids to those of the replaced session. This isn't an unreasonable=20 requirement if its the same two endpoints. But, as with everything else, this could get complex in a 3pcc=20 situation. A 3pcc controller might do a transfer using reinvites. As=20 result, one endpoint thinks it has a replacement session, while the=20 other thinks it has a new session. The guy who thinks its a new session=20 can't very well know what message ids had been used before. Its only=20 soluiton is to use message ids that are guaranteed to be globally unique. But I think this isn't going to be a major problem in practice. I hope=20 we can defer the details of this kind of stuff, including perhaps some=20 added guidelines, as future work. Paul Ignacio M=E1s Ivars (KI/EAB) wrote: > Hi all: > I still have some doubts about the unique message ID when a connection > fails. Right now, the draft specifies that an endpoint MAY attempt to > recreate a failed session, and then it MUST use a new SDP exchange. If > the session is recreated the endpoints can resend non-confirmed content= , > using the same message ID. But what happens if the sender does not want > to resend the non-confirmed content and still chooses to start a new > session? In principle the receiver will be holding on to the partial or > non-confirmed messages, waiting for the sender to recreate the session, > and then it will open a new session which, according to the draft, can > contain messages with the same message ID as the ones in the failed > session. Since B does not know whether A wants to still recreate the > failed session, it can't discard those messages, which will be > overwritten by the ones with the same message ID in the new session...=20 > I principle, there is a way to differentiate those messages since the > ones being resent come from a REINVITE or UPDATE... but what happens if > a possible new session fail? Then there would be two 'partial' sessions > and there would be no way to identify the partial messages from each > session. I might be overlooking something, but that looks to me as a > problem. >=20 > Wouldn't it be more reliable to have the same requirements for the > message ID as the ones in SMTP? SMTP and other previous protocols > require a uniqueness of the message-ID over time and space that refers > to a particular version of a particular message and is guaranteed by th= e > host that generates it. Why does MSRP deviate from this definition by > just asking uniqueness over the current and previous session? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc28= 22 > The "Message-ID:" field provides a unique message identifier that > refers to a particular version of a particular message. The > uniqueness of the message identifier is guaranteed by the host that > generates it. This message identifier is intended to be > machine readable and not necessarily meaningful to humans. A messag= e > identifier pertains to exactly one instantiation of a particular > message; subsequent revisions to the message each receive new messag= e > identifiers. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc28= 22 >=20 > Perhaps there is an obvious answer to that problem, but I have not foun= d > it so far, so comments are greatly appreciated! >=20 > /Ignacio >=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-bounces@ietf.org Tue Apr 12 13:00:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15900; Tue, 12 Apr 2005 13:00:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOtn-000760-13; Tue, 12 Apr 2005 13:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOfx-0006pe-ML; Tue, 12 Apr 2005 12:55:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLOfv-0006ov-1U for simple@megatron.ietf.org; Tue, 12 Apr 2005 12:55:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15401 for ; Tue, 12 Apr 2005 12:55:31 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLOpP-0006te-8c for simple@ietf.org; Tue, 12 Apr 2005 13:05:31 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 12 Apr 2005 12:55:26 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3CGtKeZ004306; Tue, 12 Apr 2005 12:55:23 -0400 (EDT) Received: from cisco.com ([161.44.79.173]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQO08023; Tue, 12 Apr 2005 12:55:19 -0400 (EDT) Message-ID: <425BFD77.6040702@cisco.com> Date: Tue, 12 Apr 2005 12:55:19 -0400 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: "Hyttfors, Per" Subject: Re: AW: [Simple] reachibility information for services in current presence data model References: <1AF90E65795A3D45AA116B9264B4DAAF029D84FB@SELDMSX01.corpusers.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7bit I never answered this. If the intelligent composition policy is to reduce this to one tuple, it must also reduce it to one contact address. Sometimes this could be the AoR. If that doesn't work, then it may have to create an address, serviced by an intermediary, that does the job. If you can't do that, then don't do the composition. I think maybe you are looking at the intelligent composition as just a data compression scheme. While it may have that effect, that isn't really its purpose. If all you care about is the size of the document, use compression. Paul Hyttfors, Per wrote: > The problem I see is that the current presence data model doesn't allow > for such "service composition policy" without having to define a new > format that can describe one service reachable through serveral > published addresses. > > /Per > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: onsdag den 6 april 2005 16:32 > To: Hyttfors, Per > Cc: simple@ietf.org > Subject: Re: AW: [Simple] reachibility information for services in > current presence data model > > Hyttfors, Per wrote: > >>Hello, >> >>Lets say that the same person would have several devices with the same > > >>service running on all of them (lets say a telephone service) but with > > >>different service contact addresses (telephone numbers). Each device >>will have its own Presence User Agent that publish its part of the >>presence information. Would this scenario require that the NOTIFY that > > >>is sent to a watcher with the overall presence information of that >>person would have to contain several with different contact >>addresses but with the same duplicated service information? (in the >>case that the service is the exact same one for all devices) > > > This is a function of how the multiple sources of presence information > are composed by the presence server. Simply making a union of all the > tuples (which is what you ask about) is one simple approach, because it > requires no understanding on the part of the part of the presence > server. But it is clear that people would like to have more intelligent > composition policies. So far we have deferred actually defining such > intelligent composition policies just because it is hard and we want to > get something out. But it is entirely permissible to implement such a > compostion policy even in the absence of a standard. > > Paul > > >>/Per >> >> >>Henning Schulzrinne wrote: >> >> >>>Unless there is some significant difference between services, you >>>wouldn't publish multiple contact addresses for it. Thus >>> >>> >>> ... description ... >>> sip:foo@somewhere >>> sip:bar@example >>> sip:123@whoknows >>> >>> >>>makes very little sense - why publish three URIs that the observer has >>>no way of distinguishing? If there's no annotation, the user can only >>>throw darts and pick one. >>> >>>With the possible exception of having both a "tel" and SIP URI that >>>reach the same device, I see little practical use for your >> > description, > >> >>>but maybe I'm misunderstanding your use case. >>> >>>Boehmer Bernhard Com Berlin wrote: >>> >>> >>>>Hi Henning, >>>>my assumption is that a user has a certain service available at >>>>different locations (devices, agents, etc.) each identified by >>>>different contact addresses. The user wants to publish all these >>>>contact addresses for this service. Together with the contact >>>>information, however, (s)he also publishes also a bunch of other >>>>information about this service. Due to the fact that only one contact >>> > >>>>is possible in , my current understanding is that the user has >>> >>to publish >> >> >>>>multiple tuples indicating the different contacts but *duplicating* >>>>the other service information. This information, therefore, seems to >>>>be doubled. I would like to avoid this redundancy somehow. >>>> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>Per Hyttfors >>___________________________________________________________ >>Development Engineer - Messaging Application Development >>Sony Ericsson Mobile Communications AB >>SE-221 88 Lund, Sweden >>+46 46 2126534 >>per.hyttfors@sonyericsson.com >>___________________________________________________________ >>The information in this email, and attachment(s) thereto, is strictly >>confidential and may be legally privileged. It is intended solely for >>the named recipient(s), and access to this e-mail, or any > > attachment(s) > >>thereto, by anyone else is unauthorized. Violations hereof may result > > in > >>legal actions. Any attachment(s) to this e-mail has been checked for >>viruses, but please rely on your own virus-checker and procedures. If >>you contact us by e-mail, we will store your name and address to >>facilitate communications in the matter concerned. If you do not > > consent > >>to us storing your name and address for above stated purpose, please >>notify the sender promptly. Also, if you are not the intended > > recipient > >>please inform the sender by replying to this transmission, and delete >>the e-mail, its attachment(s), and any copies of it without, > > disclosing > >>it. >> >>_______________________________________________ >>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 tony2000@eresmas.com Wed Apr 13 11:00:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03530; Wed, 13 Apr 2005 11:00:19 -0400 (EDT) Received: from smtp11.eresmas.com ([62.81.235.111]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLjVd-0001Bt-EK; Wed, 13 Apr 2005 11:10:30 -0400 Received: from [192.168.105.166] (helo=ma20.eresmas.com) by smtp11.eresmas.com with esmtp (Exim 4.10) id 1DLjIu-0006dP-00; Wed, 13 Apr 2005 16:57:20 +0200 From: anthony uba 2341 To: t6qsdmoq@yahoo.com Reply-To: anthonyuba111@yahoo.co.in Message-ID: <2187382187f5.2187f5218738@ma20.eresmas.com> Date: Wed, 13 Apr 2005 14:57:21 GMT X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: MR. Anthony Uba X-Accept-Language: en Content-Type: text/html; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: 12.3 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit

FROM THE DESK OF:
MR.Athony Uba

Dear Sir/Madam

I am MR Athony Uba, Bank Manager of Cometh Bank
Plc,Victoria-Island Branch I have an urgent and very confidential
business proposition  for you.

In 1996 - 1997, an Oil consultant/contractor with the Nigerian National
Petroleum Corporation, Engr. Nam Hyewon made a numbered time (Fixed)
Deposit for twelve calendar months, valued atS$25,000,000.00
(Twenty-five Million Dollars) in my branch. Upon maturity, I sent a
routine  notification to his forwarding address but got no reply. After
a
month, we  sent a reminder and finally we discovered from his contract
employers,  the Nigerian National Petroleum Corporation that Engr. Nam
Hyewon died in  Korean Air Flight 801, which crashed in Guam on August
1997. On further  investigation, I found out that he died without
making a WILL, and all attempts to trace his next of kin was fruitless.
I therefore made further investigation and discovered that Engr. Nam
Hyewon did not declare any next of kin or relations in all her official
documents, including her Bank Deposit paperwork in my Bank. This sum of
US$25,000,000.00 is still sitting in my Bank and the interest is being
rolled over with the principal sum at the end of each year. No one will
ever come forward to claim it. According to Nigerian Law, at the
expiration of 6 (six) years, the money will revert to the ownership of
the Nigerian Government if nobody applies to claim this fund.

Consequently, my proposal is that I will like you as a foreigner to
stand in as the next of kin to Engr. Nam Hyewon so that the fruits of
this His labor will not get into the hands of some corrupt
government officials. This is simple, I will like you to provide
immediately your full names and address so that the Attorney will
prepare the  necessary documents and affidavits which will! put you in
place as the  next of  kin. We shall employ the services of two
Attorneys
for drafting and notarization of the WILL and to obtain the necessary
documents and letter of probate/administration in your favor for the
transfer.

I would need you as a Foreigner acting as the next of kin and sole
benefactor to the inheritance of Engr. Nam Hyewon to claim from the
bank. The money will be transferred to you for us to share in the ratio
of 60% for me and 40% for you. There is no risk at all as all the
paperwork for this transaction will be done by the Attorney and my
position as the Branch Manager guarantees the successful execution of
this transaction. If you are interested, please reply immediately via
the private email address below.Upon your response, I shall then
provide you with more details and relevant documents that will help you
understand the
transaction.

Please observe utmost confidentiality, and! rest assured that this
transaction would be most profitable for both of us because I shall
require your assistance to invest my share in your country.

anthonyuba1@yahoo.co.in
Thanks and regards.

MR. Anthony Uba
Cometh Bank plc

 


 

From joan@about.com Wed Apr 13 14:34:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20741 for ; Wed, 13 Apr 2005 14:34:48 -0400 (EDT) Received: from pool-68-238-122-141.atl.dsl-w.verizon.net ([68.238.122.141]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DLmr7-0007Kw-Mn for simple-archive@ietf.org; Wed, 13 Apr 2005 14:45:00 -0400 Message-ID: From: "Vanessa J. Smith" To: simple-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgQWNyb2JhdCA2LjAgLSB2ZXJ5IGxvdyBwcmljZQ==?= Date: Wed, 13 Apr 2005 21:09:03 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_F1026951.FAD40094" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0000_F1026951.FAD40094 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_92CEB20E.FA2E043B" ------=_NextPart_001_0001_92CEB20E.FA2E043B Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Access all the popular software imaginable for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. Just a few examples: $79.95 Windows XP Professional (Including: Service Pack 2) $89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional $99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $69.95 Quark Xpress 6 Passport Multilanguage Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And lots more... To visit us go: http://www.soft-cds.com Best, Vanessa J. Smith _____________________________________________________ To change your mail preferences, go: http://www.soft-cds.com/uns.htm _____________________________________________________ ------=_NextPart_001_0001_92CEB20E.FA2E043B Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit
Access all the software possible for wholesale prices!
Our software is 2-10 times cheaper than sold by our competitors.

Examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And lots more... Enter here:

http://www.soft-cds.com

Best regards,
Vanessa J. Smith


_____________________________________________________
To change your mail preferences, go here: http://www.soft-cds.com/uns.htm
_____________________________________________________

------=_NextPart_001_0001_92CEB20E.FA2E043B-- ------=_NextPart_000_0000_F1026951.FAD40094-- From simple-bounces@ietf.org Wed Apr 13 14:42:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21431; Wed, 13 Apr 2005 14:42:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmz7-0007Z9-W4; Wed, 13 Apr 2005 14:53:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmp9-0005Bx-Vt; Wed, 13 Apr 2005 14:42:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DLmp8-00056I-2i for simple@megatron.ietf.org; Wed, 13 Apr 2005 14:42:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21413 for ; Wed, 13 Apr 2005 14:42:40 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLmyo-0007Yo-OS for simple@ietf.org; Wed, 13 Apr 2005 14:52:52 -0400 Received: from esealmw127.eemea.ericsson.se ([153.88.254.122]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3DIfRO6006264; Wed, 13 Apr 2005 20:41:27 +0200 Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:41:27 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 13 Apr 2005 20:41:27 +0200 Received: from [131.160.126.32] (rvi2-126-32.lmf.ericsson.se [131.160.126.32]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5139118A90; Wed, 13 Apr 2005 21:41:25 +0300 (EEST) Message-ID: <425D67D5.5040500@ericsson.com> Date: Wed, 13 Apr 2005 21:41:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and failed connections? References: <1113315873.16273.3.camel@Caliope> <425BE969.70107@cisco.com> In-Reply-To: <425BE969.70107@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2005 18:41:27.0646 (UTC) FILETIME=[66D4F7E0:01C54058] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Paul, > But, as with everything else, this could get complex in a 3pcc > situation. A 3pcc controller might do a transfer using reinvites. As > result, one endpoint thinks it has a replacement session, while the > other thinks it has a new session. The guy who thinks its a new session > can't very well know what message ids had been used before. I agree with you on this one. We have already been there (e.g., the comedia and the preconditions stuff), and relaying on the concept of a SIP session to set the scope of any media-related identifier is not a good idea. Paul and I tried exactly the same in comedia (using identifiers scoped by the SIP session) and cocluded that they did not work. > Its only > soluiton is to use message ids that are guaranteed to be globally > unique. Yes, I agree this is the way to resolve the problem. In fact, I believe this is how RFC 2822 defines uniqueness of message identifiers. With your proposal we kill two birds with the same stone. We align with RFC 2822 and we resolve the session mobility problem. Thanks, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From ujusfglplba@yahoo.com Wed Apr 13 18:05:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11108; Wed, 13 Apr 2005 18:05:06 -0400 (EDT) From: ujusfglplba@yahoo.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLq8l-0005qN-Q1; Wed, 13 Apr 2005 18:15:20 -0400 Received: from pcp06940753pcs.nrockv01.md.comcast.net ([69.138.20.0]) by mx2.foretec.com with smtp (Exim 4.24) id 1DLpyp-0004Fa-Lx; Wed, 13 Apr 2005 18:05:04 -0400 FCC: mailbox://ujusfglplba@yahoo.com/Sent X-Identity-Key: id1 Message-Id: Date: Wed, 13 Apr 2005 18:05:04 -0400 X-Spam-Score: 4.6 (++++) X-Scan-Signature: dd7e0c3fd18d19cffdd4de99a114001d Wed, 13 Apr 2005 15:08:23 -0800 From: Numbers Morris X-Accept-Language: en-us, en MIME-Version: 1.0 To: mipshop-web-archive@ietf.org, pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org, ietf-announce-request@ietf.org, new-work@ietf.org, avt@ietf.org, iporpr-admin@ietf.org Subject: Wonderful night of love after 15 minutes! Content-Type: multipart/related; boundary="------------76940554961468927" Message-Id: <003f01c53e04$b33c9350$0301a8c0@ackfjuh> This is a multi-part message in MIME format. --------------76940554961468927 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

Any man who is under 30, and is not a liberal, has not heart; and any man who is over 30, and is not a conservative, has no brains.

When you have to kill a man, it costs nothing to be polite.

--------------76940554961468927 Content-Type: image/gif; name="manifold's.GIF" Content-Transfer-Encoding: base64 Content-ID: <008e01c53e01$0236c380$0301a8c0@ackfjuh> Content-Disposition: inline; filename="coffeepot.GIF" R0lGODlhJgKaAaIAAEZJp7mhw/8AAAAAZv///wAAAAAAAAAAACH5BAAAAAAALAAAAAAmApoBAAP/ SLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKSSEQAMnoNAQAJ9 MqFTRwBLcFa/VklAQBZkG+Oy+pwma90Y6ffMqGqhEbAeQNg+6QpcCl56eBB+T3wNcwuFVWeOUg5Q ikyEAwCAaI9XjoaID01VmXeJk39ol6QShJqIlQpynKUDD4KhlKdRjZ67gb2QhZKbYSCIYLCdtwS5 DoSDvbURampv1GRZbWUN2BiXjAyEyaAQ0Zh9y7++XdERx+vos8zAvJENXsnf8oujyp6xhha8G0Xn mC46+tLxK1ZP2oKEqJTZiogrYL1gnjDaUyeM/5jDDxAphvsCi9xCRSEtorm2jQHLbgS2paEDx0I0 WOAAMlzoiQ8iTbdS7vQH753GjhyRqoMl1BUYNuZ0fhz4VGC/OhSp2nG37CfWnhIPcm12saHSaEf1 FFTJ4ZXAZ7rgSgXkld25DNX6lKFZ0wFMmDHNXBAHNeiXsBQU1v16Bp+Gd0zBmRz7MR5Dx9ASNSZr FZNCqRV9HaskypRUkbcobRbpzCJnwp2zKvx8Gp6gyYfY0vI4lXYc07F3L+NstxJmDC0V5FXelxuc 5M3FEOdodh3uCF6csp637viFVwwTpR46sbJljJWmA1i1UJZ50Lszw5OfDQzjsiPv5jYt13Iy6v/w tUeZaxTppksFbC123QZuVZBdcYgt9RBwFrTBRHLa7OWSYIFlARgFiymThT7BIbhdiOqs9h+IWETk x2IGLvTAcZgtSNl5oeUoYXmKDJRegb5J90eIKM4V4H37XcUdRia+d2Br+tmoATKaxDaFgrdM5l0F FgoE3UtnyNRNGt5QeFJSpkl5z4mzUbQlly3eld1485WniVzNvMkKf2YeWWKR8FGVRZYkDWNTIv1B WE6auvkmaIr4UbGdWGuGRx6DhbBX4pJfGUdhU9O0pI2HL3EYWF4fJtZnPShpxoWaSBKlFKhJitJq JnQ68pWOiuqZh4u6LUgOoJbN1cwyEK246D7/3CnbrJ+Q1noskP9UZ189vM7j7AYQAUIoQyYhS88h pXKooV4YLhfdBNOxKqEdsE5Yp1Y50ZqjF/FMcVsvpAUb0LT6sWjpvP6iIqVXoHiVDr0WXALUqjsW 6SgeCgMLVm3IbBohxB649611H1+pkr0PlCtGciVz2EaV7i7b6jmvJPorwWjJu1GOL+acayG7xtcr x1BGFjC0xeKoIzl20FZauzM2ynEzC04cRtLU6mrtYdj6zM62xpBFL4W5bOkriHt1Se66sTxHDcuK 2rmjODFWql2dhg0NJyqITk1tk00XkyfQPClF9LC0wUW4eJNaEqS8K469L3lSSwPe3qo6KSOU/x85 wTYGCh0XVXDpjB2HqGR6iXaHzE2BcqV1Gu35tZXP/XB3gOuoSrTcNXkncDXGLWvGEW7KNNSC6DPi qotn1vhnMG4X+fE5+a6O7kGPtPlgffZes1Qyi352mKKei64AZ6ctWOmh/WfQjpZJn5nslLb9nSG3 czp95bSg1/IVCH2u8aatwFx9BvY4uiWuUitqkD9iZaQkfYVOfMOfR9ZyvQqpxmbQe89W5JO92vkl fIDJy8ogAJOZoGtPH6NdwGDHLjY5z00e9MhpBmWx1gVvfcqzGXsu0UARBa+Bo3nLBidjlIYU5lLV 65tsxAUcHGariEajzPVw40QTtIN9PqzN7v/GlTKWXOgl5TPflU6HJuBh8R0Nc6EBVZgRBwLIftxx xI/auD+7bMRGnBGWRb62xMo4LDaCQ6GzbsIbtQjJj/IgZBlJcrV9EGtKd6SN17DGupt98BqXpEao +KI6MnIwJznMDxIFNMH4CcWGJnndOhQZxz0gsJLRg1h/9LgTemnqOo6UI/bsJsqq0MKMbnxgWszI Sn6VUgRLw0T/kNgfcSjRktZIlemkaTrnrIFLo1nRdDY4gQcdM1anZJkfPKUfb7bSlYvk5XSSeUul fSxbQrzgN3sYC6NUMD9c89h6xACZCqKoeRc7JzEzFZp7LqEG0hzhQRfK0IY69KEQjahEJ0r/0Ypa 9KIYzahGN8rRjnr0oyANqUhHStKSmvSkKE2pSlfK0pa69KUwjalMZ0rTmtr0pjjNqU53ytOepsAJ a0pGwILYS3myAwL62CEiheoTXyR1mcCsZP/ocpctZFAeCYHK8ag6Dtg4iEr862WVXgFVgtiMkXZk ZEic5dWzcgadbv0bMDX3C6pSlWk+fYxtwCWarAKSkkB95iys2jOAiOyq8tCKsuC6BVvUB7HFQwph 7TIJOhCUAt2yyjBLwlirte8qik0rWgv5qcsKFIaGFC1ZAqutTRwRlHnFlFZpx4tVlGZCgHBCq5Ba mRehY7abMSw0iLHVNJKGruzgqnCT2wlo/6xFck6l0BY8xR7fdrO3wDrecVcZpYggd0KtYtt3ubK5 cQrRU60ZVD7Kabmjrqm4z9JsbfMT2w90lxnoZW5QAWKL3TbtDoq4L3uXy1qr9Ki9a5rEge1KYPPQ tcDO/S00vjvZ6QIYs+axsITdW4fwnoK/CgZxbuC0ufFGmMPyxW96h4udDEdXvRR+8R0MWt//DoIP +wyEf1tzYvCymMch5vA+c6ziDUNYxz2+rng1uOAku9fEgZ0sUMOzY24xucFLDgVu96vfpvnThki+ MIr7gFy7afjII0lFdBuBq36pt8YmmOwuGrthXrqXYT9OMJDlLLLlSvk9UQ6kvJrwS8nI2P/ASdbw n9HR5CJzAM2BXg2hF5FPz2plgL5MMS5YFthksbm/nwyIp08Ms6rO2c5w9sCpD4sOgCiLsAmJDG9t zAxWE5bORga0NDJ7iD+GmniQ9a5k18xcDQfsGxi28WRj4WtH83auSOG1pmc8a9WuUJsvg12srRdm ut56r3hNNRVw7JBzsNbOkXa1noG8bnOXm9wphjR0aXwP5C7bz9EtVFyrS+yjyllo0pP3cp1R5krX Zxxgvndu2KbwTwt5aOqsMrt12+4DN5XVZuGauP9L5H3S1sYF1nCe0/zh4XacDyA73kRGDkmWF/nP S2Z4v/1QZDSPmdZYGfjKbx6LPIuc5xP/IvG4cVFlijv8ChJf99a47ejp/rscGt+4a1NOu901esJB x/nArUp1rbK8wmBG+p7nA3aVt1g6Zp+waHhpc5KHVcI/Z7GJ7wwPo2940ywqcZ2QC+Hv2o3v7e17 1cOsdvhSWuoZ8AylK6MZeW2Z6TYXPOMhrPh4I9Ihc18UZz0s9lzHnLwjp5Ey45ls+i5XuvppIuBz e2gv511I281vZ46OdZdnffY/Hup4dmh3xH+V8UNL5h5dnG1OSDsz/OBssEHGs0Lvy7FYbrHM064T yza/y0UlFKZzQpV+iRnPeJ52aJR0c6N71tpycnD639yJ15Lf9yxa71jfP/cHG/KpYn58/4P1HdcY 1c/JitZvWudaLNd7ZGZUd5d97VRWyyMuuzMFIfFrtRR2Z8V6rgdXEph0zFVwK+YPmgJ/IJhRHxiC JFiCJjhpJpiCKriCLNiCLviCMBiDMjiDNFiDNpgChnKDOriDPNiDPviDQBiEQjiERFiERniESJiE SriETNiETviEUBiFUjiFVFiFVniFWJiFOjAGWrhT4rMhZmA2YGgqoZAhmlAubLMcg9GAo8cb9CYD yZSDtbcJB6ZrTmJd0RSG0XRPozKG1/CGXbgDargAYrIumkRCpcIXJpOH9GaAAgVw4WYDx2cXThEM mjcR4uRFfuhJYMQcYBKISyCGYjQ+ef9IPl1UKpv4h5nkSfgUVNDTGQMEiCxgTqUBVd93KXg4hyuB DWYAGCZkQmdjil/4RaYIikowjCBUjITIi2RoPn2hDcvYjIN4KsM4fvIHeUWBajTgiPmiQwQYDy3G WZYjJqcSjeaIiCqzOtEoi8aIA2rYJaJYjupYjWOgiGfYHDMRj8QVdxPIeQ5nYdoTfI6ReReQOHan OSIhcqMEHAdEjh/EBtR0KuCjjKbDju14A2IIjKJoQl+oj10ECIPYEuqYCuqGaJ03FGEwXYUyWj5C gdKxLcUAVPiSYjQ3FhCojStDkegCkc1YkaN4SRd5UOKTLs2RjF9kUOWSKiIZkfnHaMT/8AslZ17+ oRPzFUUaQJB1FWF2F4AIpls16Q5rs4s8mYlq05PAGJRJAI++iDJmw5YfoonUyBJ0UUIjSXSdl3Pz cAoikzkrdGriaJFYqV/ell28UDkumSGmcpZnWYo9WY5oqQRdIj4ZGUKUSYZwmYhdBIYWtHlPmZf8 IDKR0T9OFphKtidpV5NcKTBRNz7noph1yZoJ9ZqPKQQa4pZ9kZQ+GY3q8hfqiJjXFH93WZIoCV3K x21Q1jqQgXfS12MUB3YI5mQTkCE/uZPB6IkgyZSzGQT5+CFm45vL4ZFfYiqD6J2yaZIlaZLDeZ7Y Z3+sN3/vp54l12U68yNfRW9cqCGu/9mYjumJ1pSdkIlJxKibn2idmUmgzqiImBmdEIdd/giVTjlt nTYfpNlCnDZg+eGc9Tk6qUOd09mf66iZ/pkEADpN5xigzqiM0GignliM8TiNTTkPU5Vophaa3PZz uahXCQRDrMcoz4l96KgXJ8SfQlqgQ8qhIXoEfWiii/mhK4qKKsqaT+qMwIl0r1h9VvqgOldmVWVO j6Z6ImFizZOh0bkX5EOUY5SYdFmWKIqdR+oDKWqi1UiNxKiKTDpNnaSTUfqiAlVWTXRsdecQlwYC kyhvpmZa0HmKITmiEimgqxOnbRoE9FiIeEqKTGCGl3SPzDipHmmeYvVLnAmh1tEKE//KJf/HdJ+J McQxqqw5VsO4mEkKhhb5qBc5ShbFhbJ6q3Dop6spUbaKq77qAoL2q8JaX6U6rMZ6rMiarMq6rMza rM76rNAardI6rdmpn9QKlr8ZCmG5i5+YlD3pohwZm+VphnMJJmTJit/oD67gTEKwHgioi+Y5dzfK C2mYrdNkrfdaXmxqheTJmB2JhnEpl9FUoNV4iNrqpE0Kl9aErrAIS7rHQjwQWp2Abfo3EsvjLAJ7 r9iZsXsYlACrsXQKm2HprVXSqkv5rfYKstsqsooqoAZFJBYTDHW4qy8wTkckSsp1qDf6lZfai7dZ ltgqjNSUsl2oUHKqmzxZE5tqohL/gIy82YwzMZLZ+qYmGx1Ri67Nhn0B+Kk8MClbSRwiR5C52JCC EYZpmg0RSZQ6+aqgKIpqe4pSSjas6LY14bRlarVSayhLup/mWJ5bIwox2mGjSZzFcSVv0gpxlwHc mJXJZSbstWTUha2qg6kgCpQl6rIeiw312phqia5LW6dn+a/no5T7uqhMO4p7ew+G55l4eZwwNgcs 9A2Lm0af91t4GLZhZzC0SqY6iTJ16btvubLGKJfXybnJGLIkSgFDWZkFMSaNyrDkmSq/6LcVm54+ OpgRQTxrl280G592uYHd5Snl9QcHlLCWW6SVa7o76aha6J3pa01nyrHJO6Z1+7OW/1m/97um2+qt 58u+74WXWHGTK3a7l+ELX6qNqvKSp5d64ntdHqSwwKupJyuebuC/7YuYlwu/LCuuk3qpRqq++amM tvmb/WoNSUu7AEyv12vAvVGczoaleoVg62eluFtBMSSyl/uaCRqu+GqMChWnndvBp9u03fC8FIyw fIuYpGIuBbuIGGZ9Jee64Mipg4lwi0VJ/KDAd9ecj4th3bu/9nsymUoqSxyrStibIMSqcPC5cSu3 d0uRy5ug6nuU0zmNSXlP42W9UsyzNuqXQaYLBnJAqxfANfx6yHGnRUq9BBqeZpyE42mUmdTGYizE 8Eu66YibksykkvmO/PvEpuqgJv/mNy1co/3YMahGmLDYxdf1xW+cyAzrmHfsw5tcmWj6tm58AS1r ulJrv7V8tsQ4kURqmp+8tZ3Hx7q3urN7KFVykBK6Wod5mEXcSWh7yWQ5zUIrx4EYyyfKsWxMqVxC tPi5y72coHZrivpowVobs1VpK1RJxdsLPd1bCvzGV7PTwKtcAWQqBZXpyuZ8siyDzlaIzRtMht3c zUjrwak7mUi8pCOU0H57nKP1WZYSnMu2bR8gsRWrE+SUWjoXtPaqxJUrvxqMluQajBz8za98tBrs qFXbxCg7xuh4PfL6nksjjsE5XoSBwGv4rgnoYxL4p6upz5Fqt3O6OQB9rU2YuBr/1cNInaxL1MjH SMlNjawWPdVWvVE1DdVXvdVc3dVe/dVgHdZiPdZkXdZmfdZondYpxdRqnQPsG71mizaSmrCqSJ4M 56JopwXsGgSqYHXfC6NQsh+by8FSPT5yuKptjRxMCdd36grOq6bdqs0LW9gN+ztAMGqDRm0Oegra hEryK9KTHbzCm9hEbK2M7c0fGpmxDNd4OtpSlHwa7QP4oCKilH+TcqOzm8/Au8ShMrpK68+krbyL LZstusZoHB0tbcLUm7V9HM8rwLMB7I1vB9hNY9NhFNclmrr7CYy2HNy9fdecyJ1purbHTbn9+dDK hNPzkZLuVqh/pxlKjT3iFJNR/5CQqddeDJlw0Xy+Dv3bQJvB3j3SB0vJYtjd81unmTy9PbwK6t2e jLaS5IcMLikpkrJVxhwMMrcLyZyT5o3a86vaIly6bf3WH4vaBp7JAy29j03Z69nMe1mHhQpe8NwB 8X1i9tcvP6J3uPKcLVvg69KdJwurAR7THg3Bvozixe3EJXrU6j3ABYwTLHyqbYGT6Xely0arceRP cOnjk3ou1wTibD3iw43NID7EHj7QB3vCYjq4oPnJVcxlmLItMId8WFq+8bCrmsjlvU2nAj3keXrg 1emqx927T/vSnejJGf3moAqAyBnRnNqB38XFGI7ouPzlJ76wScy7Ya7WJI6uZf8j3ngb6hNJ6H3u eonuxxWr6I9eG1cszCg2n4VJ6RYQ17zdoROgwyLO6WNe2Bhs5kmetPqr5MuZ0eztwhEWd6rKW/ON edlY35NemocMy/79srjO4rpu2tRrqb5e3r8M4Hw77PBZ7G4OXUtlyq2jo6yT47JO5GXLxCwakeij kePt54ha15LdpAPLrR48hig+x8oO290Iw/cGeAxu5xjmp36aP7EO7bfOi0Kdm2a6ot4M4lr91avd yfea79sOteFsvKwIpnrgzoF7Ws5NWmZSf/l9fYfqr81rsN782chL74walqfd7fp+80K+sEYr4P/O G1ybgJKnTBP+e433vx14Wjv/oarSmYdiKRA7n/Ey34PJHlGbHvVRSMA9SlFVb/VQ6Fdc//WC2lZg P/ZkX/Zmf/Zon/Zqv/Zs3/YeW/FujwLanpuYrvHBDJt8SNNi76bioD6XUgyJO6/w6vREy7Ym7QpP H/cDrqjxaPhnnr5ILFh9xCxbeHxSmcXwSeedWe/56/L+OqdHvfaY/MHmi/NEOvqlkA3MHLk+UPQH yHwGtOq/gHA2pNv428/6SfGprchqn60kvDpXS95kxMh22vMqzLqbvQPc+LVsAfh2lou5XbZCXevo W6eQ7O+Kf+b1SPf8mdy9ncGhX2xDo6Wu4/r0UeN3M+zTZYDOz1bObznhis9y/828RmrQaK/dQzzX Zh7S4Y8ApEszGkZgJALlgNtBb7l4m3ZR5hmCqAUNlzMtzsKiBImpqMAHQmxT8AS73mI4QdKGwabz CY1Kp9Sq9YrNarfKpu/H+MaYYXKRCBkigdGahl1x5VSiGC5Oz2DfwVn8EvEgI/gXFNghF6RmpGhG IXbE9IVGoLZ1iZmpucnZ6VnlaDPJ0AW5xNNIWbHYBcUXB1ej16JzB8NwZ3Vr4+eW2EBYI/rxxKr6 2IqMukqmNHn8GS09TV1tLRW6wii0zKw6apMd8LzdlPtKk7ibE6ZO2FKi+37S+7vrV2i+7sV6smho bBk5S9cKGjyIMCGVZNq6Df9UAwTcGYDZTuSC9cgdBXyFhMFDIWJfCjgbBQkLxO6jl19QFsUiSPGH KW/jKiq8iTOnzkwzRW0LCFOiv2UMK3VbcTFfuhj7OLLwiCEehZDzRg4r4REHPqgnuDYB4+gZya/l yhzdiTat2rUmhKaJSObhvzRnKcTNZpMWSaivmr57ylFpFZQgVUCFsZXlCsVOwDqEia3sqbFsK1u+ bA3iKTDMYvTkxtmtXYFBIU8VOahkagZOE6G7wXhKUgUe0knFk/h219jKkhD5mXc0pbhfInHGjDy5 8k1AHxOt640uUNCbjVEmXDheLr/tsO7yoJtKhogeIjIWYduJVxNIZDIyTYr/9PPjzoIvv48/f1eg cMGIju5NQNQZZwwvHxzo2YHrcJcebQryJtuDOgg2SDASsrSeMi4R2M+ARnUoHXz6jUjiiOS8hEpR oE0gVzNnnUjZHA+SNwIbgbUmlQgAZDgFIhno5hV2gczYHRQ1tdLicEeJ1ZZmJT4JZZRSWsPjlEfE aGWWWm7JZTXrHNKlP1iGSWaZZp5ZmILhoclmm26+qaWPLowJZ5123olnnnruyWeffv4JaKCCDkpo oYYeimiiii7KaKOOPgpppJJOSmmlllrpw6WaNgnRdS6R1BwRSUIXhlhs/OekcKmcaqp6Ou71AZ0J ySkBSbPlgx1rvNXWUA8o/0o2lH32bSolf+xNF990o0KTLCv9MTuXquFsIxeWQ36Qo5prUcXBaRO2 AERgerWFWohhFeiTs2cwSyymzQmHLGgCLjutsQCaVVFwpTQX4yywGbYLmGiVRwPBKYhbQ664iHsr TT8Ah8Z/K96LL7vtFmvGJECkyuTEjQGr4bMR49WDZPoyojGBi912x2tVFnSrwP8qFkGCVaWQ7Zof rrJzBT5sTCozxoEq4sUYHyNRUTCpeOxx9YI6jnRN95zsqh5L3YZr3ybCAni00Oz1a+J9i/NI+wgj bjoAk20czx9b3PSvQRv9ZMq9TnS11WTBjfVkH8JxcmhMZ12CuPVQteOB8f9cmwHbRkIITAr/tmNz ELyKHTLffxsZykB0bzlQ1MlS1sW7cfMzd98DuhU40BtS0VdV9XA9Ai2DeFeuK47nYAcIuSSctq6J 62xujHajXld7qX9OYkCuk/5evKOjTqdQSZ/VerPRPoG27CDketEtHskM++6w9c5iwDoEr3buFQO7 fbrliCEx81Ae6STTpUs/NPLqnUufcmRPQ0Uj1zsM9z2WvEYDDoID5qLwQKvARm0qUZhF3EdAkNXv dNTZoP2ONjKnTW9zbxuTBykWqqo9LSbVY5CuVAKuhU1AbA+kylhqZrk8AAEHOMTDE9jXq6B9Rn50 Ud0HSySa+kDHboMbYSr//ucc6Q1QHCCjoGqumJUJ8YGGbGPcDSGHD3Qcons/vBlASMgpzbXNFCc8 YnKSaITjqSxvK9wb1DxjhlAFEG77E2EBYRMesR2Ocgtr4GlkZSDKnGMe5VlbGXuEBg0Oa40pdGOJ UrW0NYToecWoYnU+eS8qdmOKSBqcvw5ZJMEsMIFSIR8VgrQOLs7CgvQwo6oyVZzO+C1YmwkQuixp okrKS0D9K2En7QWOIZKwkq0QpgkahgebJaiVWlTBLA12Ba9BAJvny8iCbPlCKD6sZymTiCn6eMNJ AhMzLWraL+l4BkRWq5dobNYwO1RK5y3mQgfDVoMMKbmvIUgL3BIJA585/8sL3QaI2gPg60j4EE8t b53IwZ8kU+VEvXGvVb2UGDiYWZYT5ZCf7cOQSdkgxjpEsEchCSTb1CehhYKTgHvBqC4h0LH9TJSi PPUTQ7OUqZ4KdahZJF6c1DjUpBpNQohUqlOfqp+WQnWqVK2qVa+K1axqdatc7apXvwrWsIp1rGQt COSWE66ZsmmlZW3rRoyaHHuoFU09dKtdUXDWisp1T2y9a1vzipy96qmufnWqnHY0kjqEwWu8kYM2 tVnSxc2pdilZyj7n5KBuzQA8DqRsA2fxKkPUSAYsCwZnbTMko6YWZ0OKxWnb4dnIQXab3SKtKwu7 ViLNLFa0HUFjbSjVzP8eSKCUXWWaeHutcTSOGBViLiBv8SAbcAt9rMGdP3Fz3QsO9w+KK6m/Ckra 7hLXHorF7ZswC1CDtYx2jWUvYglzEvEl1JqSdWkeTCLX975ikSX43S8eaIHKYSSGAkNE+tj7xe9t EbSz8wwf4mtNzCKiv7WIMFzNm1sKm6dwf2lvWnfouAdzZL8WGstBJSjXDUflNAClEF7n0cMwCsJl cgAf28Q4A4/4gcZrip2KDyOIn2LYTDt6rA4As9A1cWTEExoHAAiWxQQxxYyBQfJqCHyhGR4ZW/2K KUC19iBAKPClN57Qjr1Mgw4YTDE5JqmQh8wlxjH4rQMmLV6lwuR+Inf/zOESc3igYuXKdiTL3SzY QE1AaIz0sKA15nMtv2ijGaO5oEwp7W63+2Y4A3U8O/LFj9msZDy/Q8RzuoCIswVi5VKmyuqIR2vS p7MTTwU9iJ7pDGR8HUfX2sRmlnSuS11oNj+AsFfUNJsIu14VR+6fdL5yN18jX1QvhX2BObWzZWFL tqIGg2/4r+OifMFIFzolEYR2hIuUoUwbW0rCMHKz7xCIUIfTQQD1EaxluDAICYxX2Hm1gxDrw3H7 92YFxvGXYtloaRuwd2IWdzTL9gp75wArsauvoNdtpklv2dXY+u28uynnaONbbViaboUmgKPm1lbW wDg0QsVbIW9uF9za/2Wuub07OwVNGeYhn/LIsdNXjLOzDoTBcbbk4HFnR3wEw1Pl1tSa2lPpwd/9 BPi4hWv13dR2YUAqr9ON51nCOsXruHmyLIosksOm9ee4FnpSX6ZUwLrdriy/qtznPtbVbvXueBfr KbPK974LfvCEJ7zoCo/4xCt+8YxvvOMfD/nIS37ylK/8Vptq+cwP/clZj0bnZeNAzpvdEIj9/E46 MEPMP1P1uGC95gGF+m1eeAumh6BrC6az2F8G9bq3Qu1d5frX96n3FSi9g1kkeuSPXvT9Tf4NWsZ5 3Fud+aFfbAiiT5vUd6BgtMH+8zm/Q9eO/vvjXyz4s38D8T9Z9qV3Pv/52W/q86df+I/aPkgcXHw7 AEK/FJ9h+9H/fN2XfwMYe+W3TVOBfAJYgE6mf8UngAGoe/ZXMMjnfxSIgN3HgMQXgBD4XgWoXwq4 fk72gOZDf4Syfve3TbcXASh4ggvogAd4gg5odd8SgwJYCww4fyeIWDe4gSv4gtcHhDG4Oy6YdRK4 fT44fxiAcuGnezUIgCW4KNN3foYBcE5WY62kZr5zfPNnAZz3AMzHQNN3e62nZk82J/anYA5YhiSQ eiHQhq3HfRL4eU5mdkdYhHgmgk/YaaJ3hlUofxoIhYcigUG4heBnh9c3Di44gB84a4gWfo1Ihp2n iBIQgp8nhTewehP/KISht4dLOIg/mH4SeIOAeIc6GHyBeCcaaHwpKIf754YpmIRomD5toRt+OIas KImr+H0WeIHs90yL44pP+IOHSHxGuIevmH8aCIgNsISouCi9t3zNh4NqFgdA+HxvqIg6uH8N6IHV J3sPSIQOph39l4QYSIsWuIkbgXy1oovWWIkTeI09qIstOHvOGChlWCvXd37JN2zAWGovsIXUSH7i GINryIny92/61YzFlzMA12RrUob4J4wMWWTal4vYN4gGmZC8OJATaY8f2RX1CJIjqSW/R5InGSdO iJIryZIt6ZIvCZMxKZNhcoqiMJOSV4w5InqWY5KyEWsiyT25B5Q3/1lYBsZ9K8aQ0qWSndCTr5R7 c0WUGFaG7uiNj1Bk0kePO8l+DUh9FEl+RTZ+EQl/fraH47eUUbluqOeHE/mJ6JeVSUmNsYdDRPhe vtN85liJFhiXjKiQoIiWQsd7H4iE8LhYCTiAyQiM5bh+i6kdhqmNB2iMP/iOqjiUf9lWHsiBFjGG TciEwNh729eOdgmA9qeWfChmr2h/WumXlmlsuseOh5kOv8h8w3iMMEgeARiDfCmRoNl1QGiEauZ/ rOl2EYh9nZeLt0mctKmYpvaGzLiBaymDvamAVfGOwolx0PiW5ogLrVSWILiNBPh/uWmYdOAdh1md mcmZ1jl3xFeD7v/Xi0FohhSHkO4XmsoXixQHfy2AjHWolW2pnq+njJX5nwNqBcoIlQSKoHtwiwnK oA3qoA8KoREqoTxVkxPqjP7JlOqHkEepoBZKeGfJCcdJmDzRlB46ZP6plQBHj91XkPt4EexJh2Yn n35YfvRZoSY6Vir5mI+phncpl/1lKyhFhz7jo/2ol3fpnDiKd20phna4ik1qnK5lHod5iNvJfTp6 o0oKVk44iIuZiMfYhWbof2JolV2ZnIP5lVcYliWqpX71idCYep1omG0RYOUIi5lYjZ9Ye1Npp21q bFxKpsAZj0mKgt8CiGeadSCqhITqp61Zi0gqkLnZf6TZjshYmAf/yIE4iJv42ajr6QIpOp9IupGj mpQjyqGUuqbeZ6Odyqqt6qqvCquxKquzSqu1aqu36qa4qnlOaHUaCYmwiaF5uYFVAIYCylJZqqtR WIPkqX+3KJDDKl03mqjG2gZsmqyVMp9ziqkcepXot4Y2KKP7p5pdyRqnMo4tipHJx6ffCpvX+jlm RwhaiKfI+IUU+KPMuYj2+aPaaamLiKSV+J1PMY8c6a50w5huGaSNSIyPmqmZKYC2+J7PGS55iJi8 +H/WV7DM05cgQDa5yIX4mn3Rp6JtiIQ7+IhcF5/bmn7tSbEjS5FbmLEGK42VuqjW15j8N6TCep5e 2q9JGJajRrGB/3mnvRp9yxizlyKpjMih23muD4ib6DinPFuzlpqe2WeMLduA1me0R4utwKiiX2ti 6IqpIgukDuuwBminPAqwIDi0b6ioXGspRXhkqnmOcEiRVwm2dbmfbxCl5seiNLqiAMh/9IiscFtW W2u4Mhm4iWuZvsq4jwu5kSu5k0u561S4lXsmvEoeG6qPs+kE1rocLou5g+J9TQixVkmsl7sTfTm6 gpKtfkmZFpF88leWBDm4BumrYvmynQt/Mcq7d9t8jqW6rZsl/Xmxdru0iPh9A4hZwtqw8Wi64Cm9 zxmwV+iY4vqArEu8f3KxNAutXxmN2yqvbNlwTqu1d2iucUgII/8Lp8nps8O7vVKSl4qIsdaIutWI sMhohcEIivvLojv0s9RHqXYQo2wYvUlIgvELJ4R7vD1reos7vqFoiPwrhPyZZuilXLVZv3mbsC8o ugrMJ0mrre36vZhasgvJjK2onJJZi6GHpi/ImQGatQoGvyBcIkQLtneKvFb6g3YZnPfKwrC4l/ba l495wm5JjtAJuja8Vjq5uWibkDtJmus7pkk7wdzalfQZqqM3wIL7qRYrn33KxGNMxmVsxmeMxmms xmvMxm5arOBrK39mnNR6BW8KhgR7E0vcxjlxqF7LtHuhx51gx8gZyIJcyHs8K5bIna2nkrG7u49M rrr7fmNplUL/Wppeq43hCn5/6H4RCadijMiW0ce9WKWXirEhaKT+CrXTa4qlusO127DUWIfxGL4H nJfQmcChfHpgaL7UO7U6zLY8HJ0yoKnE7IYqbMp5Cp1WKqng2JtvahJlq8sVNYcsQ8C93JZHyEim KZla1ml3+4/Ju4Zc/LU4NZVyuJvBMGH4C4faO82irMgXOM7oq7DW/IvGLHvFvK2DrJmQyZ/xp7/4 6cn8G4Q9+85rMcrwyLLJ7M8oJZ19KqO3CKiAzJXj2M0m3I++eZGuVsMHrQnx/I12zNC+HJgVTczp Sbgc2MJ126MsOqzQqc3f+LxQ7NGVQYqRfBufycuoCric+rGq//rFnZvT1azR4drDWeuBzifJXdrR NX24dOzUGHfIUZ2Wb0vVV43VWa3VW80JTX0fXs3V03DHLB2UmGfVEYuVgyGjtOiTHinEUB3WH00e 0tpUfOoKcZy1UvB7GBqtwMfOcY0TWhR/a92id4ty5EzT14jJVuyxdmu8oApswLuVfzu4P03OvQzY CZGoPyy0VlvO6bmMnRjSfNm3suud2euY9vmxFYgRrZzDSpvZCkG0wZmvfw2CtL2aqSmRTwvMoKyY mqrbLf2wiSmeL2ioon3WsS0NJEC7hQjQ+ZmD3EzK+PWKPFiuIcnMCTKdysl8wmvMrUykyzfCym0Q D7yb+AqcIv+ImaLA3Jf9sCfbs4kItO77gYWto43pwWOq3g1M3uVtYjD7qdsqrHwNijsLsozql1Ir wdr9sUHMpBMrsRHIjuPd39ZgelSof+VZqqyruYWpwt14z9nroxbd4Cptns9d4qK9lxWOE+Yd0ADs fIhtqNSpXAHNud0X4L9L36dJ2bJHBxAuy8pXkfvK4kVu5EeO5Emu5EvO5E3u5I9rgDQ71p4wz4N9 44qa2OX9nU/OlAvd2K68CS9MqOyZ2ILKx1vO5Zqglo84x6e8yectxXSrsv3K1Ge51pQs2R0Jqu5Y urOJuGnuewfOsQsa3UTKjfz3vhnRz4RZyghInP83xNdI2zv/O+kB67yAfgmU+optzsz4PczDzd7t PZHljOAe7OmlzJuWKq+ojuKXjula0MU5SOi6GL1E+8jtQA/mes0lDNOmFbTByNSb+gezS8ivjgnd XbacvukwC5oA/LvJO+pCvqETJqYFHrRfSI7eit4rfdvGDut/UTgorLKKWOskLs43M63me4dWKuHK Ges/Td2/6ureTqz2LOV+vJxwieikDu3l+KPpS+fde2/rTb0ZzufgCdf0DtH4OsfuObePXbRybttR vMx3+sJlmeO5q5M1SOapGvFgrfAZusuEHvJ8le1nztYlz703rhABqvIvD/MxL/Mz/+TzbA4oHubc +cbsretZ/2DzWTDVMt+lxBP0QYmCT7CsNzr0WZDLNI/ddqu7BxuotOui6Op96ih9gPyv6Yp/kpzg BAnjM3rgTi8FaNrK4SiPJNt+UaO2qo2nc1nNeWjEVZjKUqewNEzSIVjqZO8qqGvfAK3pf7/PGmzn u17Cu6iHLYvm4nzgCi7abs33pOf33Dyw0e2FIBumFjzn+3mbpl3gmE/QjO/v3fre+Bz5RsIyOA/q io3b1pjNiZnrwNpjDO7Zh/70iDjb802mp/848rzSgLv5p4vFR3+Jnv/bZ0pwjNScjl/MTc/7S3/i wq6d5X7wJr7o/370vsyFV3j7ae+vwcz7TumF5rpfy4/DP/+OlbY7+50bI+1Zul8c+vAn2DXK9QYd /veP//mv//vP/whAutz+MMpJq7046827/2AojmRpNkFwrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/I pHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4Q1KQOI AwAqKIgRAY4LkImUlRABAImLD5AAEJmKjBOHmqKNnpeRCqCViSkXKaybDpOPqiiTiLO0raUUtakD DLm9iZLFuqYKxMgTuhGZqLSsA68N0ZzPvMIKiMqFLpjF0su3KJnDyJTbvcqdD74U1JS7x+Tn3Kvq 3hXMlO7/5oahczAvXrp93w4+GlhuXz5/re5BbOWM3wNsjcZlzBaQwLtu1cDFmFSPpMJgJy1E2yUu pD18HdmZagnwXkoCmRK2/KWIJaiZMT2ayzXz5ylOGFEqbWgBGEFtTDusuwjgHiifUEF+i+aSQVKL Il305CjK6babo8B6VZTOalYJSa+p/chxbUKPcS+yfUrO7Ma1NvV1FRpY6OC/dY/lS7sYsWEP9PT2 Vcsga04H3vZW7ko5rAlQth4GNetXQucFYOm2LMyLNU7NhEPbhQYbXuPNZUffoiu5LbSqspc+7heU QOriFHR1rkrudENReTvxHq7Vc4vL0KyVlsSQelrXi3JL/7t6wTnqrtMFLsaezbXxwwvYb1/W3Xz1 cqzzolW/Xzhm9MhVtJNc0qR3DXD0NXYZe7Gdd5d1IMzn300SEojBO6vBEqB8td3EoIVwdTihYiRO wGF+8JWYWFQ83aZYbi6WV404ViH42oMsvmfKgoMxaB+EHRgY3IremZaiLYuQp6F7DTZ5VnxHvude LuFJIKFTQvqGXzAPXrlbgDkeuFiFyYU0yY6a/agjlDDS19xgagKpgX5WOvQlQg5eqJwxF9B51JbC fdgQk4bRo5Od+fippZPciaiYQwep0+Y0WU30j4CCeWUjmOwlRdcttcUpJwbM6WlnpMiIImpDlRC6 io1Ivv90SXcFtYojTJGhqk58sKZS4D5TIqprO4/2Ep1Dt4IF1VcxylUWQ526NN2qo1agKJGOkYla PS2yZZS1ji6apVm16uLqNLL0x+K1gBYa0a1FUgimu+8+ycFxLpUKErimhKKPlh9SW+13pi405rzU nnlelIvG2q69Nx50bogANiuOrHX+OrFj+KgLMY2HNluBWtGowCy8JJsJ20cBCTzwkJdMSqS2+kwp XqTEMempbusdZpI8Ue5ssSpZQqlxkDx7zPFr8NEcAWXP6BtxnY1hGGpIHbr88icMa+PlwSI3bO90 P5vI8JphNixo2Q63pyLEgjZw3MYekzbvdt++rQFlZ+7/7J7UW36YU3pab93akF8rLXfQmqWnZMYh 3uNcXHHnPWK7iWPcm+YZZJ72iGzHi8Fy5r6JY2eZ3dZJVd8UbvjigZV9ZXdOG5ZQ3gZazjW3gilD pzho3sVn5GTpzR9gt88VbosGK278oM4b+Q0xk6UYes29dgPa6ywQJQnbnotOm78JDmag91SbrztI 5r8Vt2HBKr9y0pEWxffyjMHstIQlPy9jyL26yrPe8qjAVAV/3PtASyKytLdZ6lJrUUQrahIMQpXr SAts1VMetD5cabBuHbng9BAIs2zZiRFf+xWypMe1DkHkWsOTS4pcl0D1mGuEQwMbnnBhKLe1kFCk SMYvgqjBu6khBUwZ5F34hkG9uxQtf8J5oCs+pxhUSNE+zlndrDShs5go7D/wqqEYx0jGMprxjGh8 A3PWyMY2uvGNcIyjHOdIxzra8Y54zKMe98jHPvrxj4AMpCDtmMZCGvKQiEykIhfJyEY68pGQjKQk J0nJSlrykpjMpCY3yclOenJUCQAAOw== --------------76940554961468927-- From vvxpybqumgr@email.msn.com Thu Apr 14 06:44:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25792; Thu, 14 Apr 2005 06:44:35 -0400 (EDT) Received: from [61.177.34.85] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DM1zh-0008L0-U6; Thu, 14 Apr 2005 06:54:51 -0400 X-Message-Info: IGWJLN695wPHTylxEVdv078uqw1+Qyly671mPWT Received: from mail03185.zo.globalnet.co.uk (208.182.112.8) by rhn282-qg66.globalnet.co.uk with Microsoft SMTPSVC(5.0.2195.6824); Thu, 14 Apr 2005 05:42:24 -0600 Received: from F8 (m14.90.34.118.jgwv326.e.globalnet.co.uk 88.195.65.64) by mail355.ef.globalnet.co.uk (36.082.22w993/63.876.8) with SMTP id a16TD98HTvs46; Thu, 14 Apr 2005 07:35:24 -0400 Message-ID: <4fvo168p27u2lzz$vl335usa19hgg313$ptl6p72@TVPX6> From: "Lee Melton" To: "Simple-archive" References: Subject: xExttandder is here now! Dont waise your time cosponsor Date: Thu, 14 Apr 2005 05:40:24 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--RFIQBC135011GEPYYB" X-Spam-Score: 19.1 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ----RFIQBC135011GEPYYB Content-Type: text/plain; Content-Transfer-Encoding: 7Bit New... and improved: exxtend your tool now! simple, safe, quick ! a few minutes and you got yourself a hugge tool, with permenent reasults and no surgary needed. you'll get tired of scrrewing, for sure :) come now! The new, bast Exttandder online website! http://fraternal.y73.net/pe/erika/accentual.htm james leon holmes - holmes has called pro-choice activists nazis and compared abortion to slavery he wrote that the wife is to subordinate herself to her husband. watercolours prints two sizes signed by the artist affordable seascapes nature coastal landscapes. it s only been three days but i ve already had more things happen more things i ve witnessed that i have been involved with and that i really need to sort out. my connection to blogger has been slow lately i think i m gonna have to fix and clean out my computer this weekend. why else do you think bin laden was so happy to scare them to the polls then made no attempt to scupper the outcome? it s been a few years now and maybe you re right maybe it s better now? time to dust off my old neon whistle and my vaporub maybe? sfondi tramonti desktop skins inter sfondi inviare pc sfondi descktop wallpaper desktop wallpaper sailor moon sims skins icone download anime sfondi immagini. de bestelling is gisteren gekomen en we zijn er erg blij mee ziet erg goed uit en ook het boekje is erg leuk. i ve been remiss i know i m sorry i haven t posted in about a week here s the good bad and creepy. message nbsp nbsp how did you get to be so adorable? i hope you like my christmas present to you love grandpa. willing to trade for samurai x complete trigun complete berserk complete an d about every hentai out and many more anime. hi ich suche eine gibson les paul standard lefthand !!!wer ein angebot hat schickt mir bitte eine mail danke schon im voraus jockel. tell us what u thought of the show-- i know we didnt even get to our new songs better songs but tell us what u thought of what u saw man sfp is good go them! ----RFIQBC135011GEPYYB-- From simple-bounces@ietf.org Thu Apr 14 08:22:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05909; Thu, 14 Apr 2005 08:22:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3Wd-0004Zn-IC; Thu, 14 Apr 2005 08:32:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3Gm-00050I-T8; Thu, 14 Apr 2005 08:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DM3Gk-000501-RX for simple@megatron.ietf.org; Thu, 14 Apr 2005 08:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05257 for ; Thu, 14 Apr 2005 08:16:17 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM3Qa-0004JF-UC for simple@ietf.org; Thu, 14 Apr 2005 08:26:38 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j3ECGCO8023687; Thu, 14 Apr 2005 14:16:14 +0200 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 14:16:13 +0200 Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 14 Apr 2005 14:16:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Simple] message-sessions-10 WGLC: unique message ID and failed connections? Date: Thu, 14 Apr 2005 14:12:55 +0200 Message-ID: <40447669E52A6A498D1AA4B52D18DCA7973B57@esealmw105.eemea.ericsson.se> Thread-Topic: [Simple] message-sessions-10 WGLC: unique message ID and failed connections? Thread-Index: AcVAV/Fvh3C0cmKhQA2bS2YiD3gDbAAk1FNA From: =?iso-8859-1?Q?Ignacio_M=E1s_Ivars_=28KI/EAB=29?= To: "Gonzalo Camarillo \(JO/LMF\)" , "Paul Kyzivat " X-OriginalArrivalTime: 14 Apr 2005 12:16:12.0875 (UTC) FILETIME=[BFC491B0:01C540EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable Paul, Gonzalo: I agree completely with Gonzalo's comment. That is why I was suggesting = that we just add the paragraph from RFC 2822 were the uniqueness of = message ID is defined, i.e: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc2822= The "Message-ID:" field provides a unique message identifier that refers to a particular version of a particular message. The uniqueness of the message identifier is guaranteed by the host that generates it. This message identifier is intended to be machine readable and not necessarily meaningful to humans. A message identifier pertains to exactly one instantiation of a particular message; subsequent revisions to the message each receive new message identifiers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc2822= That would not introduce any other disruptment to the draft, would it? /Ignacio -----Original Message----- From: Gonzalo Camarillo To: Paul Kyzivat Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list Sent: 4/13/2005 8:41 PM Subject: Re: [Simple] message-sessions-10 WGLC: unique message ID and = failed connections? Paul, > But, as with everything else, this could get complex in a 3pcc=20 > situation. A 3pcc controller might do a transfer using reinvites. As=20 > result, one endpoint thinks it has a replacement session, while the=20 > other thinks it has a new session. The guy who thinks its a new session=20 > can't very well know what message ids had been used before. I agree with you on this one. We have already been there (e.g., the=20 comedia and the preconditions stuff), and relaying on the concept of a=20 SIP session to set the scope of any media-related identifier is not a=20 good idea. Paul and I tried exactly the same in comedia (using identifiers scoped=20 by the SIP session) and cocluded that they did not work. > Its only > soluiton is to use message ids that are guaranteed to be globally > unique. Yes, I agree this is the way to resolve the problem. In fact, I believe=20 this is how RFC 2822 defines uniqueness of message identifiers. With=20 your proposal we kill two birds with the same stone. We align with RFC=20 2822 and we resolve the session mobility problem. Thanks, Gonzalo _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From atqzdkfv@palais-jalta.de Thu Apr 14 14:39:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10444; Thu, 14 Apr 2005 14:39:04 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DM9P4-0003u0-SC; Thu, 14 Apr 2005 14:49:29 -0400 Received: from [213.217.62.38] (helo=SERVER) by mx2.foretec.com with smtp (Exim 4.24) id 1DM9Eo-0008At-4m; Thu, 14 Apr 2005 14:38:50 -0400 Received: from ybvwput by 213.217.62.38; Thu, 14 Apr 2005 11:42:12 -0800 Message-ID: <003001c540ca$d4d816b0$0301a8c0@ybvwput> From: "Esther Krueger" Reply-To: "Esther Krueger" To: mipshop-web-archive@ietf.org, pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org, ietf-announce-request@ietf.org, new-work@ietf.org, avt@ietf.org, iporpr-admin@ietf.org, midcom-admin@ietf.org, sip-admin@ietf.org, rtgwg@ietf.org Subject: Chose place and time.It will do the rest. - angelic Date: Thu, 14 Apr 2005 11:42:12 -0800 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0009_01C540DB.2D898590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 19.8 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C540DB.2D898590 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FJ_01C540DB.2D898590" ------=_NextPart_000_00FJ_01C540DB.2D898590 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable http://www.qmbfrkwdeagwclc.n2qg96n67y58mxq.bnamokebn.com/ His ignorance is encyclopedic Obstacles are those frightful things you see when you take your eyes off your goal. Never interrupt your enemy when he is making a mistake. From the moment I picked your book up until I laid it down I was convulsed with laughter. Some day I intend reading it. The secret of success is to know something nobody else knows. Change is inevitable, except from vending machines. A woman knows the face of the man she loves as a sailor knows the open sea. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. Too often we give our children answers to remember rather than problems to solve. While we are postponing, life speeds by. Opportunity is missed by most people because it is dressed in overalls and looks like work. If you find a path with no obstacles, it probably doesn't lead anywhere. It's not that chocolates are a substitute for love. Love is a substitute for chocolate. Chocolate is, let's face it, far more reliable than a man. Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. I've had a wonderful time, but this wasn't it. The great thing about television is that if something important happens anywhere in the world, day or night, you can always change the channel. When a friend is in trouble, don't annoy him by asking if there is anything you can do. Think up something appropriate and do it. First they ignore you, then they laugh at you, then they fight you, then you win. When love is not madness, it is not love. I do not fear computers. I fear the lack of them. Logic is in the eye of the logician.Who so loves believes the impossible. Any man who is under 30, and is not a liberal, has not heart; and any man who is over 30, and is not a conservative, has no brains. The full use of your powers along lines of excellence. Many a man's reputation would not know his character if they met on the street. Memory is a child walking along a seashore. You never can tell what small pebble it will pick up and store away among its treasured things. People demand freedom of speech to make up for the freedom of thought which they avoid. The problem with the world is that everyone is a few drinks behind. I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. I find that the harder I work, the more luck I seem to have. It has become appallingly obvious that our technology has exceeded our humanity. I would have made a good Pope. The only difference between me and a madman is that I'm not mad. It is dangerous to be sincere unless you are also stupid. Don't be so humble - you are not that great. Once is happenstance. Twice is coincidence. Three times is enemy action. I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter. You can't wait for inspiration. You have to go after it with a club. A positive attitude will not solve all your problems, but it will annoy enough people to make it worth the effort. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? Glory is fleeting, but obscurity is forever. Human history becomes more and more a race between education and catastrophe. If everything seems under control, you're just not going fast enough. What do you take me for, an idiot? Black holes are where God divided by zero. Friends are as companions on a journey, who ought to aid each other to persevere in the road to a happier life. The opposite of a correct statement is a false statement. The opposite of a profound tru th may well be another profound truth. If you want to make an apple pie from scratch, you must first create the universe. Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. Thank you for sending me a copy of your book - I'll waste no time reading it. When I am working on a problem I never think about beauty. I only think about how to solve the problem. No dictator, no invader, can hold an imprisoned population by force of arms forever. There is no greater power in the universe than the need for freedom. Against that power, governments and tyrants and armies cannot stand. I would have made a good Pope. God is a comedian playing to an audience too afraid to laugh. What lies behind us and what lies before us, are only small matters compared to what lies within us. Be nice to people on your way up because you meet them on your way down. Success usually comes to those who are too busy to be looking for it He who has a 'why' to live, can bear with almost any 'how'. It has become appallingly obvious that our technology has exceeded our humanity. Touch is the most fundamental sense. A baby experiences it, all over, before he is born and long after he learns to use sight, hearing, or taste, and no human ever ceases to need it. Keep your children short on pocket money - but long on hugs. First they ignore you, then they laugh at you, then they fight you, then you win. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. Basically, I no longer work for anything but the sensation I have while working. Abstainer: a weak person who yields to the temptation of denying himself a pleasure. We have art to save ourselves from the truth. We all agree that your theory is crazy, but is it crazy enough? It's not that chocolates are a substitute for love. Love is a substitute for chocolate. Chocolate is, let's face it, far more reliable than a man. When we drink, we get drunk. When we get drunk, we fall asleep. When we fall asleep, we commit no sin. When we commit no sin, we go to heaven. So, let's all get drunk and go to heaven! If you find a path with no obstacles, it probably doesn't lead anywhere. A doctor can bury his mistakes but an architect can only advise his clients to plant vines. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'. Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. Life's challenges are not supposed to paralyze you, they're supposed to help you discover who you are. Too often we give our children answers to remember rather than problems to solve. When you gaze long into the abyss, the abyss also gazes into you. Black holes are where God divided by zero. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. The full use of your powers along lines of excellence. We all agree that your theory is crazy, but is it crazy enough? If you want to make an apple pie from scratch, you must first create the universe. Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. The Babylon project was our last, best hope for peace. .. It failed. .. But in the year of the Shadow war it became something greater: our last, best hope .. for victory. The year is 2260, the place: Babylon 5.When love is not madness, it is not love. A doctor can bury his mistakes but an architect can only advise his clients to plant vines. A clever man commits no minor blunders. Reality is an illusion that occurs due to lack of alcohol. It is unbecoming for young men to utter maxims. Time is never wasted when you're wasted all the time. He who has a 'why' to live, can bear with almost any 'how'. No matter what looms ahead, if you can eat today, enjoy today, mix good cheer with friends today enjoy it and bless God for it. Make everything as simple as possible, but not simpler. When ideas fail, words come in very handy. I think 'Hail to the Chief' has a nice ring to it. Three o'clock is always too late or too early for anything you want to do. Education is a progressive discovery of our own ignorance. Try not to become a man of success but rather to become a man of value. Not everything that can be counted counts, and not everything that counts can be counted.Sleep is an excellent way of listening to an opera. Beer is proof that God loves us and wants us to be happy. When a friend is in trouble, don't annoy him by asking if there is anything you can do. Think up something appropriate and do it. Friends are as companions on a journey, who ought to aid each other to persevere in the road to a happier life. I find that the harder I work, the more luck I seem to have. Thank you for sending me a copy of your book - I'll waste no time reading it. You can't wait for inspiration. You have to go after it with a club. Basically, I no longer work for anything but the sensation I have while working. A narcissist is someone better looking than you are. When I read about the evils of drinking, I gave up reading. If a man does his best, what else is there? Fill what's empty, empty what's full, and scratch where it itches. A little inaccuracy sometimes saves a ton of explanation. In the end, everything is a gag. The secret of success is to know something nobody else knows. I discovered I always have choices and sometimes it's only a choice of attitude. The mistakes are all waiting to be made. A witty saying proves nothing. Luck is the residue of design. Love is the immortal flow of energy that nourishes, extends and preserves. Its eternal goal is life. Be nice to people on your way up because you meet them on your way down. Whenever I climb I am followed by a dog called 'Ego'. If y ou haven't got anything nice to say about anybody, come sit next to me. Egotist: a person more interested in himself than in me. The game of life is not so much in holding a good hand as playing a poor hand well. I do not consider it an insult, but rather a compliment to be called an agnostic. I do not pretend to know where many ignorant men are sure -- that is all that agnosticism means. Do, or do not. There is no 'try'. This book fills a much-needed gap. First they ignore you, then they laugh at you, then they fight you, then you win. If you can't get rid of the skeleton in your closet, you'd best teach it to dance.I don't know why we are here, but I'm pretty sure that it is not in order to enjoy ourselves. Facts are the enemy of truth. A woman knows the face of the man she loves as a sailor knows the open sea. There are people in the world so hungry, that God cannot appear to them except in the form of bread. A woman drove me to drink and I didn't even have the decency to thank her. It is much more comfortable to be mad and know it, than to be sane and have one's doubts. Thank you for sending me a copy of your book - I'll waste no time reading it. If you ever reach total enlightenment while drinking beer, I bet it makes beer shoot out your nose. All are lunatics, but he who can analyze his delusion is called a philosopher. He is one of those people who would be enormously improved by death. When you have to kill a man, it costs nothing to be polite. No matter what looms ahead, if you can eat today, enjoy today, mix good cheer with friends today enjoy it and bless God for it. It's kind of fun to do the impossible. Love takes off masks that we fear we cannot live without and know we cannot live within. God is a comedian playing to an audience too afraid to laugh. Sleep is an excellent way of listening to an opera. First they ignore you, then they laugh at you, then they fight you, then you win. The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands in tim es of challenge and controversy. Glory is fleeting, but obscurity is forever. 24 hours in a day, 24 beers in a case. Coincidence? Treat everyone with politeness, even those who are rude to you. Not because they are nice, but because you are. A witty saying proves nothing. Life is pleasant. Death is peaceful. It's the transition that's troublesome. Always remember that I have taken more out of alcohol than alcohol has taken out of me. In any contest between power and patience, bet on patience. When I read about the evils of drinking, I gave up reading. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens. The power of accurate observation is frequently called cynicism by those who don't have it. In the End, we will remember not the words of our enemies, but the silence of our friends. A kiss makes the heart young again and wipes out the years. The only difference between me and a madman is that I'm not mad. Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. His ignorance is encyclopedic Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Love takes off masks that we fear we cannot live without and know we cannot live within. Glory is fleeting, but obscurity is forever. In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands in times of challenge and controversy. We have art to save ourselves from the truth. We didn't lose the game; we just ran out of time. The significant problems we face cannot be solved at the same level of thinking we were at when we created them. To love oneself is the beginning of a lifelong romance ------=_NextPart_000_00FJ_01C540DB.2D898590 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
3D""


His ignorance is encyclopedic Obstacles are those frightful things you see when you take your eyes off your goal. Never interrupt your enemy when he is making a mistake. From the moment I picked your book up until I laid it down I was convulsed with laughter. Some day I intend reading it. The secret of success is to know something nobody else knows. Change is inevitable, except from vending machines. A woman knows the face of the man she loves as a sailor knows the open sea. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. Too often we give our children answers to remember rather than problems to solve. While we are postponing, life speeds by. Opportunity is missed by most people because it is dressed in overalls and looks like work. If you find a path with no obstacles, it probably doesn't lead anywhere. It's not that chocolates are a substitute for love. Love is a substitute for chocolate. Chocolate is, let's face it, far more reliable than a man. Anyone who considers arithmetical methods of producing random digits is, of course, in a state of sin. I've had a wonderful time, but this wasn't it. The great thing about television is that if something important happens anywhere in the world, day or night, you can always change the channel. When a friend is in trouble, don't annoy him by asking if there is anything you can do. Think up something appropriate and do it. First they ignore you, then they laugh at you, then they fight you, then you win. When love is not madness, it is not love. I do not fear computers. I fear the lack of them. Logic is in the eye of the logician.Who so loves believes the impossible. Any man who is under 30, and is not a liberal, has not heart; and any man who is over 30, and is not a conservative, has no brains. The full use of your powers along lines of excellence. Many a man's reputation would not know his character if they met on the street. Memory is a child walking along a seashore. You never ca n tell what small pebble it will pick up and store away among its treasured things. People demand freedom of speech to make up for the freedom of thought which they avoid. The problem with the world is that everyone is a few drinks behind. I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. A book may lie dormant for fifty years or for two thousand years in a forgotten corner of a library, only to reveal, upon being opened, the marvels or the abysses that it contains, or the line that seems to have been written for me alone. In this respect the writer is not different from any other human being: whatever we say or do can have far-reaching consequences. I find that the harder I work, the more luck I seem to have. It has become appallingly obvious that our technology has exceeded our humanity. I would have made a good Pope. The only difference between me and a madman is that I'm not mad. It is dangerous to be sincere unless you are also stupid. Don't be so humble - you are not that great. Once is happenstance. Twice is coincidence. Three times is enemy action. I am ready to meet my Maker. Whether my Maker is prepared for the great ordeal of meeting me is another matter. You can't wait for inspiration. You have to go after it with a club. A positive attitude will not solve all your problems, but it will annoy enough people to make it worth the effort. Love is the beauty of the soul. Can miles truly separate you from friends... If you want to be with someone you love, aren't you already there? Glory is fleeting, but obscurity is forever. Human history becomes more and more a race between education and catastrophe. If everything seems under control, you're just not going fast enough. What do you take me for, an idiot? Black holes are where God divided by zero. Friends are as companions on a journey, who ought to aid each other to persevere in the road to a happier life. The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth. If you want to make an apple pie from scratch, you must first create the universe. Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. Thank you for sending me a copy of your book - I'll waste no time reading it. When I am working on a problem I never think about beauty. I only think about how to solve the problem. No dictator, no invader, can hold an imprisoned population by force of arms forever. There is no greater power in the universe than the need for freedom. Against that power, governments and tyrants and armies cannot stand. I would have made a good Pope. God is a comedian playing to an audience too afraid to laugh. What lies behind us and what lies before us, are only small matters compared to what lies within us. Be nice to people on your way up because you meet them on your way down. Success usually comes to those who are too busy to be looking for it He who has a 'why' to live, can bear with almost any 'how'. It has become appallingly obvious that our technology has exceeded our humanity. Touch is the most fundamental sense. A baby experiences it, all over, before he is born and long after he learns to use sight, hearing, or taste, and no human ever ceases to need it. Keep your children short on pocket money - but long on hugs. First they ignore you, then they laugh at you, then they fight you, then you win. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. Basically, I no longer work for anything but the sensation I have while working. Abstainer: a weak person who yields to the temptation of denying himself a pleasure. We have art to save ourselves from the truth. We all agree that your theory is crazy, but is it crazy enough? It's not that chocolates are a substitute for love. Love is a substitute for chocolate. Chocolate is, let's face it, far more reliable than a man. When we drink, we get drunk. When we get drun k, we fall asleep. When we fall asleep, we commit no sin. When we commit no sin, we go to heaven. So, let's all get drunk and go to heaven! If you find a path with no obstacles, it probably doesn't lead anywhere. A doctor can bury his mistakes but an architect can only advise his clients to plant vines. The optimist proclaims that we live in the best of all possible worlds, and the pessimist fears this is true. The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'. Not all chemicals are bad. Without chemicals such as hydrogen and oxygen, for example, there would be no way to make water, a vital ingredient in beer. Life's challenges are not supposed to paralyze you, they're supposed to help you discover who you are. Too often we give our children answers to remember rather than problems to solve. When you gaze long into the abyss, the abyss also gazes into you. Black holes are where God divided by zero. Reduce the complexity of life by eliminating the needless wants of life, and the labors of life reduce themselves. The full use of your powers along lines of excellence. We all agree that your theory is crazy, but is it crazy enough? If you want to make an apple pie from scratch, you must first create the universe. Without question, the greatest invention in the history of mankind is beer. Oh, I grant you that the wheel was also a fine invention, but the wheel does not go nearly as well with pizza. The Babylon project was our last, best hope for peace. .. It failed. .. But in the year of the Shadow war it became something greater: our last, best hope .. for victory. The year is 2260, the place: Babylon 5.When love is not madness, it is not love. A doctor can bury his mistakes but an architect can only advise his clients to plant vines. A clever man commits no minor blunders. Reality is an illusion that occurs due to lack of alcohol. It is unbecoming for young men to utter maxims. Time is never wasted when you're wasted all the time. He who has a 'why' to live, can bear with almost any 'how'. No matter what looms ahead, if you can eat today, enjoy today, mix good cheer with friends today enjoy it and bless God for it. Make everything as simple as possible, but not simpler. When ideas fail, words come in very handy. I think 'Hail to the Chief' has a nice ring to it. Three o'clock is always too late or too early for anything you want to do. Education is a progressive discovery of our own ignorance. Try not to become a man of success but rather to become a man of value. Not everything that can be counted counts, and not everything that counts can be counted.Sleep is an excellent way of listening to an opera. Beer is proof that God loves us and wants us to be happy. When a friend is in trouble, don't annoy him by asking if there is anything you can do. Think up something appropriate and do it. Friends are as companions on a journey, who ought to aid each other to persevere in the road to a happier life. I find that the harder I work, the more luck I seem to have. Thank you for sending me a copy of your book - I'll waste no time reading it. You can't wait for inspiration. You have to go after it with a club. Basically, I no longer work for anything but the sensation I have while working. A narcissist is someone better looking than you are. When I read about the evils of drinking, I gave up reading. If a man does his best, what else is there? Fill what's empty, empty what's full, and scratch where it itches. A little inaccuracy sometimes saves a ton of explanation. In the end, everything is a gag. The secret of success is to know something nobody else knows. I discovered I always have choices and sometimes it's only a choice of attitude. The mistakes are all waiting to be made. A witty saying proves nothing. Luck is the residue of design. Love is the immortal flow of energy that nourishes, extends and preserves. Its eternal goal is life. Be nice to people on your way up because you meet them on your way down. Whenever I climb I am followed by a dog called 'Ego'. If you haven't got anything nice to say about anybody, come sit next to me. Egotist: a person more interested in himself than in me. The game of life is not so much in holding a good hand as playing a poor hand well. I do not consider it an insult, but rather a compliment to be called an agnostic. I do not pretend to know where many ignorant men are sure -- that is all that agnosticism means. Do, or do not. There is no 'try'. This book fills a much-needed gap. First they ignore you, then they laugh at you, then they fight you, then you win. If you can't get rid of the skeleton in your closet, you'd best teach it to dance.I don't know why we are here, but I'm pretty sure that it is not in order to enjoy ourselves. Facts are the enemy of truth. A woman knows the face of the man she loves as a sailor knows the open sea. There are people in the world so hungry, that God cannot appear to them except in the form of bread. A woman drove me to drink and I didn't even have the decency to thank her. It is much more comfortable to be mad and know it, than to be sane and have one's doubts. Thank you for sending me a copy of your book - I'll waste no time reading it. If you ever reach total enlightenment while drinking beer, I bet it makes beer shoot out your nose. All are lunatics, but he who can analyze his delusion is called a philosopher. He is one of those people who would be enormously improved by death. When you have to kill a man, it costs nothing to be polite. No matter what looms ahead, if you can eat today, enjoy today, mix good cheer with friends today enjoy it and bless God for it. It's kind of fun to do the impossible. Love takes off masks that we fear we cannot live without and know we cannot live within. God is a comedian playing to an audience too afraid to laugh. Sleep is an excellent way of listening to an opera. First they ignore you, then they laugh at you, then they fight you, then you win. The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands in times of challenge and controversy. Glory is fleeting, but obscurity is forever. 24 hours in a day, 24 beers in a case. Coincidence? Treat everyone with politeness, even those who are rude to you. Not because they are nice, but because you are. A witty saying proves nothing. Life is pleasant. Death is peaceful. It's the transition that's troublesome. Always remember that I have taken more out of alcohol than alcohol has taken out of me. In any contest between power and patience, bet on patience. When I read about the evils of drinking, I gave up reading. I feel sorry for people who don't drink. When they wake up in the morning, that's as good as they're going to feel all day. Your living is determined not so much by what life brings to you as by the attitude you bring to life; not so much by what happens to you as by the way your mind looks at what happens. The power of accurate observation is frequently called cynicism by those who don't have it. In the End, we will remember not the words of our enemies, but the silence of our friends. A kiss makes the heart young again and wipes out the years. The only difference between me and a madman is that I'm not mad. Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. His ignorance is encyclopedic Compassion alone stands apart from the continuous traffic between good and evil proceeding within us. Love takes off masks that we fear we cannot live without and know we cannot live within. Glory is fleeting, but obscurity is forever. In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in poetry, it's the exact opposite. The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. The ultimate measure of a man is not where he stands in moments of comfort and convenience, but where he stands in times of challenge and controversy. We have art to save ourselves from the truth. We didn't lose th e game; we just ran out of time. The significant problems we face cannot be solved at the same level of thinking we were at when we created them. To love oneself is the beginning of a lifelong romance
------=_NextPart_000_00FJ_01C540DB.2D898590-- ------=_NextPart_000_0009_01C540DB.2D898590 Content-Type: image/gif; name="ybvwput.gif" Content-Transfer-Encoding: base64 Content-ID: <001d01c540ca$6a00b590$0301a8c0@ybvwput> Content-Transfer-Encoding: base64 R0lGODlhJgKaAaIAAEZJp7mhw/8AAAAAZv///wAAAAAAAAAAACH5BAAAAAAALAAAAAAmApoBAAP/ SLrc/jDKSau9OOvNu/9gKI5kaZ5oqq5s675wLM90bd94ru987//AoHBILBqPyKSSEQAMnoNAQAJ9 MqFTRwBLcFa/VklAQBZkG+Oy+pwma90Y6ffMqGqhEbAeQNg+6QpcCl56eBB+T3wNcwuFVWeOUg5Q ikyEAwCAaI9XjoaID01VmXeJk39ol6QShJqIlQpynKUDD4KhlKdRjZ67gb2QhZKbYSCIYLCdtwS5 DoSDvbURampv1GRZbWUN2BiXjAyEyaAQ0Zh9y7++XdERx+vos8zAvJENXsnf8oujyp6xhha8G0Xn mC46+tLxK1ZP2oKEqJTZiogrYL1gnjDaUyeM/5jDDxAphvsCi9xCRSEtorm2jQHLbgS2paEDx0I0 WOAAMlzoiQ8iTbdS7vQH753GjhyRqoMl1BUYNuZ0fhz4VGC/OhSp2nG37CfWnhIPcm12saHSaEf1 FFTJ4ZXAZ7rgSgXkld25DNX6lKFZ0wFMmDHNXBAHNeiXsBQU1v16Bp+Gd0zBmRz7MR5Dx9ASNSZr FZNCqRV9HaskypRUkbcobRbpzCJnwp2zKvx8Gp6gyYfY0vI4lXYc07F3L+NstxJmDC0V5FXelxuc 5M3FEOdodh3uCF6csp637viFVwwTpR46sbJljJWmA1i1UJZ50Lszw5OfDQzjsiPv5jYt13Iy6v/w tUeZaxTppksFbC123QZuVZBdcYgt9RBwFrTBRHLa7OWSYIFlARgFiymThT7BIbhdiOqs9h+IWETk x2IGLvTAcZgtSNl5oeUoYXmKDJRegb5J90eIKM4V4H37XcUdRia+d2Br+tmoATKaxDaFgrdM5l0F FgoE3UtnyNRNGt5QeFJSpkl5z4mzUbQlly3eld1485WniVzNvMkKf2YeWWKR8FGVRZYkDWNTIv1B WE6auvkmaIr4UbGdWGuGRx6DhbBX4pJfGUdhU9O0pI2HL3EYWF4fJtZnPShpxoWaSBKlFKhJitJq JnQ68pWOiuqZh4u6LUgOoJbN1cwyEK246D7/3CnbrJ+Q1noskP9UZ189vM7j7AYQAUIoQyYhS88h pXKooV4YLhfdBNOxKqEdsE5Yp1Y50ZqjF/FMcVsvpAUb0LT6sWjpvP6iIqVXoHiVDr0WXALUqjsW 6SgeCgMLVm3IbBohxB649611H1+pkr0PlCtGciVz2EaV7i7b6jmvJPorwWjJu1GOL+acayG7xtcr x1BGFjC0xeKoIzl20FZauzM2ynEzC04cRtLU6mrtYdj6zM62xpBFL4W5bOkriHt1Se66sTxHDcuK 2rmjODFWql2dhg0NJyqITk1tk00XkyfQPClF9LC0wUW4eJNaEqS8K469L3lSSwPe3qo6KSOU/x85 wTYGCh0XVXDpjB2HqGR6iXaHzE2BcqV1Gu35tZXP/XB3gOuoSrTcNXkncDXGLWvGEW7KNNSC6DPi qotn1vhnMG4X+fE5+a6O7kGPtPlgffZes1Qyi352mKKei64AZ6ctWOmh/WfQjpZJn5nslLb9nSG3 czp95bSg1/IVCH2u8aatwFx9BvY4uiWuUitqkD9iZaQkfYVOfMOfR9ZyvQqpxmbQe89W5JO92vkl fIDJy8ogAJOZoGtPH6NdwGDHLjY5z00e9MhpBmWx1gVvfcqzGXsu0UARBa+Bo3nLBidjlIYU5lLV 65tsxAUcHGariEajzPVw40QTtIN9PqzN7v/GlTKWXOgl5TPflU6HJuBh8R0Nc6EBVZgRBwLIftxx xI/auD+7bMRGnBGWRb62xMo4LDaCQ6GzbsIbtQjJj/IgZBlJcrV9EGtKd6SN17DGupt98BqXpEao +KI6MnIwJznMDxIFNMH4CcWGJnndOhQZxz0gsJLRg1h/9LgTemnqOo6UI/bsJsqq0MKMbnxgWszI Sn6VUgRLw0T/kNgfcSjRktZIlemkaTrnrIFLo1nRdDY4gQcdM1anZJkfPKUfb7bSlYvk5XSSeUul fSxbQrzgN3sYC6NUMD9c89h6xACZCqKoeRc7JzEzFZp7LqEG0hzhQRfK0IY69KEQjahEJ0r/0Ypa 9KIYzahGN8rRjnr0oyANqUhHStKSmvSkKE2pSlfK0pa69KUwjalMZ0rTmtr0pjjNqU53ytOepsAJ a0pGwILYS3myAwL62CEiheoTXyR1mcCsZP/ocpctZFAeCYHK8ag6Dtg4iEr862WVXgFVgtiMkXZk ZEic5dWzcgadbv0bMDX3C6pSlWk+fYxtwCWarAKSkkB95iys2jOAiOyq8tCKsuC6BVvUB7HFQwph 7TIJOhCUAt2yyjBLwlirte8qik0rWgv5qcsKFIaGFC1ZAqutTRwRlHnFlFZpx4tVlGZCgHBCq5Ba mRehY7abMSw0iLHVNJKGruzgqnCT2wlo/6xFck6l0BY8xR7fdrO3wDrecVcZpYggd0KtYtt3ubK5 cQrRU60ZVD7Kabmjrqm4z9JsbfMT2w90lxnoZW5QAWKL3TbtDoq4L3uXy1qr9Ki9a5rEge1KYPPQ tcDO/S00vjvZ6QIYs+axsITdW4fwnoK/CgZxbuC0ufFGmMPyxW96h4udDEdXvRR+8R0MWt//DoIP +wyEf1tzYvCymMch5vA+c6ziDUNYxz2+rng1uOAku9fEgZ0sUMOzY24xucFLDgVu96vfpvnThki+ MIr7gFy7afjII0lFdBuBq36pt8YmmOwuGrthXrqXYT9OMJDlLLLlSvk9UQ6kvJrwS8nI2P/ASdbw n9HR5CJzAM2BXg2hF5FPz2plgL5MMS5YFthksbm/nwyIp08Ms6rO2c5w9sCpD4sOgCiLsAmJDG9t zAxWE5bORga0NDJ7iD+GmniQ9a5k18xcDQfsGxi28WRj4WtH83auSOG1pmc8a9WuUJsvg12srRdm ut56r3hNNRVw7JBzsNbOkXa1noG8bnOXm9wphjR0aXwP5C7bz9EtVFyrS+yjyllo0pP3cp1R5krX Zxxgvndu2KbwTwt5aOqsMrt12+4DN5XVZuGauP9L5H3S1sYF1nCe0/zh4XacDyA73kRGDkmWF/nP S2Z4v/1QZDSPmdZYGfjKbx6LPIuc5xP/IvG4cVFlijv8ChJf99a47ejp/rscGt+4a1NOu901esJB x/nArUp1rbK8wmBG+p7nA3aVt1g6Zp+waHhpc5KHVcI/Z7GJ7wwPo2940ywqcZ2QC+Hv2o3v7e17 1cOsdvhSWuoZ8AylK6MZeW2Z6TYXPOMhrPh4I9Ihc18UZz0s9lzHnLwjp5Ey45ls+i5XuvppIuBz e2gv511I281vZ46OdZdnffY/Hup4dmh3xH+V8UNL5h5dnG1OSDsz/OBssEHGs0Lvy7FYbrHM064T yza/y0UlFKZzQpV+iRnPeJ52aJR0c6N71tpycnD639yJ15Lf9yxa71jfP/cHG/KpYn58/4P1HdcY 1c/JitZvWudaLNd7ZGZUd5d97VRWyyMuuzMFIfFrtRR2Z8V6rgdXEph0zFVwK+YPmgJ/IJhRHxiC JFiCJjhpJpiCKriCLNiCLviCMBiDMjiDNFiDNpgChnKDOriDPNiDPviDQBiEQjiERFiERniESJiE SriETNiETviEUBiFUjiFVFiFVniFWJiFOjAGWrhT4rMhZmA2YGgqoZAhmlAubLMcg9GAo8cb9CYD yZSDtbcJB6ZrTmJd0RSG0XRPozKG1/CGXbgDargAYrIumkRCpcIXJpOH9GaAAgVw4WYDx2cXThEM mjcR4uRFfuhJYMQcYBKISyCGYjQ+ef9IPl1UKpv4h5nkSfgUVNDTGQMEiCxgTqUBVd93KXg4hyuB DWYAGCZkQmdjil/4RaYIikowjCBUjITIi2RoPn2hDcvYjIN4KsM4fvIHeUWBajTgiPmiQwQYDy3G WZYjJqcSjeaIiCqzOtEoi8aIA2rYJaJYjupYjWOgiGfYHDMRj8QVdxPIeQ5nYdoTfI6ReReQOHan OSIhcqMEHAdEjh/EBtR0KuCjjKbDju14A2IIjKJoQl+oj10ECIPYEuqYCuqGaJ03FGEwXYUyWj5C gdKxLcUAVPiSYjQ3FhCojStDkegCkc1YkaN4SRd5UOKTLs2RjF9kUOWSKiIZkfnHaMT/8AslZ17+ oRPzFUUaQJB1FWF2F4AIpls16Q5rs4s8mYlq05PAGJRJAI++iDJmw5YfoonUyBJ0UUIjSXSdl3Pz cAoikzkrdGriaJFYqV/ell28UDkumSGmcpZnWYo9WY5oqQRdIj4ZGUKUSYZwmYhdBIYWtHlPmZf8 IDKR0T9OFphKtidpV5NcKTBRNz7noph1yZoJ9ZqPKQQa4pZ9kZQ+GY3q8hfqiJjXFH93WZIoCV3K x21Q1jqQgXfS12MUB3YI5mQTkCE/uZPB6IkgyZSzGQT5+CFm45vL4ZFfYiqD6J2yaZIlaZLDeZ7Y Z3+sN3/vp54l12U68yNfRW9cqCGu/9mYjumJ1pSdkIlJxKibn2idmUmgzqiImBmdEIdd/giVTjlt nTYfpNlCnDZg+eGc9Tk6qUOd09mf66iZ/pkEADpN5xigzqiM0GignliM8TiNTTkPU5Vophaa3PZz uahXCQRDrMcoz4l96KgXJ8SfQlqgQ8qhIXoEfWiii/mhK4qKKsqaT+qMwIl0r1h9VvqgOldmVWVO j6Z6ImFizZOh0bkX5EOUY5SYdFmWKIqdR+oDKWqi1UiNxKiKTDpNnaSTUfqiAlVWTXRsdecQlwYC kyhvpmZa0HmKITmiEimgqxOnbRoE9FiIeEqKTGCGl3SPzDipHmmeYvVLnAmh1tEKE//KJf/HdJ+J McQxqqw5VsO4mEkKhhb5qBc5ShbFhbJ6q3Dop6spUbaKq77qAoL2q8JaX6U6rMZ6rMiarMq6rMza rM76rNAardI6rdmpn9QKlr8ZCmG5i5+YlD3pohwZm+VphnMJJmTJit/oD67gTEKwHgioi+Y5dzfK C2mYrdNkrfdaXmxqheTJmB2JhnEpl9FUoNV4iNrqpE0Kl9aErrAIS7rHQjwQWp2Abfo3EsvjLAJ7 r9iZsXsYlACrsXQKm2HprVXSqkv5rfYKstsqsooqoAZFJBYTDHW4qy8wTkckSsp1qDf6lZfai7dZ ltgqjNSUsl2oUHKqmzxZE5tqohL/gIy82YwzMZLZ+qYmGx1Ri67Nhn0B+Kk8MClbSRwiR5C52JCC EYZpmg0RSZQ6+aqgKIpqe4pSSjas6LY14bRlarVSayhLup/mWJ5bIwox2mGjSZzFcSVv0gpxlwHc mJXJZSbstWTUha2qg6kgCpQl6rIeiw312phqia5LW6dn+a/no5T7uqhMO4p7ew+G55l4eZwwNgcs 9A2Lm0af91t4GLZhZzC0SqY6iTJ16btvubLGKJfXybnJGLIkSgFDWZkFMSaNyrDkmSq/6LcVm54+ OpgRQTxrl280G592uYHd5Snl9QcHlLCWW6SVa7o76aha6J3pa01nyrHJO6Z1+7OW/1m/97um2+qt 58u+74WXWHGTK3a7l+ELX6qNqvKSp5d64ntdHqSwwKupJyuebuC/7YuYlwu/LCuuk3qpRqq++amM tvmb/WoNSUu7AEyv12vAvVGczoaleoVg62eluFtBMSSyl/uaCRqu+GqMChWnndvBp9u03fC8FIyw fIuYpGIuBbuIGGZ9Jee64Mipg4lwi0VJ/KDAd9ecj4th3bu/9nsymUoqSxyrStibIMSqcPC5cSu3 d0uRy5ug6nuU0zmNSXlP42W9UsyzNuqXQaYLBnJAqxfANfx6yHGnRUq9BBqeZpyE42mUmdTGYizE 8Eu66YibksykkvmO/PvEpuqgJv/mNy1co/3YMahGmLDYxdf1xW+cyAzrmHfsw5tcmWj6tm58AS1r ulJrv7V8tsQ4kURqmp+8tZ3Hx7q3urN7KFVykBK6Wod5mEXcSWh7yWQ5zUIrx4EYyyfKsWxMqVxC tPi5y72coHZrivpowVobs1VpK1RJxdsLPd1bCvzGV7PTwKtcAWQqBZXpyuZ8siyDzlaIzRtMht3c zUjrwak7mUi8pCOU0H57nKP1WZYSnMu2bR8gsRWrE+SUWjoXtPaqxJUrvxqMluQajBz8za98tBrs qFXbxCg7xuh4PfL6nksjjsE5XoSBwGv4rgnoYxL4p6upz5Fqt3O6OQB9rU2YuBr/1cNInaxL1MjH SMlNjawWPdVWvVE1DdVXvdVc3dVe/dVgHdZiPdZkXdZmfdZondYpxdRqnQPsG71mizaSmrCqSJ4M 56JopwXsGgSqYHXfC6NQsh+by8FSPT5yuKptjRxMCdd36grOq6bdqs0LW9gN+ztAMGqDRm0Oegra hEryK9KTHbzCm9hEbK2M7c0fGpmxDNd4OtpSlHwa7QP4oCKilH+TcqOzm8/Au8ShMrpK68+krbyL LZstusZoHB0tbcLUm7V9HM8rwLMB7I1vB9hNY9NhFNclmrr7CYy2HNy9fdecyJ1purbHTbn9+dDK hNPzkZLuVqh/pxlKjT3iFJNR/5CQqddeDJlw0Xy+Dv3bQJvB3j3SB0vJYtjd81unmTy9PbwK6t2e jLaS5IcMLikpkrJVxhwMMrcLyZyT5o3a86vaIly6bf3WH4vaBp7JAy29j03Z69nMe1mHhQpe8NwB 8X1i9tcvP6J3uPKcLVvg69KdJwurAR7THg3Bvozixe3EJXrU6j3ABYwTLHyqbYGT6Xely0arceRP cOnjk3ou1wTibD3iw43NID7EHj7QB3vCYjq4oPnJVcxlmLItMId8WFq+8bCrmsjlvU2nAj3keXrg 1emqx927T/vSnejJGf3moAqAyBnRnNqB38XFGI7ouPzlJ76wScy7Ya7WJI6uZf8j3ngb6hNJ6H3u eonuxxWr6I9eG1cszCg2n4VJ6RYQ17zdoROgwyLO6WNe2Bhs5kmetPqr5MuZ0eztwhEWd6rKW/ON edlY35NemocMy/79srjO4rpu2tRrqb5e3r8M4Hw77PBZ7G4OXUtlyq2jo6yT47JO5GXLxCwakeij kePt54ha15LdpAPLrR48hig+x8oO290Iw/cGeAxu5xjmp36aP7EO7bfOi0Kdm2a6ot4M4lr91avd yfea79sOteFsvKwIpnrgzoF7Ws5NWmZSf/l9fYfqr81rsN782chL74walqfd7fp+80K+sEYr4P/O G1ybgJKnTBP+e433vx14Wjv/oarSmYdiKRA7n/Ey34PJHlGbHvVRSMA9SlFVb/VQ6Fdc//WC2lZg P/ZkX/Zmf/Zon/Zqv/Zs3/YeW/FujwLanpuYrvHBDJt8SNNi76bioD6XUgyJO6/w6vREy7Ym7QpP H/cDrqjxaPhnnr5ILFh9xCxbeHxSmcXwSeedWe/56/L+OqdHvfaY/MHmi/NEOvqlkA3MHLk+UPQH yHwGtOq/gHA2pNv428/6SfGprchqn60kvDpXS95kxMh22vMqzLqbvQPc+LVsAfh2lou5XbZCXevo W6eQ7O+Kf+b1SPf8mdy9ncGhX2xDo6Wu4/r0UeN3M+zTZYDOz1bObznhis9y/828RmrQaK/dQzzX Zh7S4Y8ApEszGkZgJALlgNtBb7l4m3ZR5hmCqAUNlzMtzsKiBImpqMAHQmxT8AS73mI4QdKGwabz CY1Kp9Sq9YrNarfKpu/H+MaYYXKRCBkigdGahl1x5VSiGC5Oz2DfwVn8EvEgI/gXFNghF6RmpGhG IXbE9IVGoLZ1iZmpucnZ6VnlaDPJ0AW5xNNIWbHYBcUXB1ej16JzB8NwZ3Vr4+eW2EBYI/rxxKr6 2IqMukqmNHn8GS09TV1tLRW6wii0zKw6apMd8LzdlPtKk7ibE6ZO2FKi+37S+7vrV2i+7sV6smho bBk5S9cKGjyIMCGVZNq6Df9UAwTcGYDZTuSC9cgdBXyFhMFDIWJfCjgbBQkLxO6jl19QFsUiSPGH KW/jKiq8iTOnzkwzRW0LCFOiv2UMK3VbcTFfuhj7OLLwiCEehZDzRg4r4REHPqgnuDYB4+gZya/l yhzdiTat2rUmhKaJSObhvzRnKcTNZpMWSaivmr57ylFpFZQgVUCFsZXlCsVOwDqEia3sqbFsK1u+ bA3iKTDMYvTkxtmtXYFBIU8VOahkagZOE6G7wXhKUgUe0knFk/h219jKkhD5mXc0pbhfInHGjDy5 8k1AHxOt640uUNCbjVEmXDheLr/tsO7yoJtKhogeIjIWYduJVxNIZDIyTYr/9PPjzoIvv48/f1eg cMGIju5NQNQZZwwvHxzo2YHrcJcebQryJtuDOgg2SDASsrSeMi4R2M+ARnUoHXz6jUjiiOS8hEpR oE0gVzNnnUjZHA+SNwIbgbUmlQgAZDgFIhno5hV2gczYHRQ1tdLicEeJ1ZZmJT4JZZRSWsPjlEfE aGWWWm7JZTXrHNKlP1iGSWaZZp5ZmILhoclmm26+qaWPLowJZ5123olnnnruyWeffv4JaKCCDkpo oYYeimiiii7KaKOOPgpppJJOSmmlllrpw6WaNgnRdS6R1BwRSUIXhlhs/OekcKmcaqp6Ou71AZ0J ySkBSbPlgx1rvNXWUA8o/0o2lH32bSolf+xNF990o0KTLCv9MTuXquFsIxeWQ36Qo5prUcXBaRO2 AERgerWFWohhFeiTs2cwSyymzQmHLGgCLjutsQCaVVFwpTQX4yywGbYLmGiVRwPBKYhbQ664iHsr TT8Ah8Z/K96LL7vtFmvGJECkyuTEjQGr4bMR49WDZPoyojGBi912x2tVFnSrwP8qFkGCVaWQ7Zof rrJzBT5sTCozxoEq4sUYHyNRUTCpeOxx9YI6jnRN95zsqh5L3YZr3ybCAni00Oz1a+J9i/NI+wgj bjoAk20czx9b3PSvQRv9ZMq9TnS11WTBjfVkH8JxcmhMZ12CuPVQteOB8f9cmwHbRkIITAr/tmNz ELyKHTLffxsZykB0bzlQ1MlS1sW7cfMzd98DuhU40BtS0VdV9XA9Ai2DeFeuK47nYAcIuSSctq6J 62xujHajXld7qX9OYkCuk/5evKOjTqdQSZ/VerPRPoG27CDketEtHskM++6w9c5iwDoEr3buFQO7 fbrliCEx81Ae6STTpUs/NPLqnUufcmRPQ0Uj1zsM9z2WvEYDDoID5qLwQKvARm0qUZhF3EdAkNXv dNTZoP2ONjKnTW9zbxuTBykWqqo9LSbVY5CuVAKuhU1AbA+kylhqZrk8AAEHOMTDE9jXq6B9Rn50 Ud0HSySa+kDHboMbYSr//ucc6Q1QHCCjoGqumJUJ8YGGbGPcDSGHD3Qcons/vBlASMgpzbXNFCc8 YnKSaITjqSxvK9wb1DxjhlAFEG77E2EBYRMesR2Ocgtr4GlkZSDKnGMe5VlbGXuEBg0Oa40pdGOJ UrW0NYToecWoYnU+eS8qdmOKSBqcvw5ZJMEsMIFSIR8VgrQOLs7CgvQwo6oyVZzO+C1YmwkQuixp okrKS0D9K2En7QWOIZKwkq0QpgkahgebJaiVWlTBLA12Ba9BAJvny8iCbPlCKD6sZymTiCn6eMNJ AhMzLWraL+l4BkRWq5dobNYwO1RK5y3mQgfDVoMMKbmvIUgL3BIJA585/8sL3QaI2gPg60j4EE8t b53IwZ8kU+VEvXGvVb2UGDiYWZYT5ZCf7cOQSdkgxjpEsEchCSTb1CehhYKTgHvBqC4h0LH9TJSi PPUTQ7OUqZ4KdahZJF6c1DjUpBpNQohUqlOfqp+WQnWqVK2qVa+K1axqdatc7apXvwrWsIp1rGQt COSWE66ZsmmlZW3rRoyaHHuoFU09dKtdUXDWisp1T2y9a1vzipy96qmufnWqnHY0kjqEwWu8kYM2 tVnSxc2pdilZyj7n5KBuzQA8DqRsA2fxKkPUSAYsCwZnbTMko6YWZ0OKxWnb4dnIQXab3SKtKwu7 ViLNLFa0HUFjbSjVzP8eSKCUXWWaeHutcTSOGBViLiBv8SAbcAt9rMGdP3Fz3QsO9w+KK6m/Ckra 7hLXHorF7ZswC1CDtYx2jWUvYglzEvEl1JqSdWkeTCLX975ikSX43S8eaIHKYSSGAkNE+tj7xe9t EbSz8wwf4mtNzCKiv7WIMFzNm1sKm6dwf2lvWnfouAdzZL8WGstBJSjXDUflNAClEF7n0cMwCsJl cgAf28Q4A4/4gcZrip2KDyOIn2LYTDt6rA4As9A1cWTEExoHAAiWxQQxxYyBQfJqCHyhGR4ZW/2K KUC19iBAKPClN57Qjr1Mgw4YTDE5JqmQh8wlxjH4rQMmLV6lwuR+Inf/zOESc3igYuXKdiTL3SzY QE1AaIz0sKA15nMtv2ijGaO5oEwp7W63+2Y4A3U8O/LFj9msZDy/Q8RzuoCIswVi5VKmyuqIR2vS p7MTTwU9iJ7pDGR8HUfX2sRmlnSuS11oNj+AsFfUNJsIu14VR+6fdL5yN18jX1QvhX2BObWzZWFL tqIGg2/4r+OifMFIFzolEYR2hIuUoUwbW0rCMHKz7xCIUIfTQQD1EaxluDAICYxX2Hm1gxDrw3H7 92YFxvGXYtloaRuwd2IWdzTL9gp75wArsauvoNdtpklv2dXY+u28uynnaONbbViaboUmgKPm1lbW wDg0QsVbIW9uF9za/2Wuub07OwVNGeYhn/LIsdNXjLOzDoTBcbbk4HFnR3wEw1Pl1tSa2lPpwd/9 BPi4hWv13dR2YUAqr9ON51nCOsXruHmyLIosksOm9ee4FnpSX6ZUwLrdriy/qtznPtbVbvXueBfr KbPK974LfvCEJ7zoCo/4xCt+8YxvvOMfD/nIS37ylK/8Vptq+cwP/clZj0bnZeNAzpvdEIj9/E46 MEPMP1P1uGC95gGF+m1eeAumh6BrC6az2F8G9bq3Qu1d5frX96n3FSi9g1kkeuSPXvT9Tf4NWsZ5 3Fud+aFfbAiiT5vUd6BgtMH+8zm/Q9eO/vvjXyz4s38D8T9Z9qV3Pv/52W/q86df+I/aPkgcXHw7 AEK/FJ9h+9H/fN2XfwMYe+W3TVOBfAJYgE6mf8UngAGoe/ZXMMjnfxSIgN3HgMQXgBD4XgWoXwq4 fk72gOZDf4Syfve3TbcXASh4ggvogAd4gg5odd8SgwJYCww4fyeIWDe4gSv4gtcHhDG4Oy6YdRK4 fT44fxiAcuGnezUIgCW4KNN3foYBcE5WY62kZr5zfPNnAZz3AMzHQNN3e62nZk82J/anYA5YhiSQ eiHQhq3HfRL4eU5mdkdYhHgmgk/YaaJ3hlUofxoIhYcigUG4heBnh9c3Di44gB84a4gWfo1Ihp2n iBIQgp8nhTewehP/KISht4dLOIg/mH4SeIOAeIc6GHyBeCcaaHwpKIf754YpmIRomD5toRt+OIas KImr+H0WeIHs90yL44pP+IOHSHxGuIevmH8aCIgNsISouCi9t3zNh4NqFgdA+HxvqIg6uH8N6IHV J3sPSIQOph39l4QYSIsWuIkbgXy1oovWWIkTeI09qIstOHvOGChlWCvXd37JN2zAWGovsIXUSH7i GINryIny92/61YzFlzMA12RrUob4J4wMWWTal4vYN4gGmZC8OJATaY8f2RX1CJIjqSW/R5InGSdO iJIryZIt6ZIvCZMxKZNhcoqiMJOSV4w5InqWY5KyEWsiyT25B5Q3/1lYBsZ9K8aQ0qWSndCTr5R7 c0WUGFaG7uiNj1Bk0kePO8l+DUh9FEl+RTZ+EQl/fraH47eUUbluqOeHE/mJ6JeVSUmNsYdDRPhe vtN85liJFhiXjKiQoIiWQsd7H4iE8LhYCTiAyQiM5bh+i6kdhqmNB2iMP/iOqjiUf9lWHsiBFjGG TciEwNh729eOdgmA9qeWfChmr2h/WumXlmlsuseOh5kOv8h8w3iMMEgeARiDfCmRoNl1QGiEauZ/ rOl2EYh9nZeLt0mctKmYpvaGzLiBaymDvamAVfGOwolx0PiW5ogLrVSWILiNBPh/uWmYdOAdh1md mcmZ1jl3xFeD7v/Xi0FohhSHkO4XmsoXixQHfy2AjHWolW2pnq+njJX5nwNqBcoIlQSKoHtwiwnK oA3qoA8KoREqoTxVkxPqjP7JlOqHkEepoBZKeGfJCcdJmDzRlB46ZP6plQBHj91XkPt4EexJh2Yn n35YfvRZoSY6Vir5mI+phncpl/1lKyhFhz7jo/2ol3fpnDiKd20phna4ik1qnK5lHod5iNvJfTp6 o0oKVk44iIuZiMfYhWbof2JolV2ZnIP5lVcYliWqpX71idCYep1omG0RYOUIi5lYjZ9Ye1Npp21q bFxKpsAZj0mKgt8CiGeadSCqhITqp61Zi0gqkLnZf6TZjshYmAf/yIE4iJv42ajr6QIpOp9IupGj mpQjyqGUuqbeZ6Odyqqt6qqvCquxKquzSqu1aqu36qa4qnlOaHUaCYmwiaF5uYFVAIYCylJZqqtR WIPkqX+3KJDDKl03mqjG2gZsmqyVMp9ziqkcepXot4Y2KKP7p5pdyRqnMo4tipHJx6ffCpvX+jlm RwhaiKfI+IUU+KPMuYj2+aPaaamLiKSV+J1PMY8c6a50w5huGaSNSIyPmqmZKYC2+J7PGS55iJi8 +H/WV7DM05cgQDa5yIX4mn3Rp6JtiIQ7+IhcF5/bmn7tSbEjS5FbmLEGK42VuqjW15j8N6TCep5e 2q9JGJajRrGB/3mnvRp9yxizlyKpjMih23muD4ib6DinPFuzlpqe2WeMLduA1me0R4utwKiiX2ti 6IqpIgukDuuwBminPAqwIDi0b6ioXGspRXhkqnmOcEiRVwm2dbmfbxCl5seiNLqiAMh/9IiscFtW W2u4Mhm4iWuZvsq4jwu5kSu5k0u561S4lXsmvEoeG6qPs+kE1rocLou5g+J9TQixVkmsl7sTfTm6 gpKtfkmZFpF88leWBDm4BumrYvmynQt/Mcq7d9t8jqW6rZsl/Xmxdru0iPh9A4hZwtqw8Wi64Cm9 zxmwV+iY4vqArEu8f3KxNAutXxmN2yqvbNlwTqu1d2iucUgII/8Lp8nps8O7vVKSl4qIsdaIutWI sMhohcEIivvLojv0s9RHqXYQo2wYvUlIgvELJ4R7vD1reos7vqFoiPwrhPyZZuilXLVZv3mbsC8o ugrMJ0mrre36vZhasgvJjK2onJJZi6GHpi/ImQGatQoGvyBcIkQLtneKvFb6g3YZnPfKwrC4l/ba l495wm5JjtAJuja8Vjq5uWibkDtJmus7pkk7wdzalfQZqqM3wIL7qRYrn33KxGNMxmVsxmeMxmms xmvMxm5arOBrK39mnNR6BW8KhgR7E0vcxjlxqF7LtHuhx51gx8gZyIJcyHs8K5bIna2nkrG7u49M rrr7fmNplUL/Wppeq43hCn5/6H4RCadijMiW0ce9WKWXirEhaKT+CrXTa4qlusO127DUWIfxGL4H nJfQmcChfHpgaL7UO7U6zLY8HJ0yoKnE7IYqbMp5Cp1WKqng2JtvahJlq8sVNYcsQ8C93JZHyEim KZla1ml3+4/Ju4Zc/LU4NZVyuJvBMGH4C4faO82irMgXOM7oq7DW/IvGLHvFvK2DrJmQyZ/xp7/4 6cn8G4Q9+85rMcrwyLLJ7M8oJZ19KqO3CKiAzJXj2M0m3I++eZGuVsMHrQnx/I12zNC+HJgVTczp Sbgc2MJ126MsOqzQqc3f+LxQ7NGVQYqRfBufycuoCric+rGq//rFnZvT1azR4drDWeuBzifJXdrR NX24dOzUGHfIUZ2Wb0vVV43VWa3VW80JTX0fXs3V03DHLB2UmGfVEYuVgyGjtOiTHinEUB3WH00e 0tpUfOoKcZy1UvB7GBqtwMfOcY0TWhR/a92id4ty5EzT14jJVuyxdmu8oApswLuVfzu4P03OvQzY CZGoPyy0VlvO6bmMnRjSfNm3suud2euY9vmxFYgRrZzDSpvZCkG0wZmvfw2CtL2aqSmRTwvMoKyY mqrbLf2wiSmeL2ioon3WsS0NJEC7hQjQ+ZmD3EzK+PWKPFiuIcnMCTKdysl8wmvMrUykyzfCym0Q D7yb+AqcIv+ImaLA3Jf9sCfbs4kItO77gYWto43pwWOq3g1M3uVtYjD7qdsqrHwNijsLsozql1Ir wdr9sUHMpBMrsRHIjuPd39ZgelSof+VZqqyruYWpwt14z9nroxbd4Cptns9d4qK9lxWOE+Yd0ADs fIhtqNSpXAHNud0X4L9L36dJ2bJHBxAuy8pXkfvK4kVu5EeO5Emu5EvO5E3u5I9rgDQ71p4wz4N9 44qa2OX9nU/OlAvd2K68CS9MqOyZ2ILKx1vO5Zqglo84x6e8yectxXSrsv3K1Ge51pQs2R0Jqu5Y urOJuGnuewfOsQsa3UTKjfz3vhnRz4RZyghInP83xNdI2zv/O+kB67yAfgmU+optzsz4PczDzd7t PZHljOAe7OmlzJuWKq+ojuKXjula0MU5SOi6GL1E+8jtQA/mes0lDNOmFbTByNSb+gezS8ivjgnd XbacvukwC5oA/LvJO+pCvqETJqYFHrRfSI7eit4rfdvGDut/UTgorLKKWOskLs43M63me4dWKuHK Ges/Td2/6ureTqz2LOV+vJxwieikDu3l+KPpS+fde2/rTb0ZzufgCdf0DtH4OsfuObePXbRybttR vMx3+sJlmeO5q5M1SOapGvFgrfAZusuEHvJ8le1nztYlz703rhABqvIvD/MxL/Mz/+TzbA4oHubc +cbsretZ/2DzWTDVMt+lxBP0QYmCT7CsNzr0WZDLNI/ddqu7BxuotOui6Op96ih9gPyv6Yp/kpzg BAnjM3rgTi8FaNrK4SiPJNt+UaO2qo2nc1nNeWjEVZjKUqewNEzSIVjqZO8qqGvfAK3pf7/PGmzn u17Cu6iHLYvm4nzgCi7abs33pOf33Dyw0e2FIBumFjzn+3mbpl3gmE/QjO/v3fre+Bz5RsIyOA/q io3b1pjNiZnrwNpjDO7Zh/70iDjb802mp/848rzSgLv5p4vFR3+Jnv/bZ0pwjNScjl/MTc/7S3/i wq6d5X7wJr7o/370vsyFV3j7ae+vwcz7TumF5rpfy4/DP/+OlbY7+50bI+1Zul8c+vAn2DXK9QYd /veP//mv//vP/whAutz+MMpJq7046827/2AojmRpNkFwrmzrvnAsz3Rt33iu73zv/8CgcEgsGo/I pHLJbDqf0Kh0Sq1ar9isdsvter/gsHhMLpvP6LR6zW673/C4fE6v2+/4vH7P7/v/gIGCg4Q1KQOI AwAqKIgRAY4LkImUlRABAImLD5AAEJmKjBOHmqKNnpeRCqCViSkXKaybDpOPqiiTiLO0raUUtakD DLm9iZLFuqYKxMgTuhGZqLSsA68N0ZzPvMIKiMqFLpjF0su3KJnDyJTbvcqdD74U1JS7x+Tn3Kvq 3hXMlO7/5oahczAvXrp93w4+GlhuXz5/re5BbOWM3wNsjcZlzBaQwLtu1cDFmFSPpMJgJy1E2yUu pD18HdmZagnwXkoCmRK2/KWIJaiZMT2ayzXz5ylOGFEqbWgBGEFtTDusuwjgHiifUEF+i+aSQVKL Il305CjK6babo8B6VZTOalYJSa+p/chxbUKPcS+yfUrO7Ma1NvV1FRpY6OC/dY/lS7sYsWEP9PT2 Vcsga04H3vZW7ko5rAlQth4GNetXQucFYOm2LMyLNU7NhEPbhQYbXuPNZUffoiu5LbSqspc+7heU QOriFHR1rkrudENReTvxHq7Vc4vL0KyVlsSQelrXi3JL/7t6wTnqrtMFLsaezbXxwwvYb1/W3Xz1 cqzzolW/Xzhm9MhVtJNc0qR3DXD0NXYZe7Gdd5d1IMzn300SEojBO6vBEqB8td3EoIVwdTihYiRO wGF+8JWYWFQ83aZYbi6WV404ViH42oMsvmfKgoMxaB+EHRgY3IremZaiLYuQp6F7DTZ5VnxHvude LuFJIKFTQvqGXzAPXrlbgDkeuFiFyYU0yY6a/agjlDDS19xgagKpgX5WOvQlQg5eqJwxF9B51JbC fdgQk4bRo5Od+fippZPciaiYQwep0+Y0WU30j4CCeWUjmOwlRdcttcUpJwbM6WlnpMiIImpDlRC6 io1Ivv90SXcFtYojTJGhqk58sKZS4D5TIqprO4/2Ep1Dt4IF1VcxylUWQ526NN2qo1agKJGOkYla PS2yZZS1ji6apVm16uLqNLL0x+K1gBYa0a1FUgimu+8+ycFxLpUKErimhKKPlh9SW+13pi405rzU nnlelIvG2q69Nx50bogANiuOrHX+OrFj+KgLMY2HNluBWtGowCy8JJsJ20cBCTzwkJdMSqS2+kwp XqTEMempbusdZpI8Ue5ssSpZQqlxkDx7zPFr8NEcAWXP6BtxnY1hGGpIHbr88icMa+PlwSI3bO90 P5vI8JphNixo2Q63pyLEgjZw3MYekzbvdt++rQFlZ+7/7J7UW36YU3pab93akF8rLXfQmqWnZMYh 3uNcXHHnPWK7iWPcm+YZZJ72iGzHi8Fy5r6JY2eZ3dZJVd8UbvjigZV9ZXdOG5ZQ3gZazjW3gilD pzho3sVn5GTpzR9gt88VbosGK278oM4b+Q0xk6UYes29dgPa6ywQJQnbnotOm78JDmag91SbrztI 5r8Vt2HBKr9y0pEWxffyjMHstIQlPy9jyL26yrPe8qjAVAV/3PtASyKytLdZ6lJrUUQrahIMQpXr SAts1VMetD5cabBuHbng9BAIs2zZiRFf+xWypMe1DkHkWsOTS4pcl0D1mGuEQwMbnnBhKLe1kFCk SMYvgqjBu6khBUwZ5F34hkG9uxQtf8J5oCs+pxhUSNE+zlndrDShs5go7D/wqqEYx0jGMprxjGh8 A3PWyMY2uvGNcIyjHOdIxzra8Y54zKMe98jHPvrxj4AMpCDtmMZCGvKQiEykIhfJyEY68pGQjKQk J0nJSlrykpjMpCY3yclOenJUCQAAOw== ------=_NextPart_000_0009_01C540DB.2D898590-- From simple-bounces@ietf.org Thu Apr 14 17:08:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28341; Thu, 14 Apr 2005 17:08:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMBjb-00036E-Ji; Thu, 14 Apr 2005 17:18:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAwl-000562-Qe; Thu, 14 Apr 2005 16:28:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMAwj-00054d-6O for simple@megatron.ietf.org; Thu, 14 Apr 2005 16:28:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22561 for ; Thu, 14 Apr 2005 16:28:06 -0400 (EDT) Received: from atlas.jabber.org ([208.245.212.69] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMB6d-0000gS-EP for simple@ietf.org; Thu, 14 Apr 2005 16:38:32 -0400 Received: by atlas.jabber.org (Postfix, from userid 1005) id 15B1D21A514; Thu, 14 Apr 2005 15:29:29 -0500 (CDT) Date: Thu, 14 Apr 2005 15:29:29 -0500 From: Peter Saint-Andre To: xmppwg@jabber.org, simple@ietf.org Message-ID: <20050414202929.GH24647@jabber.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Subject: [Simple] FW: I-D ACTION:draft-saintandre-xmpp-simple-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable FYI. ----- Forwarded message from Internet-Drafts@ietf.org ----- To: i-d-announce@ietf.org =46rom: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-saintandre-xmpp-simple-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Basic Messaging and Presence Interoperability=20 between the Extensible Messaging and Presence=20 Protocol (XMPP) and Session Initiation Protocol=20 (SIP) Extensions for Instant Messaging and Presence (SIMPLE) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-xmpp-simple-02.txt Pages : 25 Date : 2005-4-14 =09 This document defines a bi-directional protocol mapping for use by gateways that enable the exchange of instant messages and presence information between systems that implement the Extensible Messaging and Presence Protocol (XMPP) and those that implement the basic extensions to the Session Initiation Protocol (SIP) for instant messaging and presence. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-xmpp-simple-02.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of the = message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-saintandre-xmpp-simple-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-saintandre-xmpp-simple-02.txt". =09 NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ----- End forwarded message ----- _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From kien_cousins@gemcity.com Fri Apr 15 05:06:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09860; Fri, 15 Apr 2005 05:06:37 -0400 (EDT) Message-Id: <200504150906.FAA09860@ietf.org> Received: from 66-141-72-132.ded.swbell.net ([66.141.72.132]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMMwl-0004kx-IJ; Fri, 15 Apr 2005 05:17:10 -0400 Received: from mail.gryphinracing.com (66.141.72.132) by 66.141.72.132 (chenchev.5) with SMTP id <59755s20f> (Authid: 883); Fri, 15 Apr 2005 13:04:02 +0300 Reply-To: "arona bower" From: "arona bower" To: scoya@ietf.org Cc: sctp-impl-archive@ietf.org, seamoby@ietf.org, seamoby-admin@ietf.org, seamoby-archive@ietf.org, seamoby-request@ietf.org, seamoby-web-archive@ietf.org, secdir@ietf.org, secdir-admin@ietf.org, secdir-web-archive@ietf.org, secretariat@ietf.org, secretary@ietf.org, sg@ietf.org, sic@ietf.org, sigtran@ietf.org, sigtran-admin@ietf.org, simple@ietf.org, simple-admin@ietf.org, simple-archive@ietf.org Subject: Responding back to your email.. Date: Fri, 15 Apr 2005 04:06:02 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2182718_2026925.4N660" X-Spam-Score: 16.7 (++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 93238566e09e6e262849b4f805833007 ----2182718_2026925.4N660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7Bit Dear Homeowner,

You have been pre-approved for $400,000 with a low fixed rate.

This offer is being extended to you unconditionally and your credit is in no way a factor.

Take Advantage of this Limited Time opportunity. Just answer only a few questions at
our site and we can give you an approval in under 30 seconds - it’s that simple!

http://www.refi-gazette.com/s5/jwex.php?l4d=63

Regards,

arona bower

-------------
r-m-v yourself - http://www.refi-gazette.com/r1/ ----2182718_2026925.4N660-- From YFTSANFHUBML@earthlink.net Fri Apr 15 11:44:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14830; Fri, 15 Apr 2005 11:44:15 -0400 (EDT) Received: from [216.155.91.5] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMT6V-0002kl-MM; Fri, 15 Apr 2005 11:51:42 -0400 Message-ID: <2865401773236.36ajj87tl@northstate.net> Received: from 194.104.150.177 by rynny7-jib53.qh1.northstate.net with DAV; Fri, 15 Apr 2005 18:36:00 +0200 Reply-To: "Charlie Doherty" From: "Charlie Doherty" To: Subject: Posses whatever drag you want fennel Date: Fri, 15 Apr 2005 15:30:00 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--kzyxkzz859110digj" X-Spam-Score: 9.0 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 ----kzyxkzz859110digj Content-Type: text/plain; Content-Transfer-Encoding: 7Bit neew, improoved drags on our website! just try us, you wont be dissappointed... for sure :) main page: http://sourdough.jaqo.com/p/erika/aura.htm also: lose wieght fast and easy? Maridia is the ultimate solution: http://sourdough.jaqo.com/p/erika/6/diffeomorphic.htm you wont stop scrrewing with viaggra, enjoy!: http://sourdough.jaqo.com/p/erika/20/icosahedral.htm wanna get rid of smoking? Zybban is the simple and elegant answer: http://sourdough.jaqo.com/p/erika/28/breakdown.htm loosing hair? stop it now! look good again with Propesia, recomended! : http://sourdough.jaqo.com/p/erika/12/infield.htm also: men's haelth mucsle relexers pajn reliev ho is that stalking over the hotel lobby! it is nan hands clutching a meaty axe! and with a low bellow her voice cometh. n bsp and run in the gentle rain. falstaff do so for it is worth the listening to these nine in buckram that i told thee of--. autumn rose briggs- autumn your encouraging spirit means so much to me you never but always understand! your friendship is more than cherished!! they were among the innumerable heroes who spent weeks and months looking for remains - only to develop life-threatening cancer. lighting with fast and free shipping at discount prices kitchen islandand pool table lighting lighting kitchen remodel. i won t be around very much this weekend and wanted to wish you all a great holiday keep up the workouts. it was fun to discover such a wealth of missions information through you web page we spent three months this summer at galmi hospital in niger a great experience that we would like to repeat!! this is news? no really thank goodness someone spent a kazillion dollars on a study to figure out that i am truly addicted to chocolate my favorite quote of the entire article was this one. hi! i m rozie s older sister just started up my own journal looking for other christian girls around here love your journal! - compress link pages to save disk space you can compress or decompress the links pages online. moreover when ye fast be not as the hypocrites of a sad countenance for they disfigure their faces that they may appear unto men to fast verily i say unto you they have their reward. that is a excelent home page i d like to help missionaries who want to came to brazil if you have anybody please contact me. we h ave these huge casement windows in our family room and there is this robin that has been trying diligently i might add to breach the glass since last thursday morning. ----kzyxkzz859110digj-- From fyzbumu@turkuamk.fi Sat Apr 16 01:57:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04008; Sat, 16 Apr 2005 01:57:16 -0400 (EDT) Received: from [221.159.58.107] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DMgTG-0002iy-8n; Sat, 16 Apr 2005 02:08:00 -0400 Received: from 221.159.58.107 by mail.adherer.net; Fri, 15 Apr 2005 23:00:41 -0800 Message-ID: <003001c540ca$d4d816b0$0301a8c0@trwcpuwy> From: "Joaquin Wilson" Reply-To: "Joaquin Wilson" To: ips-admin@ietf.org, ietf-rsvp@ietf.org, sipping@ietf.org, midcom@ietf.org, pilc-admin@ietf.org, mipshop-web-archive@ietf.org, pim@ietf.org, l2tpext@ietf.org, simple-archive@ietf.org, iporpr@ietf.org Subject: Available now: Weight loss/diet pill meds etc... - democrat Date: Fri, 15 Apr 2005 23:00:41 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--01C540DB.2D898590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.224 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.224 X-Spam-Score: 11.0 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 52e1467c2184c31006318542db5614d5 ----01C540DB.2D898590 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable
What are Soft Tabs that everyone is talking about?
A Soft Tab is an oral lozenge, mint in flavor, containing pure
Tadalafil Citrate that is placed under your tongue and dissolved.

This is most modern and safe way not to cover with shame!

Interested?

dont need it...
----01C540DB.2D898590-- From simple-bounces@ietf.org Wed Apr 20 03:07:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9JL-0002yU-Ot; Wed, 20 Apr 2005 03:07:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DO9JH-0002yO-4Y for simple@megatron.ietf.org; Wed, 20 Apr 2005 03:07:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09233 for ; Wed, 20 Apr 2005 03:07:42 -0400 (EDT) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DO9UR-00087L-IO for simple@ietf.org; Wed, 20 Apr 2005 03:19:16 -0400 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j3K75rdr026090; Wed, 20 Apr 2005 09:05:54 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j3K75mDm009167; Wed, 20 Apr 2005 09:05:48 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Apr 2005 09:05:48 +0200 Message-ID: From: Boehmer Bernhard Com Berlin To: "'Paul Kyzivat'" , "Hyttfors, Per" , "'hgs@cs.columbia.edu'" Subject: Re: Re: [Simple] reachibility information for services in current presence data model Date: Wed, 20 Apr 2005 09:05:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, wasn't able to join the thread for a while... I cannot follow the view that the described use case is poor. For me it's quite plausible that a user wants to select a subset of his/her devices being available for a specific service. So, if I'm in=20 a meeting I would like to make clear to the world that my device I'm carrying in the meeting is available for IM but not for voice. So, one way to do that would be to publish the tuple for IM indicating "open" and the tuple for voice (what ever this means in IETF SIMPLE terms) = indicating "closed". The PS then may have to handle voice tuples from different = sources=20 all indicating "open" or "closed" for this service. For IM the same. = But=20 merging all voice tuples with "open" by using an AOR obviously isn't = possible. This means that all voice tuples with value "open" have to be = concatenated in=20 the raw presence doc and hence in some of the notified ones. This is = certainly possible but for mobile networks there are already quite heavy = discussions on the resulting traffic in terms of number of messages and of number of = bytes. So, a more effective way to combine this information would be helpful. = Using=20 compression helps a bit but a too generous handling of data redundancy = may outweight the effects of compression. Regards Bernhard > -----Urspr=FCngliche Nachricht----- > Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 > Im Auftrag von Paul Kyzivat > Gesendet: Donnerstag, 7. April 2005 16:58 > An: Hyttfors, Per > Cc: simple@ietf.org > Betreff: Re: AW: [Simple] reachibility information for=20 > services in current presence data model >=20 >=20 > The *point* of publishing multiple tuples in presence is because you=20 > want the watcher to make the choice. And for the watcher to do so you = > must give him some basis on which to make that choice. But if all the = > tuples are identical except for the contact, then there is no=20 > basis for=20 > the choice. >=20 > In this case I think it is preferable to publish a single=20 > tuple with a=20 > single contact, where requests sent to that contact try any or all of = > the actual services based on presentity logic. Often that can be=20 > achieved simply by merging the tuples into one with the AoR=20 > as the contact. >=20 > You *may* of course publish all those tuples that differ only in=20 > contact, and leave the decision up to the watcher. But then you must=20 > accept that you have no control over which gets tried. As a=20 > result, your=20 > watchers may be annoyed with you. >=20 > I'm not seeing much value in adding a second way to represent=20 > a poor use=20 > case. I think you would be better off figuring out what=20 > criteria would=20 > allow the watchers to make an informed choice, and publishing that so = > the tuples *aren't* identical. >=20 > Paul >=20 > Hyttfors, Per wrote: > > I hope that several devices running the same service for=20 > the same person > > will publish the same service URI representing an=20 > address-of-record with > > all the individual service addresses for each device. > >=20 > > But the conversation between Boehmer Bernhard and Henning=20 > Schulzrinne > > made me think and realize that maybe there is a use case where you > > actually would have a person with several devices running the same > > service publishing different service addresses. Hence, it=20 > would maybe be > > beneficial from a watcher's standpoint for the presence=20 > server (running > > some sort of composition policy) to be able to express=20 > several service > > addresses for the same service and maybe to express which device = has > > which service address without needing to duplicate the whole = service > > tuple. But I won't fight over this since it sounds like=20 > people don't see > > this as a likely problem. > >=20 > > /Per > >=20 > >=20 > > -----Original Message----- > > From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 > > Sent: onsdag den 6 april 2005 19:02 > > To: Hyttfors, Per > > Cc: simple@ietf.org; Paul Kyzivat > > Subject: Re: AW: [Simple] reachibility information for services in > > current presence data model > >=20 > >=20 > > Are you asking for multiple elements per tuple? > >=20 > > Hisham > >=20 > > On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: > >=20 > >=20 > >>The problem I see is that the current presence data model doesn't=20 > >>allow for such "service composition policy" without having=20 > to define a > >=20 > >=20 > >>new format that can describe one service reachable through serveral = > >>published addresses. > >> > >>/Per > >> > >>-----Original Message----- > >>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>Sent: onsdag den 6 april 2005 16:32 > >>To: Hyttfors, Per > >>Cc: simple@ietf.org > >>Subject: Re: AW: [Simple] reachibility information for services in=20 > >>current presence data model > >> > >>Hyttfors, Per wrote: > >> > >>>Hello, > >>> > >>>Lets say that the same person would have several devices with the=20 > >>>same > >> > >>>service running on all of them (lets say a telephone service) but=20 > >>>with > >> > >>>different service contact addresses (telephone numbers).=20 > Each device=20 > >>>will have its own Presence User Agent that publish its part of the = > >>>presence information. Would this scenario require that the NOTIFY=20 > >>>that > >> > >>>is sent to a watcher with the overall presence information of that = > >>>person would have to contain several with=20 > different contact=20 > >>>addresses but with the same duplicated service=20 > information? (in the=20 > >>>case that the service is the exact same one for all devices) > >> > >>This is a function of how the multiple sources of presence=20 > information > >=20 > >=20 > >>are composed by the presence server. Simply making a union=20 > of all the=20 > >>tuples (which is what you ask about) is one simple=20 > approach, because=20 > >>it requires no understanding on the part of the part of the=20 > presence=20 > >>server. But it is clear that people would like to have more=20 > >>intelligent composition policies. So far we have deferred actually=20 > >>defining such intelligent composition policies just because=20 > it is hard > >=20 > >=20 > >>and we want to get something out. But it is entirely permissible to = > >>implement such a compostion policy even in the absence of a=20 > standard. > >> > >> Paul > >> > >> > >>>/Per > >>> > >>> > >>>Henning Schulzrinne wrote: > >>> > >>> > >>>>Unless there is some significant difference between services, you = > >>>>wouldn't publish multiple contact addresses for it. Thus > >>>> > >>>> > >>>> ... description ... > >>>> sip:foo@somewhere > >>>> sip:bar@example > >>>> sip:123@whoknows > >>>> > >>>> > >>>>makes very little sense - why publish three URIs that the = observer > >>>>has > >>>>no way of distinguishing? If there's no annotation, the user can > >>> > > only > >=20 > >>>>throw darts and pick one. > >>>> > >>>>With the possible exception of having both a "tel" and=20 > SIP URI that=20 > >>>>reach the same device, I see little practical use for your > >>> > >>description, > >> > >>> > >>>>but maybe I'm misunderstanding your use case. > >>>> > >>>>Boehmer Bernhard Com Berlin wrote: > >>>> > >>>> > >>>>>Hi Henning, > >>>>>my assumption is that a user has a certain service available at=20 > >>>>>different locations (devices, agents, etc.) each identified by=20 > >>>>>different contact addresses. The user wants to publish all these = > >>>>>contact addresses for this service. Together with the contact=20 > >>>>>information, however, (s)he also publishes also a bunch of other = > >>>>>information about this service. Due to the fact that only one=20 > >>>>>contact > >>>> > >>>>>is possible in , my current understanding is that the = user > >>>>>has > >>>> > >>>to publish > >>> > >>> > >>>>>multiple tuples indicating the different contacts but=20 > *duplicating* > >>>> > >=20 > >>>>>the other service information. This information,=20 > therefore, seems=20 > >>>>>to be doubled. I would like to avoid this redundancy somehow. > >>>>> > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Per Hyttfors=20 > >>>___________________________________________________________ > >>>Development Engineer - Messaging Application Development Sony=20 > >>>Ericsson Mobile Communications AB SE-221 88 Lund, Sweden > >>>+46 46 2126534 > >>>per.hyttfors@sonyericsson.com=20 > >>>___________________________________________________________ > >>>The information in this email, and attachment(s) thereto,=20 > is strictly > >> > >=20 > >>>confidential and may be legally privileged. It is intended=20 > solely for > >> > >=20 > >>>the named recipient(s), and access to this e-mail, or any > >> > >>attachment(s) > >> > >>>thereto, by anyone else is unauthorized. Violations hereof=20 > may result > >> > >>in > >> > >>>legal actions. Any attachment(s) to this e-mail has been=20 > checked for=20 > >>>viruses, but please rely on your own virus-checker and=20 > procedures. If > >> > >=20 > >>>you contact us by e-mail, we will store your name and address to=20 > >>>facilitate communications in the matter concerned. If you do not > >> > >>consent > >> > >>>to us storing your name and address for above stated=20 > purpose, please=20 > >>>notify the sender promptly. Also, if you are not the intended > >> > >>recipient > >> > >>>please inform the sender by replying to this transmission,=20 > and delete > >> > >=20 > >>>the e-mail, its attachment(s), and any copies of it without, > >> > >>disclosing > >> > >>>it. > >>> > >>>_______________________________________________ > >>>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 >=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-bounces@ietf.org Wed Apr 20 09:36:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFNS-0001CG-0Z; Wed, 20 Apr 2005 09:36:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOFNQ-0001C5-6z for simple@megatron.ietf.org; Wed, 20 Apr 2005 09:36:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08522 for ; Wed, 20 Apr 2005 09:36:22 -0400 (EDT) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOFYe-0002qg-78 for simple@ietf.org; Wed, 20 Apr 2005 09:48:00 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 20 Apr 2005 09:47:17 -0400 X-IronPort-AV: i="3.92,116,1112587200"; d="scan'208"; a="45362060:sNHT32334544" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3KDaCRQ027307; Wed, 20 Apr 2005 09:36:12 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:36:11 -0400 Received: from cisco.com ([161.44.79.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 20 Apr 2005 09:36:11 -0400 Message-ID: <42665ACB.80509@cisco.com> Date: Wed, 20 Apr 2005 09:36:11 -0400 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: Boehmer Bernhard Com Berlin Subject: Re: [Simple] reachibility information for services in current presence data model References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 20 Apr 2005 13:36:11.0577 (UTC) FILETIME=[EA7EE290:01C545AD] X-Spam-Score: 1.0 (+) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA08522 Cc: simple@ietf.org, "Hyttfors, Per" , "'hgs@cs.columbia.edu'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Boehmer Bernhard Com Berlin wrote: > Hi, > wasn't able to join the thread for a while... > I cannot follow the view that the described use case is poor. > For me it's quite plausible that a user wants to select a subset of > his/her devices being available for a specific service. So, if I'm in=20 > a meeting I would like to make clear to the world that my device I'm > carrying in the meeting is available for IM but not for voice. So, one > way to do that would be to publish the tuple for IM indicating "open" > and the tuple for voice (what ever this means in IETF SIMPLE terms) ind= icating > "closed". There is your problem. You are immediately faced with having multiple=20 tuples with the same contact address. And semantically its complicated to= o. A better way to do this is to have each device publish a single tuple=20 describing the capabilities it has available. So your portable device=20 sometimes indicates it is available for both voice and IM, but when in a=20 meeting it changes this to indicate it is still available, but only for I= M. > The PS then may have to handle voice tuples from different sources=20 > all indicating "open" or "closed" for this service. For IM the same. Bu= t=20 > merging all voice tuples with "open" by using an AOR obviously isn't po= ssible. You shouldn't be merging them unless you want the watcher to perceive=20 them as one thing, which includes having one address. If there are=20 multiple addresses then it isn't one thing. > This means that all voice tuples with value "open" have to be concatena= ted in=20 > the raw presence doc and hence in some of the notified ones. This is ce= rtainly > possible but for mobile networks there are already quite heavy discussi= ons on the > resulting traffic in terms of number of messages and of number of bytes. > So, a more effective way to combine this information would be helpful. = Using=20 > compression helps a bit but a too generous handling of data redundancy = may outweight > the effects of compression. I don't agree with screwing up the semantics in the name of providing a=20 questionable form of compression. Simple partial notification will probably resolve most of the problem in=20 this case, and sigcomp can help a lot too. Paul > Regards Bernhard >=20 >=20 >=20 >>-----Urspr=FCngliche Nachricht----- >>Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 >>Im Auftrag von Paul Kyzivat >>Gesendet: Donnerstag, 7. April 2005 16:58 >>An: Hyttfors, Per >>Cc: simple@ietf.org >>Betreff: Re: AW: [Simple] reachibility information for=20 >>services in current presence data model >> >> >>The *point* of publishing multiple tuples in presence is because you=20 >>want the watcher to make the choice. And for the watcher to do so you=20 >>must give him some basis on which to make that choice. But if all the=20 >>tuples are identical except for the contact, then there is no=20 >>basis for=20 >>the choice. >> >>In this case I think it is preferable to publish a single=20 >>tuple with a=20 >>single contact, where requests sent to that contact try any or all of=20 >>the actual services based on presentity logic. Often that can be=20 >>achieved simply by merging the tuples into one with the AoR=20 >>as the contact. >> >>You *may* of course publish all those tuples that differ only in=20 >>contact, and leave the decision up to the watcher. But then you must=20 >>accept that you have no control over which gets tried. As a=20 >>result, your=20 >>watchers may be annoyed with you. >> >>I'm not seeing much value in adding a second way to represent=20 >>a poor use=20 >>case. I think you would be better off figuring out what=20 >>criteria would=20 >>allow the watchers to make an informed choice, and publishing that so=20 >>the tuples *aren't* identical. >> >> Paul >> >>Hyttfors, Per wrote: >> >>>I hope that several devices running the same service for=20 >> >>the same person >> >>>will publish the same service URI representing an=20 >> >>address-of-record with >> >>>all the individual service addresses for each device. >>> >>>But the conversation between Boehmer Bernhard and Henning=20 >> >>Schulzrinne >> >>>made me think and realize that maybe there is a use case where you >>>actually would have a person with several devices running the same >>>service publishing different service addresses. Hence, it=20 >> >>would maybe be >> >>>beneficial from a watcher's standpoint for the presence=20 >> >>server (running >> >>>some sort of composition policy) to be able to express=20 >> >>several service >> >>>addresses for the same service and maybe to express which device has >>>which service address without needing to duplicate the whole service >>>tuple. But I won't fight over this since it sounds like=20 >> >>people don't see >> >>>this as a likely problem. >>> >>>/Per >>> >>> >>>-----Original Message----- >>>From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 >>>Sent: onsdag den 6 april 2005 19:02 >>>To: Hyttfors, Per >>>Cc: simple@ietf.org; Paul Kyzivat >>>Subject: Re: AW: [Simple] reachibility information for services in >>>current presence data model >>> >>> >>>Are you asking for multiple elements per tuple? >>> >>>Hisham >>> >>>On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: >>> >>> >>> >>>>The problem I see is that the current presence data model doesn't=20 >>>>allow for such "service composition policy" without having=20 >>> >>to define a >> >>> >>>>new format that can describe one service reachable through serveral=20 >>>>published addresses. >>>> >>>>/Per >>>> >>>>-----Original Message----- >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>>Sent: onsdag den 6 april 2005 16:32 >>>>To: Hyttfors, Per >>>>Cc: simple@ietf.org >>>>Subject: Re: AW: [Simple] reachibility information for services in=20 >>>>current presence data model >>>> >>>>Hyttfors, Per wrote: >>>> >>>> >>>>>Hello, >>>>> >>>>>Lets say that the same person would have several devices with the=20 >>>>>same >>>> >>>>>service running on all of them (lets say a telephone service) but=20 >>>>>with >>>> >>>>>different service contact addresses (telephone numbers).=20 >>>> >>Each device=20 >> >>>>>will have its own Presence User Agent that publish its part of the=20 >>>>>presence information. Would this scenario require that the NOTIFY=20 >>>>>that >>>> >>>>>is sent to a watcher with the overall presence information of that=20 >>>>>person would have to contain several with=20 >>>> >>different contact=20 >> >>>>>addresses but with the same duplicated service=20 >>>> >>information? (in the=20 >> >>>>>case that the service is the exact same one for all devices) >>>> >>>>This is a function of how the multiple sources of presence=20 >>> >>information >> >>> >>>>are composed by the presence server. Simply making a union=20 >>> >>of all the=20 >> >>>>tuples (which is what you ask about) is one simple=20 >>> >>approach, because=20 >> >>>>it requires no understanding on the part of the part of the=20 >>> >>presence=20 >> >>>>server. But it is clear that people would like to have more=20 >>>>intelligent composition policies. So far we have deferred actually=20 >>>>defining such intelligent composition policies just because=20 >>> >>it is hard >> >>> >>>>and we want to get something out. But it is entirely permissible to=20 >>>>implement such a compostion policy even in the absence of a=20 >>> >>standard. >> >>>> Paul >>>> >>>> >>>> >>>>>/Per >>>>> >>>>> >>>>>Henning Schulzrinne wrote: >>>>> >>>>> >>>>> >>>>>>Unless there is some significant difference between services, you=20 >>>>>>wouldn't publish multiple contact addresses for it. Thus >>>>>> >>>>>> >>>>>> ... description ... >>>>>> sip:foo@somewhere >>>>>> sip:bar@example >>>>>> sip:123@whoknows >>>>>> >>>>>> >>>>>>makes very little sense - why publish three URIs that the observer >>>>>>has >>>>>>no way of distinguishing? If there's no annotation, the user can >>>>> >>>only >>> >>> >>>>>>throw darts and pick one. >>>>>> >>>>>>With the possible exception of having both a "tel" and=20 >>>>> >>SIP URI that=20 >> >>>>>>reach the same device, I see little practical use for your >>>>> >>>>description, >>>> >>>> >>>>>>but maybe I'm misunderstanding your use case. >>>>>> >>>>>>Boehmer Bernhard Com Berlin wrote: >>>>>> >>>>>> >>>>>> >>>>>>>Hi Henning, >>>>>>>my assumption is that a user has a certain service available at=20 >>>>>>>different locations (devices, agents, etc.) each identified by=20 >>>>>>>different contact addresses. The user wants to publish all these=20 >>>>>>>contact addresses for this service. Together with the contact=20 >>>>>>>information, however, (s)he also publishes also a bunch of other=20 >>>>>>>information about this service. Due to the fact that only one=20 >>>>>>>contact >>>>>> >>>>>>>is possible in , my current understanding is that the user >>>>>>>has >>>>>> >>>>>to publish >>>>> >>>>> >>>>> >>>>>>>multiple tuples indicating the different contacts but=20 >>>>>> >>*duplicating* >> >>>>>>>the other service information. This information,=20 >>>>>> >>therefore, seems=20 >> >>>>>>>to be doubled. I would like to avoid this redundancy somehow. >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>Per Hyttfors=20 >>>>>___________________________________________________________ >>>>>Development Engineer - Messaging Application Development Sony=20 >>>>>Ericsson Mobile Communications AB SE-221 88 Lund, Sweden >>>>>+46 46 2126534 >>>>>per.hyttfors@sonyericsson.com=20 >>>>>___________________________________________________________ >>>>>The information in this email, and attachment(s) thereto,=20 >>>> >>is strictly >> >>>>>confidential and may be legally privileged. It is intended=20 >>>> >>solely for >> >>>>>the named recipient(s), and access to this e-mail, or any >>>> >>>>attachment(s) >>>> >>>> >>>>>thereto, by anyone else is unauthorized. Violations hereof=20 >>>> >>may result >> >>>>in >>>> >>>> >>>>>legal actions. Any attachment(s) to this e-mail has been=20 >>>> >>checked for=20 >> >>>>>viruses, but please rely on your own virus-checker and=20 >>>> >>procedures. If >> >>>>>you contact us by e-mail, we will store your name and address to=20 >>>>>facilitate communications in the matter concerned. If you do not >>>> >>>>consent >>>> >>>> >>>>>to us storing your name and address for above stated=20 >>>> >>purpose, please=20 >> >>>>>notify the sender promptly. Also, if you are not the intended >>>> >>>>recipient >>>> >>>> >>>>>please inform the sender by replying to this transmission,=20 >>>> >>and delete >> >>>>>the e-mail, its attachment(s), and any copies of it without, >>>> >>>>disclosing >>>> >>>> >>>>>it. >>>>> >>>>>_______________________________________________ >>>>>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 >> >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 21 04:13:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOWo4-0006ZI-Kz; Thu, 21 Apr 2005 04:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOWnx-0006YR-Py for simple@megatron.ietf.org; Thu, 21 Apr 2005 04:13:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03812 for ; Thu, 21 Apr 2005 04:12:55 -0400 (EDT) Received: from ns2.bln1.siemens.de ([194.138.127.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOWzK-00070e-Pr for simple@ietf.org; Thu, 21 Apr 2005 04:24:43 -0400 Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j3L8Brdr005866; Thu, 21 Apr 2005 10:12:02 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id j3L8BhDm000520; Thu, 21 Apr 2005 10:11:43 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Apr 2005 10:11:43 +0200 Message-ID: From: Boehmer Bernhard Com Berlin To: "'Paul Kyzivat'" , Boehmer Bernhard Com Berlin Subject: AW: [Simple] reachibility information for services in current pr esence data model Date: Thu, 21 Apr 2005 10:11:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org, "Hyttfors, Per" , "'hgs@cs.columbia.edu'" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi Paul, the discussion convinced me that one would mess up the=20 semantics of presence elements by such an approach. Concerning=20 the verbosity of the XML I think sigcomp helps by ~60% and hopefully this will convince mobile operators!=20 Thanks Bernhard > -----Urspr=FCngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Gesendet: Mittwoch, 20. April 2005 15:36 > An: Boehmer Bernhard Com Berlin > Cc: Hyttfors, Per; 'hgs@cs.columbia.edu'; simple@ietf.org > Betreff: Re: [Simple] reachibility information for services=20 > in current presence data model >=20 >=20 >=20 >=20 > Boehmer Bernhard Com Berlin wrote: > > Hi, > > wasn't able to join the thread for a while... > > I cannot follow the view that the described use case is poor. > > For me it's quite plausible that a user wants to select a subset of > > his/her devices being available for a specific service. So,=20 > if I'm in=20 > > a meeting I would like to make clear to the world that my device = I'm > > carrying in the meeting is available for IM but not for=20 > voice. So, one > > way to do that would be to publish the tuple for IM=20 > indicating "open" > > and the tuple for voice (what ever this means in IETF=20 > SIMPLE terms) indicating > > "closed". >=20 > There is your problem. You are immediately faced with having multiple = > tuples with the same contact address. And semantically its=20 > complicated too. >=20 > A better way to do this is to have each device publish a single tuple = > describing the capabilities it has available. So your portable device = > sometimes indicates it is available for both voice and IM,=20 > but when in a=20 > meeting it changes this to indicate it is still available,=20 > but only for IM. >=20 > > The PS then may have to handle voice tuples from different sources=20 > > all indicating "open" or "closed" for this service. For IM=20 > the same. But=20 > > merging all voice tuples with "open" by using an AOR=20 > obviously isn't possible. >=20 > You shouldn't be merging them unless you want the watcher to perceive = > them as one thing, which includes having one address. If there are=20 > multiple addresses then it isn't one thing. >=20 > > This means that all voice tuples with value "open" have to=20 > be concatenated in=20 > > the raw presence doc and hence in some of the notified=20 > ones. This is certainly > > possible but for mobile networks there are already quite=20 > heavy discussions on the > > resulting traffic in terms of number of messages and of=20 > number of bytes. > > So, a more effective way to combine this information would=20 > be helpful. Using=20 > > compression helps a bit but a too generous handling of data=20 > redundancy may outweight > > the effects of compression. >=20 > I don't agree with screwing up the semantics in the name of=20 > providing a=20 > questionable form of compression. >=20 > Simple partial notification will probably resolve most of the=20 > problem in=20 > this case, and sigcomp can help a lot too. >=20 > Paul >=20 > > Regards Bernhard > >=20 > >=20 > >=20 > >>-----Urspr=FCngliche Nachricht----- > >>Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20 > >>Im Auftrag von Paul Kyzivat > >>Gesendet: Donnerstag, 7. April 2005 16:58 > >>An: Hyttfors, Per > >>Cc: simple@ietf.org > >>Betreff: Re: AW: [Simple] reachibility information for=20 > >>services in current presence data model > >> > >> > >>The *point* of publishing multiple tuples in presence is=20 > because you=20 > >>want the watcher to make the choice. And for the watcher to=20 > do so you=20 > >>must give him some basis on which to make that choice. But=20 > if all the=20 > >>tuples are identical except for the contact, then there is no=20 > >>basis for=20 > >>the choice. > >> > >>In this case I think it is preferable to publish a single=20 > >>tuple with a=20 > >>single contact, where requests sent to that contact try any=20 > or all of=20 > >>the actual services based on presentity logic. Often that can be=20 > >>achieved simply by merging the tuples into one with the AoR=20 > >>as the contact. > >> > >>You *may* of course publish all those tuples that differ only in=20 > >>contact, and leave the decision up to the watcher. But then=20 > you must=20 > >>accept that you have no control over which gets tried. As a=20 > >>result, your=20 > >>watchers may be annoyed with you. > >> > >>I'm not seeing much value in adding a second way to represent=20 > >>a poor use=20 > >>case. I think you would be better off figuring out what=20 > >>criteria would=20 > >>allow the watchers to make an informed choice, and=20 > publishing that so=20 > >>the tuples *aren't* identical. > >> > >> Paul > >> > >>Hyttfors, Per wrote: > >> > >>>I hope that several devices running the same service for=20 > >> > >>the same person > >> > >>>will publish the same service URI representing an=20 > >> > >>address-of-record with > >> > >>>all the individual service addresses for each device. > >>> > >>>But the conversation between Boehmer Bernhard and Henning=20 > >> > >>Schulzrinne > >> > >>>made me think and realize that maybe there is a use case where you > >>>actually would have a person with several devices running the same > >>>service publishing different service addresses. Hence, it=20 > >> > >>would maybe be > >> > >>>beneficial from a watcher's standpoint for the presence=20 > >> > >>server (running > >> > >>>some sort of composition policy) to be able to express=20 > >> > >>several service > >> > >>>addresses for the same service and maybe to express which=20 > device has > >>>which service address without needing to duplicate the=20 > whole service > >>>tuple. But I won't fight over this since it sounds like=20 > >> > >>people don't see > >> > >>>this as a likely problem. > >>> > >>>/Per > >>> > >>> > >>>-----Original Message----- > >>>From: Hisham Khartabil [mailto:hisham.khartabil@telio.no]=20 > >>>Sent: onsdag den 6 april 2005 19:02 > >>>To: Hyttfors, Per > >>>Cc: simple@ietf.org; Paul Kyzivat > >>>Subject: Re: AW: [Simple] reachibility information for services in > >>>current presence data model > >>> > >>> > >>>Are you asking for multiple elements per tuple? > >>> > >>>Hisham > >>> > >>>On Apr 6, 2005, at 4:54 PM, Hyttfors, Per wrote: > >>> > >>> > >>> > >>>>The problem I see is that the current presence data model doesn't = > >>>>allow for such "service composition policy" without having=20 > >>> > >>to define a > >> > >>> > >>>>new format that can describe one service reachable=20 > through serveral=20 > >>>>published addresses. > >>>> > >>>>/Per > >>>> > >>>>-----Original Message----- > >>>>From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >>>>Sent: onsdag den 6 april 2005 16:32 > >>>>To: Hyttfors, Per > >>>>Cc: simple@ietf.org > >>>>Subject: Re: AW: [Simple] reachibility information for=20 > services in=20 > >>>>current presence data model > >>>> > >>>>Hyttfors, Per wrote: > >>>> > >>>> > >>>>>Hello, > >>>>> > >>>>>Lets say that the same person would have several devices=20 > with the=20 > >>>>>same > >>>> > >>>>>service running on all of them (lets say a telephone=20 > service) but=20 > >>>>>with > >>>> > >>>>>different service contact addresses (telephone numbers).=20 > >>>> > >>Each device=20 > >> > >>>>>will have its own Presence User Agent that publish its=20 > part of the=20 > >>>>>presence information. Would this scenario require that=20 > the NOTIFY=20 > >>>>>that > >>>> > >>>>>is sent to a watcher with the overall presence=20 > information of that=20 > >>>>>person would have to contain several with=20 > >>>> > >>different contact=20 > >> > >>>>>addresses but with the same duplicated service=20 > >>>> > >>information? (in the=20 > >> > >>>>>case that the service is the exact same one for all devices) > >>>> > >>>>This is a function of how the multiple sources of presence=20 > >>> > >>information > >> > >>> > >>>>are composed by the presence server. Simply making a union=20 > >>> > >>of all the=20 > >> > >>>>tuples (which is what you ask about) is one simple=20 > >>> > >>approach, because=20 > >> > >>>>it requires no understanding on the part of the part of the=20 > >>> > >>presence=20 > >> > >>>>server. But it is clear that people would like to have more=20 > >>>>intelligent composition policies. So far we have deferred=20 > actually=20 > >>>>defining such intelligent composition policies just because=20 > >>> > >>it is hard > >> > >>> > >>>>and we want to get something out. But it is entirely=20 > permissible to=20 > >>>>implement such a compostion policy even in the absence of a=20 > >>> > >>standard. > >> > >>>> Paul > >>>> > >>>> > >>>> > >>>>>/Per > >>>>> > >>>>> > >>>>>Henning Schulzrinne wrote: > >>>>> > >>>>> > >>>>> > >>>>>>Unless there is some significant difference between=20 > services, you=20 > >>>>>>wouldn't publish multiple contact addresses for it. Thus > >>>>>> > >>>>>> > >>>>>> ... description ... > >>>>>> sip:foo@somewhere > >>>>>> sip:bar@example > >>>>>> sip:123@whoknows > >>>>>> > >>>>>> > >>>>>>makes very little sense - why publish three URIs that=20 > the observer > >>>>>>has > >>>>>>no way of distinguishing? If there's no annotation, the user = can > >>>>> > >>>only > >>> > >>> > >>>>>>throw darts and pick one. > >>>>>> > >>>>>>With the possible exception of having both a "tel" and=20 > >>>>> > >>SIP URI that=20 > >> > >>>>>>reach the same device, I see little practical use for your > >>>>> > >>>>description, > >>>> > >>>> > >>>>>>but maybe I'm misunderstanding your use case. > >>>>>> > >>>>>>Boehmer Bernhard Com Berlin wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>>Hi Henning, > >>>>>>>my assumption is that a user has a certain service=20 > available at=20 > >>>>>>>different locations (devices, agents, etc.) each identified by = > >>>>>>>different contact addresses. The user wants to publish=20 > all these=20 > >>>>>>>contact addresses for this service. Together with the contact=20 > >>>>>>>information, however, (s)he also publishes also a=20 > bunch of other=20 > >>>>>>>information about this service. Due to the fact that only one=20 > >>>>>>>contact > >>>>>> > >>>>>>>is possible in , my current understanding is=20 > that the user > >>>>>>>has > >>>>>> > >>>>>to publish > >>>>> > >>>>> > >>>>> > >>>>>>>multiple tuples indicating the different contacts but=20 > >>>>>> > >>*duplicating* > >> > >>>>>>>the other service information. This information,=20 > >>>>>> > >>therefore, seems=20 > >> > >>>>>>>to be doubled. I would like to avoid this redundancy somehow. > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>Per Hyttfors=20 > >>>>>___________________________________________________________ > >>>>>Development Engineer - Messaging Application Development Sony=20 > >>>>>Ericsson Mobile Communications AB SE-221 88 Lund, Sweden > >>>>>+46 46 2126534 > >>>>>per.hyttfors@sonyericsson.com=20 > >>>>>___________________________________________________________ > >>>>>The information in this email, and attachment(s) thereto,=20 > >>>> > >>is strictly > >> > >>>>>confidential and may be legally privileged. It is intended=20 > >>>> > >>solely for > >> > >>>>>the named recipient(s), and access to this e-mail, or any > >>>> > >>>>attachment(s) > >>>> > >>>> > >>>>>thereto, by anyone else is unauthorized. Violations hereof=20 > >>>> > >>may result > >> > >>>>in > >>>> > >>>> > >>>>>legal actions. Any attachment(s) to this e-mail has been=20 > >>>> > >>checked for=20 > >> > >>>>>viruses, but please rely on your own virus-checker and=20 > >>>> > >>procedures. If > >> > >>>>>you contact us by e-mail, we will store your name and address to = > >>>>>facilitate communications in the matter concerned. If you do not > >>>> > >>>>consent > >>>> > >>>> > >>>>>to us storing your name and address for above stated=20 > >>>> > >>purpose, please=20 > >> > >>>>>notify the sender promptly. Also, if you are not the intended > >>>> > >>>>recipient > >>>> > >>>> > >>>>>please inform the sender by replying to this transmission,=20 > >>>> > >>and delete > >> > >>>>>the e-mail, its attachment(s), and any copies of it without, > >>>> > >>>>disclosing > >>>> > >>>> > >>>>>it. > >>>>> > >>>>>_______________________________________________ > >>>>>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 > >> > >=20 > >=20 >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Apr 21 19:29:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOl6k-0005Mo-BH; Thu, 21 Apr 2005 19:29:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOl6j-0005Mh-Ga for simple@megatron.ietf.org; Thu, 21 Apr 2005 19:29:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01447 for ; Thu, 21 Apr 2005 19:29:14 -0400 (EDT) Received: from mail-src.takas.lt ([212.59.31.78] helo=mail.takas.lt) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOlIE-0000k7-Jz for Simple@ietf.org; Thu, 21 Apr 2005 19:41:11 -0400 Received: from company ([85.206.109.191]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Apr 2005 02:29:13 +0300 Message-ID: <000c01c546c9$e9cca180$cebffea9@company> From: "Renatas Vaiciunas" To: Date: Fri, 22 Apr 2005 02:29:07 +0300 Organization: GSA MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 21 Apr 2005 23:29:13.0337 (UTC) FILETIME=[ED4A5690:01C546C9] X-Spam-Score: 1.2 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Subject: [Simple] (no subject) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1221550719==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1221550719== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C546E3.0EF3B3E0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C546E3.0EF3B3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0009_01C546E3.0EF3B3E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 
------=_NextPart_000_0009_01C546E3.0EF3B3E0-- --===============1221550719== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1221550719==-- From simple-bounces@ietf.org Thu Apr 21 19:47:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOlOF-0007uK-Ev; Thu, 21 Apr 2005 19:47:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DOlOD-0007uC-Ms for simple@megatron.ietf.org; Thu, 21 Apr 2005 19:47:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02173 for ; Thu, 21 Apr 2005 19:47:18 -0400 (EDT) Received: from mail-src.takas.lt ([212.59.31.78] helo=mail.takas.lt) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOlZj-00014E-6j for simple@ietf.org; Thu, 21 Apr 2005 19:59:16 -0400 Received: from company ([85.206.109.191]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.6713); Fri, 22 Apr 2005 02:47:18 +0300 Message-ID: <00b401c546cc$706ea7e0$cebffea9@company> From: "Renatas Vaiciunas" To: "HELPDESK OMA" Date: Fri, 22 Apr 2005 02:47:12 +0300 Organization: GSA MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-OriginalArrivalTime: 21 Apr 2005 23:47:18.0328 (UTC) FILETIME=[73FED380:01C546CC] X-Spam-Score: 1.3 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: simple@ietf.org Subject: [Simple] Feedback X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1645732177==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1645732177== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C546E5.958C9280" This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C546E5.958C9280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_00B1_01C546E5.958C9280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_00B1_01C546E5.958C9280-- --===============1645732177== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1645732177==-- From simple-bounces@ietf.org Fri Apr 22 15:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP4Fv-0003b8-Db; Fri, 22 Apr 2005 15:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DP4Fr-0003a7-4Z; Fri, 22 Apr 2005 15:55:59 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18776; Fri, 22 Apr 2005 15:55:57 -0400 (EDT) Message-Id: <200504221955.PAA18776@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 22 Apr 2005 15:55:57 -0400 Cc: simple@ietf.org Subject: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-04.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. Title : Presence Information Data format (PIDF) Extension for Partial Presence Author(s) : M. Lonnfors, et al. Filename : draft-ietf-simple-partial-pidf-format-04.txt Pages : 15 Date : 2005-4-22 The Presence Information Document Format (PIDF) specifies the baseline XML based format for describing presence information. One of the characteristic of the PIDF is that document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type which enables transporting of either only the changed parts or the full PIDF based presence information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-simple-partial-pidf-format-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-4-22162337.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-simple-partial-pidf-format-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-4-22162337.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --NextPart-- From simple-bounces@ietf.org Mon Apr 25 02:19:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPwwN-000238-5p; Mon, 25 Apr 2005 02:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DPwwK-000230-12 for simple@megatron.ietf.org; Mon, 25 Apr 2005 02:19:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13095 for ; Mon, 25 Apr 2005 02:19:26 -0400 (EDT) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DPx8V-0006gx-ON for simple@ietf.org; Mon, 25 Apr 2005 02:32:04 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3P6JO828337 for ; Mon, 25 Apr 2005 09:19:24 +0300 (EET DST) X-Scanned: Mon, 25 Apr 2005 09:39:17 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j3P6dHBA032596 for ; Mon, 25 Apr 2005 09:39:17 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 003w6uSL; Mon, 25 Apr 2005 09:37:51 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j3P6HqU11014 for ; Mon, 25 Apr 2005 09:17:52 +0300 (EET DST) Received: from kusti.research.nokia.com ([172.21.56.13]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 25 Apr 2005 09:17:52 +0300 Received: from [172.21.39.195] (hed039-195.research.nokia.com [172.21.39.195]) by kusti.research.nokia.com (Postfix) with ESMTP id 76CEE93B75 for ; Mon, 25 Apr 2005 09:17:50 +0300 (EEST) Message-ID: <426C8B8E.6010906@nokia.com> Date: Mon, 25 Apr 2005 09:17:50 +0300 From: Jari Urpalainen User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: simple@ietf.org Subject: Re: [Simple] I-D ACTION:draft-ietf-simple-partial-pidf-format-04.txt References: <200504221955.PAA18776@ietf.org> In-Reply-To: <200504221955.PAA18776@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2005 06:17:52.0480 (UTC) FILETIME=[8313E600:01C5495E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org ext Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the SIP for Instant Messaging and Presence Leveraging Extensions Working Group of the IETF. > > Title : Presence Information Data format (PIDF) Extension > for Partial Presence > Author(s) : M. Lonnfors, et al. > Filename : draft-ietf-simple-partial-pidf-format-04.txt > Pages : 15 > Date : 2005-4-22 > >The Presence Information Document Format (PIDF) specifies the > baseline XML based format for describing presence information. One > of the characteristic of the PIDF is that document always needs to > carry all presence information available for the presentity. In some > environments where low bandwidth and high latency links can exist it > is often beneficial to limit the amount of transported information > over the network. This document introduces a new MIME type which > enables transporting of either only the changed parts or the full > PIDF based presence information. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-04.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-simple-partial-pidf-format-04.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-simple-partial-pidf-format-04.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > >------------------------------------------------------------------------ > >_______________________________________________ >Simple mailing list >Simple@ietf.org >https://www1.ietf.org/mailman/listinfo/simple > > Changes from 03 based on discussions: -pidf-diff content-type contains either full PIDF content or patch operation elements from draft-urpalainen-simple-xml-patch-ops-00.txt -document root is thus either or -in addition to PIDF content contains a version attribute information. This is used to "sync" full docs with patches easily. Also resource list servers with eventlist subscriptions could utilize it. -partial-pidf includes patch-ops elements which describes a generic xml patch model Comments ? Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 25 05:37:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ025-0002Cn-Cn; Mon, 25 Apr 2005 05:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQ023-0002CZ-G6 for simple@megatron.ietf.org; Mon, 25 Apr 2005 05:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29440 for ; Mon, 25 Apr 2005 05:37:32 -0400 (EDT) From: Martin.Hynar@tietoenator.com Received: from ebb01.tietoenator.com ([193.12.180.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQ0EF-0007dD-A6 for simple@ietf.org; Mon, 25 Apr 2005 05:50:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Apr 2005 11:37:18 +0200 Message-ID: <3ACC9A25264A684F82C71840111F9798428661@carrera.eu.tieto.com> Thread-Topic: SIP subscribing to documents with resource-lists content Thread-Index: AcVJel+mBGfOx68sRNi0B/CSaCaE/g== To: X-OriginalArrivalTime: 25 Apr 2005 09:37:20.0600 (UTC) FILETIME=[60A21580:01C5497A] X-Spam-Score: 0.5 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Subject: [Simple] SIP subscribing to documents with resource-lists content X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1525437355==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1525437355== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5497A.5FEDEFB1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5497A.5FEDEFB1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 is in some way possible to SIP subscribe to documents that use application/resource-lists+xml MIME type for the content? I need to be informed about changes that are taken on such documents via XCAP protocol. And, I don't know about event-package for such purpose. The only method I know about is to utilize sip-profile package (from draft-ietf-sipping-config-framework-06) with the application/xcap-diff+xml MIME in content. However, this method is "ugly" workaround. =20 Thanks for some delectable response =20 =20 =20 Martin Hynar=20 Senior Developer TietoEnator Czech Software Centre Direct +420 59 732 5901 Fax +420 59 732 5903 E-mail martin.hynar@tietoenator.com =20 Technologicka 372/2 CZ-708 00 Ostrava=20 www.tietoenator.com =20 =20 =20 ------_=_NextPart_001_01C5497A.5FEDEFB1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

is in some way possible to SIP subscribe to documents = that use application/resource-lists+xml MIME type for the content? I need to = be informed about changes that are taken on such documents via XCAP = protocol. And, I don’t know about event-package for such purpose. The only method = I know about is to utilize sip-profile package (from = draft-ietf-sipping-config-framework-06) with the application/xcap-diff+xml MIME in content. However, this method = is “ugly” workaround.

 

Thanks for some delectable = response

 

 

 

Martin = Hynar 

Senior = Developer

= TietoEnator

=

Czech Software = Centre
Direct +420 59 732 5901

Fax +420 59 732 = 5903

=

E-mail martin.hynar@tietoenator.com=

Technologicka = 372/2

=

CZ-708 00 = Ostrava 

www.tietoenator.com=

=

 

 

------_=_NextPart_001_01C5497A.5FEDEFB1-- --===============1525437355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1525437355==-- From simple-bounces@ietf.org Mon Apr 25 21:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQEZA-0007hx-1M; Mon, 25 Apr 2005 21:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQEZ8-0007hi-GP for simple@megatron.ietf.org; Mon, 25 Apr 2005 21:08:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17434 for ; Mon, 25 Apr 2005 21:08:39 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQElT-0002qn-Te for simple@ietf.org; Mon, 25 Apr 2005 21:21:28 -0400 Received: from [192.168.0.39] (services.xten.net [69.28.248.106]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j3Q18Y105943; Mon, 25 Apr 2005 18:08:34 -0700 Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Mon, 25 Apr 2005 18:09:03 -0700 To: "simple@ietf.org WG" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Simple] Free text in presence documents X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hi, I'd like to make some comments on the rather casual sprinkling of free text elements in PIDF and its extensions. In part I would like to clarify and refine my earlier point about the proliferation of note text. 1) It may come as a surprise to some of you that I believe that we need an element which contains a free-text alternative or alternatives to siblings which are members of an explicit enumeration. However, I think the semantics need of such an element need to be really crisp or it loses value. I also think this has very different semantics than the current element in basic PIDF. I will use for this purpose in my example. Whatever we call this element, I feel very strongly that it should have the semantics of its parent. For example, Juggling chainsaws is an activity, which is not specifically included in any standard enumeration.** In other words, my hypothetical element has an "is-a" relationship with its parent element. closed Juggling chainsaws Contrast this with the following example from the RPIDs draft: I got my paycheck! "I got my paycheck" is not a mood; it is a statement. While it's nice that you got paid, that statement doesn't belong here IMO. 2) ** I think we should try to avoid having both free-text and enumerations which have the same semantics. However, some of the enumerations might get extended. In that case the implementor might want to provide a free text alternative to a new element which a receiving might not understand. In that case, I think we want the receiver to know the difference between an alternative and an additional semantic. I think we could probably do that by adding an attribute of some kind. For example: slovenly ralenti 3) Of course, we also have the elements in basic PIDF which are legal in the element and in the element. I am already getting the same headache I get when I think about parsing SDP c-lines. Implementations have already used the in the element to apply to elements with no note of their own, and also to imply a note appropriate for a element. Yuck! Now we are talking about introducing a new element explicitly for the element and possibly another for the element. What are the semantics of each of these notes? How do I merge these notes? If one of these a status, a funny saying, directions to contact me, or some characteristic of the tuple, person, or device? I think the existing is (or has become) an opaque blob of text that users of IM systems expect to be conveyed transparently for a specific *service*. I do not think it applies to a element because the semantics of the blob are not known. All this talk about separate status like "running out of battery power" for your device is nice in theory, but we should call them something else. I also don't think we will be able to agree on crisp semantics, in part because I don't think these extensions are a core part of the data model. Here some examples of notes I have seen at various times. Where do each of these belong? How do I compose these? I don't know about others, but I won't even try. I'll present/render each one under the service that provided the note. Purple Califlower! at home +1 408 555 1212 At Lunch bork, bork, bork Away Stepped Out Ah, home Lovestad 08:00 GMT +2 http://ln-s/983/ So, while I am not opposed to additional free-text fields, they should have specific semantics and they should have a different name than the current element, which has become useless for automata. thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 25 22:21:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQFh9-0000TX-Ma; Mon, 25 Apr 2005 22:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQFh8-0000Sw-4r for simple@megatron.ietf.org; Mon, 25 Apr 2005 22:21:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22880 for ; Mon, 25 Apr 2005 22:20:59 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQFtU-0005QE-Jx for simple@ietf.org; Mon, 25 Apr 2005 22:33:48 -0400 Received: from [192.168.0.31] (pool-141-153-174-47.mad.east.verizon.net [141.153.174.47]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3Q2Kr16021806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Apr 2005 22:20:54 -0400 (EDT) Message-ID: <426DA57A.7010809@cs.columbia.edu> Date: Mon, 25 Apr 2005 22:20:42 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> In-Reply-To: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > > > > I got my paycheck! > The example is borrowed from the Jabber docs, if I recall correctly, which have a similar mechanism. > > "I got my paycheck" is not a mood; it is a statement. While it's nice > that you got paid, that statement doesn't belong here IMO. There are at least two uses of such free text: (1) Explaining the background for an enumeration. ("I got my paycheck!") (2) Providing additional values for an enumeration which are not captured by the existing list ("Juggling chainsaws") Both are of value, I believe. I don't think it is particularly helpful to try to create two types of elements for this, as this seems unlikely to be observed by users typing in this information. The likely consequence of facilitating (2) is to essentially make that the enumeration extension mechanism for software. > 2) ** I think we should try to avoid having both free-text and > enumerations which have the same semantics. However, some of the > enumerations might get extended. In that case the implementor might > want to provide a free text alternative to a new element which a > receiving might not understand. In that case, I think we want the > receiver to know the difference between an alternative and an additional > semantic. I think we could probably do that by adding an attribute of > some kind. For example: > > > > slovenly > ralenti > This might be interesting, but seems awfully complex for this case. How likely is it that we'll see implementations of this? > > > 3) Of course, we also have the elements in basic PIDF which are > legal in the element and in the element. I am > already getting the same headache I get when I think about parsing SDP > c-lines. Implementations have already used the in the > element to apply to elements with no note of their own, and also > to imply a note appropriate for a element. Yuck! Now we > are talking about introducing a new element explicitly for the > element and possibly another for the element. What > are the semantics of each of these notes? How do I merge these notes? > If one of these a status, a funny saying, directions to contact me, or > some characteristic of the tuple, person, or device? > > I think the existing is (or has become) an opaque blob of text > that users of IM systems expect to be conveyed transparently for a > specific *service*. I do not think it applies to a element > because the semantics of the blob are not known. The only justification for a generic note, for example, is to explain things that are not captured by any of the existing RPID elements. For a contrived example, suppose we have not yet introduced a 'visual appearance' element, so something like Bad hair day - please don't ask for video. will be a -specific note. This clearly describes a person, not a device or a service. > > All this talk about separate status like "running out of battery power" > for your device is nice in theory, but we should call them something > else. I also don't think we will be able to agree on crisp semantics, in > part because I don't think these extensions are a core part of the data > model. > > Here some examples of notes I have seen at various times. Where do each > of these belong? How do I compose these? I don't know about others, > but I won't even try. I'll present/render each one under the service > that provided the note. Or simply show all of them if I need to compose multiple elements. The whole point of free text is to allow for a reality that can't easily be classified into neat enumerations. > > Purple Califlower! > at home +1 408 555 1212 > At Lunch > bork, bork, bork > Away > Stepped Out > Ah, home > Lovestad 08:00 GMT +2 > http://ln-s/983/ > > So, while I am not opposed to additional free-text fields, they should > have specific semantics and they should have a different name than the > current element, which has become useless for automata. are always going to be useless for automata. That's why they are there... I agree that having notes/free-text close to elements that they describe is useful, since it makes filtering, for example, easier (avoids information leakage) and allows better context-appropriate rendering (e.g., showing a balloon text over the activities icon). Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 25 22:54:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGDX-0004bJ-KP; Mon, 25 Apr 2005 22:54:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGDW-0004ai-DV for simple@megatron.ietf.org; Mon, 25 Apr 2005 22:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25780 for ; Mon, 25 Apr 2005 22:54:27 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQGPs-0006ab-Gb for simple@ietf.org; Mon, 25 Apr 2005 23:07:17 -0400 Received: from [192.168.0.39] (services.xten.net [69.28.248.106]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j3Q2sN106239; Mon, 25 Apr 2005 19:54:23 -0700 In-Reply-To: <426DA57A.7010809@cs.columbia.edu> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] Free text in presence documents Date: Mon, 25 Apr 2005 19:54:23 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 25, 2005, at 19:20, Henning Schulzrinne wrote: > Rohan Mahy wrote: > >> >> >> I got my paycheck! >> > > The example is borrowed from the Jabber docs, if I recall correctly, > which have a similar mechanism. > >> "I got my paycheck" is not a mood; it is a statement. While it's >> nice that you got paid, that statement doesn't belong here IMO. > > There are at least two uses of such free text: > > (1) Explaining the background for an enumeration. ("I got my > paycheck!") I understand that a *human* recognizes this as a justification, but its just not relevant semantically in the context of the mood element. (The creation of which is intended to be useful to computer programs). Semantically, the justification is just a statement about the person. Somebody should put this as a textual element elsewhere. (see my comment about below) > (2) Providing additional values for an enumeration which are not > captured by the existing list ("Juggling chainsaws") > > Both are of value, I believe. I don't think it is particularly helpful > to try to create two types of elements for this, as this seems > unlikely to be observed by users typing in this information. The > likely consequence of facilitating (2) is to essentially make that the > enumeration extension mechanism for software. > >> 2) ** I think we should try to avoid having both free-text and >> enumerations which have the same semantics. However, some of the >> enumerations might get extended. In that case the implementor might >> want to provide a free text alternative to a new element which a >> receiving might not understand. In that case, I think we want the >> receiver to know the difference between an alternative and an >> additional semantic. I think we could probably do that by adding an >> attribute of some kind. For example: >> >> >> slovenly >> ralenti >> > > This might be interesting, but seems awfully complex for this case. > How likely is it that we'll see implementations of this? do you care about being able to make a distinction between additional values and alternative values? additional value: brushing teeth alternative value: dejeuner >> 3) Of course, we also have the elements in basic PIDF which >> are legal in the element and in the element. I am >> already getting the same headache I get when I think about parsing >> SDP c-lines. Implementations have already used the in the >> element to apply to elements with no note of their >> own, and also to imply a note appropriate for a element. >> Yuck! Now we are talking about introducing a new element >> explicitly for the element and possibly another for the >> element. What are the semantics of each of these notes? >> How do I merge these notes? If one of these a status, a funny >> saying, directions to contact me, or some characteristic of the >> tuple, person, or device? >> I think the existing is (or has become) an opaque blob of text >> that users of IM systems expect to be conveyed transparently for a >> specific *service*. I do not think it applies to a element >> because the semantics of the blob are not known. > > The only justification for a generic note, for example, is to > explain things that are not captured by any of the existing RPID > elements. For a contrived example, suppose we have not yet introduced > a 'visual appearance' element, so something like > > Bad hair day - please don't ask for video. > > will be a -specific note. > > This clearly describes a person, not a device or a service. Sure. But I don't think we should call it a element. It's the element or something. This would make it much more clear for implementors that these things are different. This thing can also be of type Note_t, but it would have different semantics than other elements of the same type. >> All this talk about separate status like "running out of battery >> power" for your device is nice in theory, but we should call them >> something else. I also don't think we will be able to agree on crisp >> semantics, in part because I don't think these extensions are a core >> part of the data model. >> Here some examples of notes I have seen at various times. Where do >> each of these belong? How do I compose these? I don't know about >> others, but I won't even try. I'll present/render each one under the >> service that provided the note. > > Or simply show all of them if I need to compose multiple > elements. > > The whole point of free text is to allow for a reality that can't > easily be classified into neat enumerations. but the whole point of writing a schema is to come up with crisp semantics so real programmers can write real programs that have a hope of parsing, rendering, composing, sending this information. Bonus points if the parsing and sending actual results in interop. ;-) >> Purple Califlower! >> at home +1 408 555 1212 >> At Lunch >> bork, bork, bork >> Away >> Stepped Out >> Ah, home >> Lovestad 08:00 GMT +2 >> http://ln-s/983/ >> So, while I am not opposed to additional free-text fields, they >> should have specific semantics and they should have a different name >> than the current element, which has become useless for >> automata. > > are always going to be useless for automata. That's why they > are there... you always need a relief valve / garbage pit. We need to have one, but we only need *one*. has become that garbage pit. We don't need to create a proliferation of them. thanks, -rohan > I agree that having notes/free-text close to elements that they > describe is useful, since it makes filtering, for example, easier > (avoids information leakage) and allows better context-appropriate > rendering (e.g., showing a balloon text over the activities icon). > > Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Mon Apr 25 23:29:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGlD-0000gj-Ru; Mon, 25 Apr 2005 23:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQGlC-0000gO-1t for simple@megatron.ietf.org; Mon, 25 Apr 2005 23:29:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28321 for ; Mon, 25 Apr 2005 23:29:12 -0400 (EDT) Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQGxV-0007Xr-Mi for simple@ietf.org; Mon, 25 Apr 2005 23:42:03 -0400 Received: from [192.168.0.31] (pool-141-153-174-47.mad.east.verizon.net [141.153.174.47]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3Q3TBTN003169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Apr 2005 23:29:11 -0400 (EDT) Message-ID: <426DB587.7090604@cs.columbia.edu> Date: Mon, 25 Apr 2005 23:29:11 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 3.0 (+++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > > I understand that a *human* recognizes this as a justification, but its > just not relevant semantically in the context of the mood element. (The Indeed - it explains the mood to the human observer. > creation of which is intended to be useful to computer programs). Part (or for RPID, most of it) is display to humans. Computer programs generally don't appreciate moods as such. > Semantically, the justification is just a statement about the person. > Somebody should put this as a textual element elsewhere. (see my > comment about below) In general, I hope we agree that it is useful to be able to annote elements, as that provides semantic association that collecting this in one big blob loses. As I noted earlier, this also makes it a lot easier to filter out information based on context. If I don't want to show the mood element, removing the associated annotation is a lot easier if it is part of that element rather than all collected in some general annotation element. > do you care about being able to make a distinction between additional > values and alternative values? > > additional value: > > > brushing teeth > > > alternative value: > > > dejeuner > Not particularly. I very much doubt that user interfaces would expose this level of detail. > Sure. But I don't think we should call it a element. It's the > element or something. This would make it much more clear for > implementors that these things are different. This thing can also be of > type Note_t, but it would have different semantics than other elements > of the same type. I don't particularly care about the element tag. I don't see the harm of calling it a note - this seems to be universally understood as content to be rendered to humans, annotating the enclosing element. > but the whole point of writing a schema is to come up with crisp > semantics so real programmers can write real programs that have a hope > of parsing, rendering, composing, sending this information. Bonus > points if the parsing and sending actual results in interop. ;-) The semantics of or whatever you call them are clear: - No attempt at automated processing - Render close to the enclosing element, possibly in some way that indicates an annotation (mouse-over, alt-text, etc.) - Remove if enclosing element is removed. - Compose by concatenation within each element. Henning _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 04:39:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQLbZ-00071H-8m; Tue, 26 Apr 2005 04:39:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQLbW-000718-CW for simple@megatron.ietf.org; Tue, 26 Apr 2005 04:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14378 for ; Tue, 26 Apr 2005 04:39:36 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQLnv-0005TE-9g for simple@ietf.org; Tue, 26 Apr 2005 04:52:28 -0400 Received: by rproxy.gmail.com with SMTP id a41so1074650rng for ; Tue, 26 Apr 2005 01:39:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=inCKUPyaiTu9u+sMiT1TCWzpSOGOXY8UmVG2sU7TfUPBbtYQuj7tXOlnCezMx03TWBchLKL5B8FCEmWLTlzb4NqWM860Cww39s4tkQBKMrJ9/vXA/NhWKA74ZkWd4ijy5/UBcdpmp+XR4bAOEk/NrbYKQQvh6neUSg+syXFKufc= Received: by 10.38.24.45 with SMTP id 45mr7224041rnx; Tue, 26 Apr 2005 01:39:36 -0700 (PDT) Received: by 10.38.149.1 with HTTP; Tue, 26 Apr 2005 01:39:36 -0700 (PDT) Message-ID: Date: Tue, 26 Apr 2005 10:39:36 +0200 From: Miguel Eduardo Gil Biraud To: simple@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Simple] MSRP implementation question X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Miguel Eduardo Gil Biraud List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hello all, I just joined the mailing list, so I hope I am not asking anything too obvi= ous. I am wondering if there is any reference implementation of the MSRP stack available somewhere and any software that implements MSRP. Thank you, Miguel Eduardo Gil Biraud miguel.gil.biraud@ieee.org _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 10:05:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQQgP-00023E-PY; Tue, 26 Apr 2005 10:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQQgO-00021c-C4 for simple@megatron.ietf.org; Tue, 26 Apr 2005 10:05:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10297 for ; Tue, 26 Apr 2005 10:04:58 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQQsp-0005B0-V8 for simple@ietf.org; Tue, 26 Apr 2005 10:17:53 -0400 Received: from rtp-core-2.cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 26 Apr 2005 07:04:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j3QE4kdr014367; Tue, 26 Apr 2005 10:04:47 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 10:04:46 -0400 Received: from cisco.com ([161.44.79.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 10:04:46 -0400 Message-ID: <426E4A7E.8020303@cisco.com> Date: Tue, 26 Apr 2005 10:04:46 -0400 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: Henning Schulzrinne Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2005 14:04:46.0274 (UTC) FILETIME=[E7036220:01C54A68] X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Interesting discussion. I agree with Rohan about the value of associating semantics with additional elements. However I don't think the examples really accomplish that. You may believe that brushing teeth Adds a new semantic element to , but other than knowing it is is a different element, what semantic is the watching UA supposed to associate with it? I think it would make more sense to associate free text with an existing defined enumeration element. The interpretation would be one of specialization: This element may be semantically treated as simply . As long as each enumeration as at least one sufficiently vague element there should always be something reasonable to attach your refinement to. Paul Henning Schulzrinne wrote: > Rohan Mahy wrote: > >> > >> I understand that a *human* recognizes this as a justification, but >> its just not relevant semantically in the context of the mood >> element. (The > > > Indeed - it explains the mood to the human observer. > > >> creation of which is intended to be useful to computer programs). > > > Part (or for RPID, most of it) is display to humans. Computer programs > generally don't appreciate moods as such. > > >> Semantically, the justification is just a statement about the person. >> Somebody should put this as a textual element elsewhere. (see my >> comment about below) > > > In general, I hope we agree that it is useful to be able to annote > elements, as that provides semantic association that collecting this in > one big blob loses. As I noted earlier, this also makes it a lot easier > to filter out information based on context. If I don't want to show the > mood element, removing the associated annotation is a lot easier if it > is part of that element rather than all collected in some general > annotation element. > > >> do you care about being able to make a distinction between additional >> values and alternative values? >> >> additional value: >> >> >> brushing teeth >> >> >> alternative value: >> >> >> dejeuner >> > > > Not particularly. I very much doubt that user interfaces would expose > this level of detail. > >> Sure. But I don't think we should call it a element. It's the >> element or something. This would make it much more clear >> for implementors that these things are different. This thing can also >> be of type Note_t, but it would have different semantics than other >> elements of the same type. > > > I don't particularly care about the element tag. I don't see the harm of > calling it a note - this seems to be universally understood as content > to be rendered to humans, annotating the enclosing element. > >> but the whole point of writing a schema is to come up with crisp >> semantics so real programmers can write real programs that have a hope >> of parsing, rendering, composing, sending this information. Bonus >> points if the parsing and sending actual results in interop. ;-) > > > The semantics of or whatever you call them are clear: > > - No attempt at automated processing > > - Render close to the enclosing element, possibly in some way that > indicates an annotation (mouse-over, alt-text, etc.) > > - Remove if enclosing element is removed. > > - Compose by concatenation within each element. > > Henning > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 10:45:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRJH-0006cu-Ou; Tue, 26 Apr 2005 10:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQRJG-0006cp-Uw for simple@megatron.ietf.org; Tue, 26 Apr 2005 10:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13934 for ; Tue, 26 Apr 2005 10:45:09 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQRVh-00062i-3J for simple@ietf.org; Tue, 26 Apr 2005 10:58:04 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id D6B4BA98AC; Tue, 26 Apr 2005 16:44:55 +0200 (CEST) Received: from [192.168.1.57] (unknown [82.196.214.14]) by voyager.coretrek.no (Postfix) with ESMTP id 7DA5DA98B2; Tue, 26 Apr 2005 16:44:53 +0200 (CEST) In-Reply-To: <426E4A7E.8020303@cisco.com> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <426E4A7E.8020303@cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77ce7fab9e7b46756e3bf028267ffdad@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Free text in presence documents Date: Tue, 26 Apr 2005 16:44:53 +0200 To: Paul Kyzivat X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Interesting discussion indeed. It took a couple of reads and sometime to understand what Rohan is trying to do, but I get it now :) I agree with Rohan that the semantics behind the elements that exist today and the proposed ones for and are vague. I also agree that they need to be renamed to make it easier for implementers to understand what purpose they serve. But the catch is that those things require human input. I'm not talking about the human implementers. I am talking about end users. You can rename the element to , but that will only help implementers name the label next to the edit box a little better. That's about it. We cannot control what the end user will put there. I don't quite understand the multi language thing. Are you proposing that the element be repeated in different languages? In that case, how does a compositor know which one the watcher wants? Paul, for your suggestion below, do you mean that all existing s need that text attribute? Isnt it a bit too much? /Hisham On Apr 26, 2005, at 4:04 PM, Paul Kyzivat wrote: > Interesting discussion. > > I agree with Rohan about the value of associating semantics with > additional elements. However I don't think the examples really > accomplish that. You may believe that > > brushing teeth > > Adds a new semantic element to , but other than knowing it > is is a different element, what semantic is the watching UA supposed > to associate with it? > > I think it would make more sense to associate free text with an > existing defined enumeration element. The interpretation would be one > of specialization: > > > > This element may be semantically treated as simply . As long as > each enumeration as at least one sufficiently vague element there > should always be something reasonable to attach your refinement to. > > Paul > > Henning Schulzrinne wrote: >> Rohan Mahy wrote: >>> >>> I understand that a *human* recognizes this as a justification, but >>> its just not relevant semantically in the context of the mood >>> element. (The >> Indeed - it explains the mood to the human observer. >>> creation of which is intended to be useful to computer programs). >> Part (or for RPID, most of it) is display to humans. Computer >> programs generally don't appreciate moods as such. >>> Semantically, the justification is just a statement about the >>> person. Somebody should put this as a textual element elsewhere. >>> (see my comment about below) >> In general, I hope we agree that it is useful to be able to annote >> elements, as that provides semantic association that collecting this >> in one big blob loses. As I noted earlier, this also makes it a lot >> easier to filter out information based on context. If I don't want to >> show the mood element, removing the associated annotation is a lot >> easier if it is part of that element rather than all collected in >> some general annotation element. >>> do you care about being able to make a distinction between >>> additional values and alternative values? >>> >>> additional value: >>> >>> >>> brushing teeth >>> >>> >>> alternative value: >>> >>> >>> dejeuner >>> >> Not particularly. I very much doubt that user interfaces would expose >> this level of detail. >>> Sure. But I don't think we should call it a element. It's >>> the element or something. This would make it much more >>> clear for implementors that these things are different. This thing >>> can also be of type Note_t, but it would have different semantics >>> than other elements of the same type. >> I don't particularly care about the element tag. I don't see the harm >> of calling it a note - this seems to be universally understood as >> content to be rendered to humans, annotating the enclosing element. >>> but the whole point of writing a schema is to come up with crisp >>> semantics so real programmers can write real programs that have a >>> hope of parsing, rendering, composing, sending this information. >>> Bonus points if the parsing and sending actual results in interop. >>> ;-) >> The semantics of or whatever you call them are clear: >> - No attempt at automated processing >> - Render close to the enclosing element, possibly in some way that >> indicates an annotation (mouse-over, alt-text, etc.) >> - Remove if enclosing element is removed. >> - Compose by concatenation within each element. >> Henning >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 13:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQTe2-0003r3-Lp; Tue, 26 Apr 2005 13:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQTe1-0003qP-2V for simple@megatron.ietf.org; Tue, 26 Apr 2005 13:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27264 for ; Tue, 26 Apr 2005 13:14:42 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQTqT-0001zy-9W for simple@ietf.org; Tue, 26 Apr 2005 13:27:39 -0400 Received: from [192.168.0.39] (services.xten.net [69.28.248.106]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j3QHEc109281; Tue, 26 Apr 2005 10:14:38 -0700 In-Reply-To: <426DB587.7090604@cs.columbia.edu> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9a5a39471199885157c7f1795c065e44@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] Free text in presence documents Date: Tue, 26 Apr 2005 10:15:06 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 25, 2005, at 20:29, Henning Schulzrinne wrote: > Rohan Mahy wrote: > >> I understand that a *human* recognizes this as a justification, but >> its just not relevant semantically in the context of the mood >> element. (The > > Indeed - it explains the mood to the human observer. I disagree that it explains any more to the human observer *here* under the mood element than it would in a generic textual element hanging under person. >> creation of which is intended to be useful to computer programs). > > Part (or for RPID, most of it) is display to humans. Computer programs > generally don't appreciate moods as such. humans are not directly reading the XML document. Computer programs will read the XML and render the contents as best they can. Having a proliferation of "annotations" each in different parts of the XML document are unlikely to be of any more value to a human, but a proliferation of text fields makes it difficult for computer programs to know how to render the information. Even for devices with a relatively large display area, there are human factors issues which prevent programs from displaying annotations all over the place. >> Semantically, the justification is just a statement about the person. >> Somebody should put this as a textual element elsewhere. (see my >> comment about below) > > In general, I hope we agree that it is useful to be able to annote > elements, as that provides semantic association that collecting this > in one big blob loses. As I noted earlier, this also makes it a lot > easier to filter out information based on context. If I don't want to > show the mood element, removing the associated annotation is a lot > easier if it is part of that element rather than all collected in some > general annotation element. I absolutely disagree. Tons of human factors studies show that annotating arbitrary elements with arbitrary text is NOT generally useful for humans, even if the computer program could figure out how to display the information in a sensible way. >> do you care about being able to make a distinction between additional >> values and alternative values? >> additional value: >> >> >> brushing teeth >> >> alternative value: >> >> >> dejeuner >> > > Not particularly. I very much doubt that user interfaces would expose > this level of detail. This is not just an issue for display, it is also an issue for compositing. The difference from a UI perspective seems pretty easy to display. Take a french user interface displaying: voyager, "brushing teeth" or just "dejeuner" I'm not sure what you imagine a UI would display for activities, but I am imagining either a list of words, or a set of icons (which would effectively exclude custom strings not known by the UI. >> Sure. But I don't think we should call it a element. It's >> the element or something. This would make it much more >> clear for implementors that these things are different. This thing >> can also be of type Note_t, but it would have different semantics >> than other elements of the same type. > > I don't particularly care about the element tag. I don't see the harm > of calling it a note - this seems to be universally understood as > content to be rendered to humans, annotating the enclosing element. that's not the semantics of the current element. A under the root element actually "annotates" the status or a characteristic of (possibly many) elements. >> but the whole point of writing a schema is to come up with crisp >> semantics so real programmers can write real programs that have a >> hope of parsing, rendering, composing, sending this information. >> Bonus points if the parsing and sending actual results in interop. >> ;-) > > The semantics of or whatever you call them are clear: > > - No attempt at automated processing > > - Render close to the enclosing element, possibly in some way that > indicates an annotation (mouse-over, alt-text, etc.) > > - Remove if enclosing element is removed. > > - Compose by concatenation within each element. I don't agree that concatenation is appropriate here. For example, merging these two by concatenation is not likely what the user intended. asleep at the dentist thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 13:54:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUG1-0007qc-WA; Tue, 26 Apr 2005 13:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUFz-0007qX-N8 for simple@megatron.ietf.org; Tue, 26 Apr 2005 13:53:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00291 for ; Tue, 26 Apr 2005 13:53:58 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQUST-0002xY-Fp for simple@ietf.org; Tue, 26 Apr 2005 14:06:54 -0400 Received: from [192.168.0.39] (services.xten.net [69.28.248.106]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j3QHqc109408; Tue, 26 Apr 2005 10:52:38 -0700 In-Reply-To: <77ce7fab9e7b46756e3bf028267ffdad@telio.no> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <426E4A7E.8020303@cisco.com> <77ce7fab9e7b46756e3bf028267ffdad@telio.no> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] Free text in presence documents Date: Tue, 26 Apr 2005 10:53:09 -0700 To: Hisham Khartabil X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , Paul Kyzivat , "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 26, 2005, at 7:44, Hisham Khartabil wrote: > I don't quite understand the multi language thing. Are you proposing > that the element be repeated in different languages? In that > case, how does a compositor know which one the watcher wants? If the human user types something in a small number of languages, you can provide all of them and the receiver can display the best one, but only if it knows the difference between an alternative and an additional text element ;-) thanks, -rohan _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 14:33:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUru-0004Wm-Ev; Tue, 26 Apr 2005 14:33:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQUrs-0004We-Gc for simple@megatron.ietf.org; Tue, 26 Apr 2005 14:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03486 for ; Tue, 26 Apr 2005 14:33:07 -0400 (EDT) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQV4M-0003vt-Cl for simple@ietf.org; Tue, 26 Apr 2005 14:46:03 -0400 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id CFFA5A98A8; Tue, 26 Apr 2005 20:32:56 +0200 (CEST) Received: from [192.168.1.57] (unknown [82.196.214.14]) by voyager.coretrek.no (Postfix) with ESMTP id AB2D7A98A4; Tue, 26 Apr 2005 20:32:55 +0200 (CEST) In-Reply-To: References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <426E4A7E.8020303@cisco.com> <77ce7fab9e7b46756e3bf028267ffdad@telio.no> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6e2fbe5d7e6672d8434c874e343e1259@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Simple] Free text in presence documents Date: Tue, 26 Apr 2005 20:32:55 +0200 To: Rohan Mahy X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 26, 2005, at 7:53 PM, Rohan Mahy wrote: > > On Apr 26, 2005, at 7:44, Hisham Khartabil wrote: >> I don't quite understand the multi language thing. Are you proposing >> that the element be repeated in different languages? In that >> case, how does a compositor know which one the watcher wants? > > If the human user types something in a small number of languages, you > can provide all of them and the receiver can display the best one, but > only if it knows the difference between an alternative and an > additional text element ;-) So we need to group the alternatives or have an id for them. Hisham > > thanks, > -rohan > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 16:17:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWUf-0000kv-AE; Tue, 26 Apr 2005 16:17:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWUd-0000kq-2K for simple@megatron.ietf.org; Tue, 26 Apr 2005 16:17:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13712 for ; Tue, 26 Apr 2005 16:17:13 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWh7-0006V4-3i for simple@ietf.org; Tue, 26 Apr 2005 16:30:11 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j3QK1BTO004290; Tue, 26 Apr 2005 16:01:11 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Apr 2005 15:56:48 -0400 Message-ID: From: Eric Burger To: "Gonzalo Camarillo (JO/LMF)" Subject: RE: [Simple] message-sessions-10 WGLC: unique message ID and fail ed connections? Date: Tue, 26 Apr 2005 15:56:43 -0400 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-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: SIMPLE mailing list X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org I agree wholeheartedly. Yes, like Ben, I'm coming to this party late. However, a unique message ID fixes a bunch of problems we can see = coming (see previous thread). Moreover, it makes message delivery = notification (my next project) a lot easier. Since the namespace of Message ID is rather large, and SMTP has been generating unique Message ID's for, what, 20 years, do you think we = could get consensus on this issue? > -----Original Message----- > From: simple-bounces@ietf.org=20 > [mailto:simple-bounces@ietf.org] On Behalf Of Ignacio M=E1s=20 > Ivars (KI/EAB) > Sent: Thursday, April 14, 2005 8:13 AM > To: Gonzalo Camarillo (JO/LMF); Paul Kyzivat=20 > Cc: SIMPLE mailing list > Subject: RE: [Simple] message-sessions-10 WGLC: unique=20 > message ID and failed connections? >=20 > Paul, Gonzalo: >=20 > I agree completely with Gonzalo's comment. That is why I was=20 > suggesting that we just add the paragraph from RFC 2822 were=20 > the uniqueness of message ID is defined, i.e: >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc282= 2 > The "Message-ID:" field provides a unique message identifier that > refers to a particular version of a particular message. The > uniqueness of the message identifier is guaranteed by the host = that > generates it. This message identifier is intended to be > machine readable and not necessarily meaningful to humans.=20 > A message > identifier pertains to exactly one instantiation of a particular > message; subsequent revisions to the message each receive=20 > new message > identifiers. > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3Drfc282= 2 >=20 > That would not introduce any other disruptment to the draft, would = it? >=20 > /Ignacio >=20 > -----Original Message----- > From: Gonzalo Camarillo > To: Paul Kyzivat > Cc: Ignacio M=E1s Ivars (KI/EAB); SIMPLE mailing list > Sent: 4/13/2005 8:41 PM > Subject: Re: [Simple] message-sessions-10 WGLC: unique=20 > message ID and failed connections? >=20 > Paul, >=20 > > But, as with everything else, this could get complex in a 3pcc=20 > > situation. A 3pcc controller might do a transfer using=20 > reinvites. As=20 > > result, one endpoint thinks it has a replacement session, while the = > > other thinks it has a new session. The guy who thinks its a new > session=20 > > can't very well know what message ids had been used before. >=20 > I agree with you on this one. We have already been there=20 > (e.g., the comedia and the preconditions stuff), and relaying=20 > on the concept of a SIP session to set the scope of any=20 > media-related identifier is not a good idea. >=20 > Paul and I tried exactly the same in comedia (using=20 > identifiers scoped by the SIP session) and cocluded that they=20 > did not work. >=20 > > Its only > > soluiton is to use message ids that are guaranteed to be=20 > globally > unique. >=20 > Yes, I agree this is the way to resolve the problem. In fact,=20 > I believe this is how RFC 2822 defines uniqueness of message=20 > identifiers. With your proposal we kill two birds with the=20 > same stone. We align with RFC > 2822 and we resolve the session mobility problem. >=20 > Thanks, >=20 > Gonzalo >=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-bounces@ietf.org Tue Apr 26 16:17:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWUi-0000lQ-0N; Tue, 26 Apr 2005 16:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQWUf-0000lL-V2 for simple@megatron.ietf.org; Tue, 26 Apr 2005 16:17:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13716 for ; Tue, 26 Apr 2005 16:17:16 -0400 (EDT) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQWhB-0006V9-LI for simple@ietf.org; Tue, 26 Apr 2005 16:30:14 -0400 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j3QK1DTO004294; Tue, 26 Apr 2005 16:01:13 -0400 (EDT) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Apr 2005 15:56:51 -0400 Message-ID: From: Eric Burger To: Orit Levin , Hisham Khartabil Subject: RE: [Simple] Impending WGLC: msrp relays Date: Tue, 26 Apr 2005 15:56:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Let me take another view on this: Why propose something we know the Security AD's [should] reject out of hand? They will not [should not] be happy with the thought of plaintext passwords being handed off between relays that, while possibly trusted by your first relay, are not trusted by the user. > -----Original Message----- > From: simple-bounces@ietf.org > [mailto:simple-bounces@ietf.org] On Behalf Of Orit Levin > Sent: Monday, March 21, 2005 12:31 PM > To: Hisham Khartabil > Cc: Miguel Garcia; Avshalom Houri; Simple WG > Subject: RE: [Simple] Impending WGLC: msrp relays > > The text in 9.1 is very clear about the limitations being > introduced by using Basic. > > The draft says: only weakness of Basic authentication in MSRP is that "inner" > relays can view the credentials used to authenticate with > "outer" relays. When multiple relays are under the > administration of a single domain, this is unlikely to be a > major problem. ......> > > This language is a little ambiguous because "ideally" MSRP > should work in both directions :-) which would mean that each > relay can in clear see passwords being exchanged with the others. > > As the draft says, the Basic mechanism (may be somehow) can > make sense for deployments restricted to a single relay > provider ... BUT even "closed" clouds being deployed today > don't build on this limitation. Not mentioning that we are > moving towards inter-domain communications. Not mentioning > that it doesn't fit the IETF spirit in general. > > Orit. > > > -----Original Message----- > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > Behalf > > Of Hisham Khartabil > > Sent: Monday, March 21, 2005 1:56 AM > > To: Orit Levin > > Cc: Miguel Garcia; Avshalom Houri; Simple WG > > Subject: Re: [Simple] Impending WGLC: msrp relays > > > > Please finish your sentence below by stating the > limitations of basic > > (not in general, but in this specific MSRP relay instance > where TLS is > > used). If something is broken, we fix it NOW. > > > > Regards, > > Hisham > > > > On Mar 20, 2005, at 9:25 PM, Orit Levin wrote: > > > > > I don't understand why we are going back and arguing about the > > > requirements at this point. Especially since the Basic > "simplification" > > > has been introduced just recently with the -10 version... > > > > > > What would be wrong with stating in the document that > > > > > > with > > > MSRP as specified by this spec. These are the limitations to pay > > > attention to when using Basic... Future specifications can > standardize > > > how additional authentication algorithms are applied to MSRP and > > > negotiated using the AUTH method transaction.> > > > > > > More inline. > > > Orit. > > > > > >> -----Original Message----- > > >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > >> Sent: Sunday, March 20, 2005 1:26 AM > > >> To: Avshalom Houri > > >> Cc: Orit Levin; Simple WG > > >> Subject: Re: [Simple] Impending WGLC: msrp relays > > >> > > >> Avshalom: > > >> > > >> Isn't it so that, in any case, no matter whether you use Basic or > > > Digest > > >> authentication, the administrator of the relay can always see the > > > users' > > >> password? > > > [OL] No, it is not. For example, when using Digest, there is no > > > password in clear that can be seen by an intermediate relay. > > >> I can imagine that the administrator has the tools and > control to > > >> enable eavesdropping of password at the relay. > > > [OL] Existing commercial systems today have invested a lot of > efforts > > > to > > > design mechanisms that would prevent any possible (close to > > > unimaginable) malicious behavior. Here once again we are > trying to > > > standardize a mechanism that is weaker than the existing > solutions > > > today. > > >> The basic assumption > > >> is that users trust the relay, the same way that users trust > existing > > >> commertial e-mail or presence services for storing > username/password > > >> combinations. > > > [OL] There is a big difference between trusting a relay > for routing > the > > > data and trusting the same relay for not looking at it. > > >> > > >> /Miguel > > >> > > >> Avshalom Houri wrote: > > >>> > > >>> Actually Orit may be raising an issue that we have not thought > > > about. > > >>> Basic authentication enables the relay administrator to see the > > >>> passwords of the users. This is not acceptable by many > > >>> organizations. > > >>> > > >>> Can we say that the relay will accept digest authentication also > or > > >> enable > > >>> an extensibility mechanism? > > >>> Adding digest authentication may be easier to do but it > may not be > > >>> acceptable to organizations like 3GPP that use different > > >>> authentication > method > > > for > > >>> SIP. > > >>> > > >>> Avshalom > > >>> > > >>> simple-bounces@ietf.org wrote on 10/03/2005 01:06:50 AM: > > >>> > > >>>> Guys, > > >>>> > > >>>> One of the open issues mentioned during the meeting was > > > addressing > > >> the > > >>>> MSRP Relay extensibility mechanism. > > >>>> > > >>>> With the latest simplification of the authentication to be > > > limited to > > >>>> Basic only, it becomes a major topic that needs to be > nailed down > > >> before > > >>>> the spec closure. (Although the Basic over encrypted hop-by-hop > > > links > > >>>> may be OK for some deployments - it will not be acceptable for > > >> others.) > > >>>> > > >>>> It is absolutely necessarily to define a mechanism that will > > > allow > > >> for > > >>>> signaling alternative authentication methods (potentially among > > > other > > >>>> features). Without it, I don't think MSRP can be deployed and > > > remain > > >>>> interoperable. > > >>>> > > >>>> Orit. > > >>>> > > >>>>> -----Original Message----- > > >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > > > On > > >>>> Behalf > > >>>>> Of Robert Sparks > > >>>>> Sent: Wednesday, March 09, 2005 7:29 AM > > >>>>> To: Simple WG > > >>>>> Subject: [Simple] Impending WGLC: msrp relays > > >>>>> > > >>>>> The relay draft will undergo some minor changes as > discussed in > > >>>>> the SIMPLE meetings this week in Minneapolis. The changes are > > >>>>> mostly simple editorial changes. One major change will be the > > >>>>> removal of the appendix describing stateless relay behavior. > > >>>>> > > >>>>> This revision will be posted after the I-D blackout. When it > > >> appears, > > >>>>> it will be WGLCed. Please feel free to send comments > against the > > >>>>> current draft (minus the appendix mentioned above) this > > > week > > >>>>> if you have time to provide them. > > >>>>> > > >>>>> RjS > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Simple mailing list > > >>>>> Simple@ietf.org > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > >>>> > > >>>> _______________________________________________ > > >>>> Simple mailing list > > >>>> Simple@ietf.org > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > >>> > > >>> > > >>> > > > > -------------------------------------------------------------- > --------- > > > - > > >>> > > >>> _______________________________________________ > > >>> Simple mailing list > > >>> Simple@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/simple > > >> > > >> -- > > >> Miguel A. Garcia tel:+358-50-4804586 > > >> Nokia Research Center Helsinki, Finland > > > > > > > > > _______________________________________________ > > > Simple mailing list > > > Simple@ietf.org > > > https://www1.ietf.org/mailman/listinfo/simple > > > > > > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www1.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 17:51:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXxv-0006VN-Tp; Tue, 26 Apr 2005 17:51:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQXxt-0006VD-Ry for simple@megatron.ietf.org; Tue, 26 Apr 2005 17:51:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21396 for ; Tue, 26 Apr 2005 17:51:31 -0400 (EDT) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYAO-0008Vy-J8 for simple@ietf.org; Tue, 26 Apr 2005 18:04:31 -0400 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 26 Apr 2005 17:51:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j3QLoeS4020553; Tue, 26 Apr 2005 17:51:20 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 17:51:19 -0400 Received: from cisco.com ([161.44.79.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 17:51:18 -0400 Message-ID: <426EB7D6.8030204@cisco.com> Date: Tue, 26 Apr 2005 17:51:18 -0400 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 Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <426E4A7E.8020303@cisco.com> <77ce7fab9e7b46756e3bf028267ffdad@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2005 21:51:18.0976 (UTC) FILETIME=[13F6BC00:01C54AAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Hisham Khartabil wrote: > Interesting discussion indeed. It took a couple of reads and sometime to > understand what Rohan is trying to do, but I get it now :) > > I agree with Rohan that the semantics behind the elements that > exist today and the proposed ones for and are vague. I > also agree that they need to be renamed to make it easier for > implementers to understand what purpose they serve. But the catch is > that those things require human input. I'm not talking about the human > implementers. I am talking about end users. You can rename the > element to , but that will only help implementers name the > label next to the edit box a little better. That's about it. We cannot > control what the end user will put there. > > I don't quite understand the multi language thing. Are you proposing > that the element be repeated in different languages? In that > case, how does a compositor know which one the watcher wants? > > Paul, for your suggestion below, do you mean that all existing s > need that text attribute? Isnt it a bit too much? Well, at least the way I showed it I guess it would require that, which would be annoying at this late date. There are other ways the same thing could be achieved. Perhaps: Brushing Teeth Paul > /Hisham > > > On Apr 26, 2005, at 4:04 PM, Paul Kyzivat wrote: > >> Interesting discussion. >> >> I agree with Rohan about the value of associating semantics with >> additional elements. However I don't think the examples really >> accomplish that. You may believe that >> >> brushing teeth >> >> Adds a new semantic element to , but other than knowing it >> is is a different element, what semantic is the watching UA supposed >> to associate with it? >> >> I think it would make more sense to associate free text with an >> existing defined enumeration element. The interpretation would be one >> of specialization: >> >> >> >> This element may be semantically treated as simply . As long as >> each enumeration as at least one sufficiently vague element there >> should always be something reasonable to attach your refinement to. >> >> Paul >> >> Henning Schulzrinne wrote: >> >>> Rohan Mahy wrote: >>> >>>> >>>> I understand that a *human* recognizes this as a justification, but >>>> its just not relevant semantically in the context of the mood >>>> element. (The >>> >>> Indeed - it explains the mood to the human observer. >>> >>>> creation of which is intended to be useful to computer programs). >>> >>> Part (or for RPID, most of it) is display to humans. Computer >>> programs generally don't appreciate moods as such. >>> >>>> Semantically, the justification is just a statement about the >>>> person. Somebody should put this as a textual element elsewhere. >>>> (see my comment about below) >>> >>> In general, I hope we agree that it is useful to be able to annote >>> elements, as that provides semantic association that collecting this >>> in one big blob loses. As I noted earlier, this also makes it a lot >>> easier to filter out information based on context. If I don't want to >>> show the mood element, removing the associated annotation is a lot >>> easier if it is part of that element rather than all collected in >>> some general annotation element. >>> >>>> do you care about being able to make a distinction between >>>> additional values and alternative values? >>>> >>>> additional value: >>>> >>>> >>>> brushing teeth >>>> >>>> >>>> alternative value: >>>> >>>> >>>> dejeuner >>>> >>> >>> Not particularly. I very much doubt that user interfaces would expose >>> this level of detail. >>> >>>> Sure. But I don't think we should call it a element. It's >>>> the element or something. This would make it much more >>>> clear for implementors that these things are different. This thing >>>> can also be of type Note_t, but it would have different semantics >>>> than other elements of the same type. >>> >>> I don't particularly care about the element tag. I don't see the harm >>> of calling it a note - this seems to be universally understood as >>> content to be rendered to humans, annotating the enclosing element. >>> >>>> but the whole point of writing a schema is to come up with crisp >>>> semantics so real programmers can write real programs that have a >>>> hope of parsing, rendering, composing, sending this information. >>>> Bonus points if the parsing and sending actual results in interop. ;-) >>> >>> The semantics of or whatever you call them are clear: >>> - No attempt at automated processing >>> - Render close to the enclosing element, possibly in some way that >>> indicates an annotation (mouse-over, alt-text, etc.) >>> - Remove if enclosing element is removed. >>> - Compose by concatenation within each element. >>> Henning >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www1.ietf.org/mailman/listinfo/simple >> >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www1.ietf.org/mailman/listinfo/simple >> > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 18:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYBW-0008Tm-41; Tue, 26 Apr 2005 18:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQYBU-0008S7-0V for simple@megatron.ietf.org; Tue, 26 Apr 2005 18:05:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22727 for ; Tue, 26 Apr 2005 18:05:33 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQYNy-0000KY-Tz for simple@ietf.org; Tue, 26 Apr 2005 18:18:33 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 26 Apr 2005 15:05:25 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j3QM5Lb4009836; Tue, 26 Apr 2005 15:05:22 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 18:05:21 -0400 Received: from cisco.com ([161.44.79.173]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Apr 2005 18:05:20 -0400 Message-ID: <426EBB20.8020804@cisco.com> Date: Tue, 26 Apr 2005 18:05:20 -0400 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: Rohan Mahy Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <9a5a39471199885157c7f1795c065e44@ekabal.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2005 22:05:20.0883 (UTC) FILETIME=[09C78C30:01C54AAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" , Henning Schulzrinne X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: >>> do you care about being able to make a distinction between additional >>> values and alternative values? >>> additional value: >>> >>> >>> brushing teeth >>> >>> alternative value: >>> >>> >>> dejeuner >>> >> >> >> Not particularly. I very much doubt that user interfaces would expose >> this level of detail. > > > This is not just an issue for display, it is also an issue for compositing. > The difference from a UI perspective seems pretty easy to display. Take > a french user interface displaying: > > voyager, "brushing teeth" or just "dejeuner" Rohan - I don't understand what you are proposing here. You seem to be showing two alternative meanings for the same extension syntax and suggesting to adopt them both. The defintion as alternative value, at least for translations, seems both unworkable and unnecessary to me as a way to translate predefined values: - unworkable because I see nothing in the syntax you show that binds the alternative to its primary. - unnecessary because the whole point of using standard enumerations is that the names are just labels for semantics - they aren't necessarily display names. The French UI is free to represent as "dejeuner" if it wants. (And the English UI can represent as "lunch".) The point of my proposal (with the new syntax in my response to Hisham) would be to permit you to define dejeuner Then a UI that wants to can display the text for this, and/or it can treat it exactly the same as (e.g. display a knife&fork icon.) In all cases, at least the new activity can be interpretted as some element with predefined semantics. > I'm not sure what you imagine a UI would display for activities, but I > am imagining either a list of words, or a set of icons (which would > effectively exclude custom strings not known by the UI. Paul _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 22:06:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQbwr-0007N4-91; Tue, 26 Apr 2005 22:06:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQbwq-0007Mz-JF for simple@megatron.ietf.org; Tue, 26 Apr 2005 22:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14410 for ; Tue, 26 Apr 2005 22:06:42 -0400 (EDT) Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQc9N-0006Rd-Oc for simple@ietf.org; Tue, 26 Apr 2005 22:19:44 -0400 Received: from [192.168.0.31] (pool-141-153-208-93.mad.east.verizon.net [141.153.208.93]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j3R26XqN000817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Apr 2005 22:06:34 -0400 (EDT) Message-ID: <426EF39F.2080908@cs.columbia.edu> Date: Tue, 26 Apr 2005 22:06:23 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rohan Mahy Subject: Re: [Simple] Free text in presence documents References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <9a5a39471199885157c7f1795c065e44@ekabal.com> In-Reply-To: <9a5a39471199885157c7f1795c065e44@ekabal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org Rohan Mahy wrote: > I disagree that it explains any more to the human observer *here* under > the mood element than it would in a generic textual element hanging > under person. No. Even in this contrived example, the sentence "I'm getting my paycheck!" has a different meaning when it appears next to mood 'happy' compared to a location reference. See also the item about filtering. mputer programs to > know how to render the information. Even for devices with a relatively > large display area, there are human factors issues which prevent > programs from displaying annotations all over the place. As noted earlier, it is actually easier that way, e.g., through mouse-overs, to render such annotations that are close to the element that they describe. > I absolutely disagree. Tons of human factors studies show that > annotating arbitrary elements with arbitrary text is NOT generally > useful for humans, even if the computer program could figure out how to > display the information in a sensible way. I'm curious: Any pointers to such studies? > > > asleep > > > > > > at the dentist > > This is actually a good example why a simple blob is not a good idea. In this case, composition would select one of the activities (if more credible), including the annotation. A single blob would not be selectable in that way. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Tue Apr 26 23:52:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdbM-0005Vy-56; Tue, 26 Apr 2005 23:52:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQdbK-0005Vs-M5 for simple@megatron.ietf.org; Tue, 26 Apr 2005 23:52:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21435 for ; Tue, 26 Apr 2005 23:52:36 -0400 (EDT) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQdnr-00005P-IM for simple@ietf.org; Wed, 27 Apr 2005 00:05:38 -0400 Received: from [192.168.0.39] (services.xten.net [69.28.248.106]) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j3R3qP111179; Tue, 26 Apr 2005 20:52:25 -0700 In-Reply-To: <426EF39F.2080908@cs.columbia.edu> References: <40d9d5ad8542b37bc0de84d1687217f6@ekabal.com> <426DA57A.7010809@cs.columbia.edu> <426DB587.7090604@cs.columbia.edu> <9a5a39471199885157c7f1795c065e44@ekabal.com> <426EF39F.2080908@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1850f3705d118aca5304afc7fea6308c@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Subject: Re: [Simple] Free text in presence documents Date: Tue, 26 Apr 2005 20:52:51 -0700 To: Henning Schulzrinne X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "simple@ietf.org WG" X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org On Apr 26, 2005, at 19:06, Henning Schulzrinne wrote: > Rohan Mahy wrote: > >> I disagree that it explains any more to the human observer *here* >> under the mood element than it would in a generic textual element >> hanging under person. > > No. Even in this contrived example, the sentence > > "I'm getting my paycheck!" > > has a different meaning when it appears next to mood 'happy' compared > to a location reference. See also the item about filtering. what different meaning? > mputer programs to >> know how to render the information. Even for devices with a >> relatively large display area, there are human factors issues which >> prevent programs from displaying annotations all over the place. > > As noted earlier, it is actually easier that way, e.g., through > mouse-overs, to render such annotations that are close to the element > that they describe. can you have a note element in a mood with no moods enumerated? what about multiple textual elements within an activities element? is that ok? how do you provide indication to the user that they can get more information by mousing-over? >> I absolutely disagree. Tons of human factors studies show that >> annotating arbitrary elements with arbitrary text is NOT generally >> useful for humans, even if the computer program could figure out how >> to display the information in a sensible way. > > I'm curious: Any pointers to such studies? I'll try to dig some up. >> >> >> asleep >> >> >> >> >> at the dentist >> >> > > This is actually a good example why a simple blob is not a good idea. > In this case, composition would select one of the activities (if more > credible), including the annotation. A single blob would not be > selectable in that way. I think you would judge the credibility of the entire person, tuple, or device, and disregard the entire thing is it is not credible. If the source isn't credible why would you keep any of the information that you discredited? thx, -r _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Apr 27 11:04:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQo5A-0005wL-MZ; Wed, 27 Apr 2005 11:04:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DQo58-0005vo-0u for simple@megatron.ietf.org; Wed, 27 Apr 2005 11:04:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22888 for ; Wed, 27 Apr 2005 11:04:01 -0400 (EDT) Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DQoHh-0006jq-73 for simple@ietf.org; Wed, 27 Apr 2005 11:17:09 -0400 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j3RF3i0Q140460 for ; Wed, 27 Apr 2005 15:03:44 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j3RF3igA291988 for ; Wed, 27 Apr 2005 17:03:44 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j3RF3ivE004251 for ; Wed, 27 Apr 2005 17:03:44 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j3RF3ivc004248; Wed, 27 Apr 2005 17:03:44 +0200 In-Reply-To: To: Eric Burger Subject: RE: [Simple] Impending WGLC: msrp relays MIME-Version: 1.0 X-Mailer: Lotus Notes Build V70_M4_01112005 Beta 3NP January 11, 2005 Message-ID: From: Avshalom Houri Date: Wed, 27 Apr 2005 18:03:41 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(V70_M4_01112005 Sidepack 2802|March 1, 2005) at 27/04/2005 18:03:43, Serialize complete at 27/04/2005 18:03:43 X-Spam-Score: 0.0 (/) X-Scan-Signature: 94ddbad0060c343c23e74ba9bbebbccf Cc: Orit Levin , Simple WG X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1639213965==" Sender: simple-bounces@ietf.org Errors-To: simple-bounces@ietf.org This is a multipart message in MIME format. --===============1639213965== Content-Type: multipart/alternative; boundary="=_alternative 0052BC1FC2256FF0_=" This is a multipart message in MIME format. --=_alternative 0052BC1FC2256FF0_= Content-Type: text/plain; charset="US-ASCII" Agree with Eric. >From an actual deployment of a different product I can say that it is a real requirement to not allow passwords in cleartext to be exposed in the server. Avshalom simple-bounces@ietf.org wrote on 26/04/2005 10:56:45 PM: > Let me take another view on this: > > Why propose something we know the Security AD's [should] reject out of hand? > > They will not [should not] be happy with the thought of plaintext passwords > being handed off between relays that, while possibly trusted by your first > relay, are not trusted by the user. > > > -----Original Message----- > > From: simple-bounces@ietf.org > > [mailto:simple-bounces@ietf.org] On Behalf Of Orit Levin > > Sent: Monday, March 21, 2005 12:31 PM > > To: Hisham Khartabil > > Cc: Miguel Garcia; Avshalom Houri; Simple WG > > Subject: RE: [Simple] Impending WGLC: msrp relays > > > > The text in 9.1 is very clear about the limitations being > > introduced by using Basic. > > > > The draft says: > only weakness of Basic authentication in MSRP is that "inner" > > relays can view the credentials used to authenticate with > > "outer" relays. When multiple relays are under the > > administration of a single domain, this is unlikely to be a > > major problem. ......> > > > > This language is a little ambiguous because "ideally" MSRP > > should work in both directions :-) which would mean that each > > relay can in clear see passwords being exchanged with the others. > > > > As the draft says, the Basic mechanism (may be somehow) can > > make sense for deployments restricted to a single relay > > provider ... BUT even "closed" clouds being deployed today > > don't build on this limitation. Not mentioning that we are > > moving towards inter-domain communications. Not mentioning > > that it doesn't fit the IETF spirit in general. > > > > Orit. > > > > > -----Original Message----- > > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On > > Behalf > > > Of Hisham Khartabil > > > Sent: Monday, March 21, 2005 1:56 AM > > > To: Orit Levin > > > Cc: Miguel Garcia; Avshalom Houri; Simple WG > > > Subject: Re: [Simple] Impending WGLC: msrp relays > > > > > > Please finish your sentence below by stating the > > limitations of basic > > > (not in general, but in this specific MSRP relay instance > > where TLS is > > > used). If something is broken, we fix it NOW. > > > > > > Regards, > > > Hisham > > > > > > On Mar 20, 2005, at 9:25 PM, Orit Levin wrote: > > > > > > > I don't understand why we are going back and arguing about the > > > > requirements at this point. Especially since the Basic > > "simplification" > > > > has been introduced just recently with the -10 version... > > > > > > > > What would be wrong with stating in the document that > > > > > > > > > with > > > > MSRP as specified by this spec. These are the limitations to pay > > > > attention to when using Basic... Future specifications can > > standardize > > > > how additional authentication algorithms are applied to MSRP and > > > > negotiated using the AUTH method transaction.> > > > > > > > > More inline. > > > > Orit. > > > > > > > >> -----Original Message----- > > > >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] > > > >> Sent: Sunday, March 20, 2005 1:26 AM > > > >> To: Avshalom Houri > > > >> Cc: Orit Levin; Simple WG > > > >> Subject: Re: [Simple] Impending WGLC: msrp relays > > > >> > > > >> Avshalom: > > > >> > > > >> Isn't it so that, in any case, no matter whether you use Basic or > > > > Digest > > > >> authentication, the administrator of the relay can always see the > > > > users' > > > >> password? > > > > [OL] No, it is not. For example, when using Digest, there is no > > > > password in clear that can be seen by an intermediate relay. > > > >> I can imagine that the administrator has the tools and > > control to > > > >> enable eavesdropping of password at the relay. > > > > [OL] Existing commercial systems today have invested a lot of > > efforts > > > > to > > > > design mechanisms that would prevent any possible (close to > > > > unimaginable) malicious behavior. Here once again we are > > trying to > > > > standardize a mechanism that is weaker than the existing > > solutions > > > > today. > > > >> The basic assumption > > > >> is that users trust the relay, the same way that users trust > > existing > > > >> commertial e-mail or presence services for storing > > username/password > > > >> combinations. > > > > [OL] There is a big difference between trusting a relay > > for routing > > the > > > > data and trusting the same relay for not looking at it. > > > >> > > > >> /Miguel > > > >> > > > >> Avshalom Houri wrote: > > > >>> > > > >>> Actually Orit may be raising an issue that we have not thought > > > > about. > > > >>> Basic authentication enables the relay administrator to see the > > > >>> passwords of the users. This is not acceptable by many > > > >>> organizations. > > > >>> > > > >>> Can we say that the relay will accept digest authentication also > > or > > > >> enable > > > >>> an extensibility mechanism? > > > >>> Adding digest authentication may be easier to do but it > > may not be > > > >>> acceptable to organizations like 3GPP that use different > > > >>> authentication > > method > > > > for > > > >>> SIP. > > > >>> > > > >>> Avshalom > > > >>> > > > >>> simple-bounces@ietf.org wrote on 10/03/2005 01:06:50 AM: > > > >>> > > > >>>> Guys, > > > >>>> > > > >>>> One of the open issues mentioned during the meeting was > > > > addressing > > > >> the > > > >>>> MSRP Relay extensibility mechanism. > > > >>>> > > > >>>> With the latest simplification of the authentication to be > > > > limited to > > > >>>> Basic only, it becomes a major topic that needs to be > > nailed down > > > >> before > > > >>>> the spec closure. (Although the Basic over encrypted hop-by-hop > > > > links > > > >>>> may be OK for some deployments - it will not be acceptable for > > > >> others.) > > > >>>> > > > >>>> It is absolutely necessarily to define a mechanism that will > > > > allow > > > >> for > > > >>>> signaling alternative authentication methods (potentially among > > > > other > > > >>>> features). Without it, I don't think MSRP can be deployed and > > > > remain > > > >>>> interoperable. > > > >>>> > > > >>>> Orit. > > > >>>> > > > >>>>> -----Original Message----- > > > >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] > > > > On > > > >>>> Behalf > > > >>>>> Of Robert Sparks > > > >>>>> Sent: Wednesday, March 09, 2005 7:29 AM > > > >>>>> To: Simple WG > > > >>>>> Subject: [Simple] Impending WGLC: msrp relays > > > >>>>> > > > >>>>> The relay draft will undergo some minor changes as > > discussed in > > > >>>>> the SIMPLE meetings this week in Minneapolis. The changes are > > > >>>>> mostly simple editorial changes. One major change will be the > > > >>>>> removal of the appendix describing stateless relay behavior. > > > >>>>> > > > >>>>> This revision will be posted after the I-D blackout. When it > > > >> appears, > > > >>>>> it will be WGLCed. Please feel free to send comments > > against the > > > >>>>> current draft (minus the appendix mentioned above) this > > > > week > > > >>>>> if you have time to provide them. > > > >>>>> > > > >>>>> RjS > > > >>>>> > > > >>>>> > > > >>>>> _______________________________________________ > > > >>>>> Simple mailing list > > > >>>>> Simple@ietf.org > > > >>>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>>> > > > >>>> _______________________________________________ > > > >>>> Simple mailing list > > > >>>> Simple@ietf.org > > > >>>> https://www1.ietf.org/mailman/listinfo/simple > > > >>> > > > >>> > > > >>> > > > > > > -------------------------------------------------------------- > > --------- > > > > - > > > >>> > > > >>> _______________________________________________ > > > >>> Simple mailing list > > > >>> Simple@ietf.org > > > >>> https://www1.ietf.org/mailman/listinfo/simple > > > >> > > > >> -- > > > >> Miguel A. Garcia tel:+358-50-4804586 > > > >> Nokia Research Center Helsinki, Finland > > > > > > > > > > > > _______________________________________________ > > > > 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 --=_alternative 0052BC1FC2256FF0_= Content-Type: text/html; charset="US-ASCII"
Agree with Eric.
From an actual deployment of a different product I can say that it is a real requirement to not allow passwords in cleartext to be exposed in the server.

Avshalom


simple-bounces@ietf.org wrote on 26/04/2005 10:56:45 PM:

> Let me take another view on this:
>
> Why propose something we know the Security AD's [should] reject out of hand?
>
> They will not [should not] be happy with the thought of plaintext passwords
> being handed off between relays that, while possibly trusted by your first
> relay, are not trusted by the user.
>
> > -----Original Message-----
> > From: simple-bounces@ietf.org
> > [mailto:simple-bounces@ietf.org] On Behalf Of Orit Levin
> > Sent: Monday, March 21, 2005 12:31 PM
> > To: Hisham Khartabil
> > Cc: Miguel Garcia; Avshalom Houri; Simple WG
> > Subject: RE: [Simple] Impending WGLC: msrp relays
> >
> > The text in 9.1 is very clear about the limitations being
> > introduced by using Basic.
> >
> > The draft says: <When used over TLS-protected channels, the
> > only weakness of Basic authentication in MSRP is that "inner"
> > relays can view the credentials used to authenticate with
> > "outer" relays. When multiple relays are under the
> > administration of a single domain, this is unlikely to be a
> > major problem. ......>
> >
> > This language is a little ambiguous because "ideally" MSRP
> > should work in both directions :-) which would mean that each
> > relay can in clear see passwords being exchanged with the others.
> >
> > As the draft says, the Basic mechanism (may be somehow) can
> > make sense for deployments restricted to a single relay
> > provider ... BUT even "closed" clouds being deployed today
> > don't build on this limitation. Not mentioning that we are
> > moving towards inter-domain communications. Not mentioning
> > that it doesn't fit the IETF spirit in general.
> >
> > Orit.
> >
> > > -----Original Message-----
> > > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On
> > Behalf
> > > Of Hisham Khartabil
> > > Sent: Monday, March 21, 2005 1:56 AM
> > > To: Orit Levin
> > > Cc: Miguel Garcia; Avshalom Houri; Simple WG
> > > Subject: Re: [Simple] Impending WGLC: msrp relays
> > >
> > > Please finish your sentence below by stating the
> > limitations of basic
> > > (not in general, but in this specific MSRP relay instance
> > where TLS is
> > > used). If something is broken, we fix it NOW.
> > >
> > > Regards,
> > > Hisham
> > >
> > > On Mar 20, 2005, at 9:25 PM, Orit Levin wrote:
> > >
> > > > I don't understand why we are going back and arguing about the
> > > > requirements at this point. Especially since the Basic
> > "simplification"
> > > > has been introduced just recently with the -10 version...
> > > >
> > > > What would be wrong with stating in the document that
> > > >
> > > > <Basic is the first standardized authentication method to be used
> > with
> > > > MSRP as specified by this spec. These are the limitations to pay
> > > > attention to when using Basic... Future specifications can
> > standardize
> > > > how additional authentication algorithms are applied to MSRP and
> > > > negotiated using the AUTH method transaction.>
> > > >
> > > > More inline.
> > > > Orit.
> > > >
> > > >> -----Original Message-----
> > > >> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com]
> > > >> Sent: Sunday, March 20, 2005 1:26 AM
> > > >> To: Avshalom Houri
> > > >> Cc: Orit Levin; Simple WG
> > > >> Subject: Re: [Simple] Impending WGLC: msrp relays
> > > >>
> > > >> Avshalom:
> > > >>
> > > >> Isn't it so that, in any case, no matter whether you use Basic or
> > > > Digest
> > > >> authentication, the administrator of the relay can always see the
> > > > users'
> > > >> password?
> > > > [OL] No, it is not. For example, when using Digest, there is no
> > > > password in clear that can be seen by an intermediate relay.
> > > >> I can imagine that the administrator has the tools and
> > control to
> > > >> enable eavesdropping of password at the relay.
> > > > [OL] Existing commercial systems today have invested a lot of
> > efforts
> > > > to
> > > > design mechanisms that would prevent any possible (close to
> > > > unimaginable) malicious behavior. Here once again we are
> > trying to
> > > > standardize a mechanism that is weaker than the existing
> > solutions
> > > > today.
> > > >> The basic assumption
> > > >> is that users trust the relay, the same way that users trust
> > existing
> > > >> commertial e-mail or presence services for storing
> > username/password
> > > >> combinations.
> > > > [OL] There is a big difference between trusting a relay
> > for routing
> > the
> > > > data and trusting the same relay for not looking at it.
> > > >>
> > > >> /Miguel
> > > >>
> > > >> Avshalom Houri wrote:
> > > >>>
> > > >>> Actually Orit may be raising an issue that we have not thought
> > > > about.
> > > >>> Basic authentication enables the relay administrator to see the
> > > >>> passwords of the users. This is not acceptable by many
> > > >>> organizations.
> > > >>>
> > > >>> Can we say that the relay will accept digest authentication also
> > or
> > > >> enable
> > > >>> an extensibility mechanism?
> > > >>> Adding digest authentication may be easier to do but it
> > may not be
> > > >>> acceptable to organizations like 3GPP that use different
> > > >>> authentication
> > method
> > > > for
> > > >>> SIP.
> > > >>>
> > > >>> Avshalom
> > > >>>
> > > >>> simple-bounces@ietf.org wrote on 10/03/2005 01:06:50 AM:
> > > >>>
> > > >>>> Guys,
> > > >>>>
> > > >>>> One of the open issues mentioned during the meeting was
> > > > addressing
> > > >> the
> > > >>>> MSRP Relay extensibility mechanism.
> > > >>>>
> > > >>>> With the latest simplification of the authentication to be
> > > > limited to
> > > >>>> Basic only, it becomes a major topic that needs to be
> > nailed down
> > > >> before
> > > >>>> the spec closure. (Although the Basic over encrypted hop-by-hop
> > > > links
> > > >>>> may be OK for some deployments - it will not be acceptable for
> > > >> others.)
> > > >>>>
> > > >>>> It is absolutely necessarily to define a mechanism that will
> > > > allow
> > > >> for
> > > >>>> signaling alternative authentication methods (potentially among
> > > > other
> > > >>>> features). Without it, I don't think MSRP can be deployed and
> > > > remain
> > > >>>> interoperable.
> > > >>>>
> > > >>>> Orit.
> > > >>>>
> > > >>>>> -----Original Message-----
> > > >>>>> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]
> > > > On
> > > >>>> Behalf
> > > >>>>> Of Robert Sparks
> > > >>>>> Sent: Wednesday, March 09, 2005 7:29 AM
> > > >>>>> To: Simple WG
> > > >>>>> Subject: [Simple] Impending WGLC: msrp relays
> > > >>>>>
> > > >>>>> The relay draft will undergo some minor changes as
> > discussed in
> > > >>>>> the SIMPLE meetings this week in Minneapolis. The changes are
> > > >>>>> mostly simple editorial changes. One major change will be the
> > > >>>>> removal of the appendix describing stateless relay behavior.
> > > >>>>>
> > > >>>>> This revision will be posted after the I-D blackout. When it
> > > >> appears,
> > > >>>>> it will be WGLCed. Please feel free to send comments
> > against the
> > > >>>>> current draft (minus the appendix mentioned above) this
> > > > week
> > > >>>>> if you have time to provide them.
> > > >>>>>
> > > >>>>> RjS
> > > >>>>>
> > > >>>>>
> > > >>>>> _______________________________________________
> > > >>>>> Simple mailing list
> > > >>>>> Simple@ietf.org
> > > >>>>> https://www1.ietf.org/mailman/listinfo/simple
> > > >>>>
> > > >>>> _______________________________________________
> > > >>>> Simple mailing list
> > > >>>> Simple@ietf.org
> > > >>>> https://www1.ietf.org/mailman/listinfo/simple
> > > >>>
> > > >>>
> > > >>>
> > > >
> > --------------------------------------------------------------
> > ---------
> > > > -
> > > >>>
> > > >>> _______________________________________________
> > > >>> Simple mailing list
> > > >>> Simple@ietf.org
> > > >>> https://www1.ietf.org/mailman/listinfo/simple
> > > >>
> > > >> --
> > > >> Miguel A. Garcia           tel:+358-50-4804586
> > > >> Nokia Research Center      Helsinki, Finland
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
 --=_alternative 0052BC1FC2256FF0_=-- --===============1639213965== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple --===============1639213965==--