Re: [Simple] IMDN Issue 4: Disposition = Notification Types

Hi,

I can see some little misunderstanding here. = The=20 presence rules document does not refer to any RLS service here. The = situation=20 tested by this test case is that user Dave has some resource-lists = document=20 in Shared XDMS

<resource-lists>

   =20 <entry>Alice</entry>
   =20 <entry>Bob</entry>
    <entry>Ch= arles</entry>
=20 </list>

</resource-lists>

And the = same=20 user Dave has = presence-rules document=20 in Presence XDMS

&nbs= p;

=20 <conditions>

=20 <external anchor=3Dhttp://SharedXdms/res= ource-lists/users/sip:dave@domain.com/index/~~/resource-lists/list%5b@nam= e=3D%22friends%22%5d/>

=20 </conditions>

=20 <actions>

=20 <sub-handling>allow</sub-handling>

=20 </actions>

=20 <transformations></transformations>

</ruleset>

Using=20 reference to some list defined in Shared XDMS the user can use something = like=20 "controlling access to presence information" for some group of users. = Note that=20 neither RLS service is referenced nor list in rls-services=20 document.

br, Martin

From: Noga Tor = [mailto:noga.tor@gmail.com]=20
Sent: 28. srpna 2006 15:03
To: simple@ietf.org;=20 Tschofenig, Hannes
Subject: Re: [Simple] Authorization Rules = for=20 groups

I have no problem with this approach. It seems very logical to me = the=20 Presence XDMS will not have any knowledge of groups (RLS XDMS).

However, I have bumped into an OMA test fest use = case, which=20 implies that such a connection should exist. I will append the text of = the use=20 case and let me know what u think...

-- cut --

------_=_NextPart_001_01C6CAB3.79D32520-- --===============1191196805== 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 --===============1191196805==-- From simple-bounces@ietf.org Tue Aug 29 05:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHzoR-0008SH-Rd; Tue, 29 Aug 2006 05:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHzoR-0008SB-DY for simple@ietf.org; Tue, 29 Aug 2006 05:23:15 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHybt-0000W4-I2 for simple@ietf.org; Tue, 29 Aug 2006 04:06:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHyMP-0000Wl-32 for simple@ietf.org; Tue, 29 Aug 2006 03:50:15 -0400 Received: by ug-out-1314.google.com with SMTP id m2so2047456uge for ; Tue, 29 Aug 2006 00:50:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=M4oLLkFPyK+arGKlpoxcm81x2RsdR53EJfXi7ZEExX89Rc0SFNS63SR0tPGRdy4H71iSaaozY63Ph5qdP1b3IeWHCqcHq4LKn4hKQuWvfmkzhGzVlAwwey4oEnY1FCZgqDxJSgvzQbwG1TDKV+rv4jCLQSs3CoH7et9f6Tr//4s= Received: by 10.67.101.8 with SMTP id d8mr4259514ugm; Tue, 29 Aug 2006 00:50:09 -0700 (PDT) Received: by 10.67.20.16 with HTTP; Tue, 29 Aug 2006 00:50:09 -0700 (PDT) Message-ID: <44781c350608290050g5ba6606fh29213e9569b189ce@mail.gmail.com> Date: Tue, 29 Aug 2006 10:50:09 +0300 From: "Noga Tor" To: simple@ietf.org MIME-Version: 1.0 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Simple] question about Presence XDMS AUID 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="===============1486518254==" Errors-To: simple-bounces@ietf.org --===============1486518254== Content-Type: multipart/alternative; boundary="----=_Part_6011_15389643.1156837809761" ------=_Part_6011_15389643.1156837809761 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi I was reading the OMA document regarding the AUID of the Presence XDMS and I stumbled into something confusing. DEFINITION OF APPLICATION UNIQUE ID ================================== * 5.1.2.2 Application Unique ID * The AUID SHALL be "org.openmobilealliance.pres-rules". EXAMPLE OF USAGE WITH APPLICATION UNIQUE ID ========================================== 1) The user "sip:ronald.underwood@example.com" wants to obtain the document describing his Presence Authorisation Rules. For this purpose the XDM Client sends an HTTP GET request to the Aggregation Proxy. GET http://xcap.example.com/pres-rules/users/sip:ronald.underwood@example.com/pres-rulesHTTP/1.1 Content-Length: 0 2) Based on the AUID the Aggregation Proxy forwards the request to the Presence XDMS. What does it mean, based on the AUID? the "GET" request did not contain the AUID in the same format mentioned above, so by which part do we base the conclusion that this should be forwarded to the Presence XDMS?? Thanks Noga ------=_Part_6011_15389643.1156837809761 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

I was reading the OMA document regarding the AUID of the Presence XDMS and I stumbled into something confusing.

DEFINITION OF APPLICATION UNIQUE ID

==================================

5.1.2.2 Application Unique ID

The AUID SHALL be "org.openmobilealliance.pres-rules".

EXAMPLE OF USAGE WITH APPLICATION UNIQUE ID

==========================================

1) The user "sip:ronald.underwood@example.com" wants to obtain the document describing his Presence Authorisation

Rules. For this purpose the XDM Client sends an HTTP GET request to the Aggregation Proxy.

GET http://xcap.example.com/pres-rules/users/sip:ronald.underwood@example.com/pres-rules HTTP/1.1

Content-Length: 0

2) Based on the AUID the Aggregation Proxy forwards the request to the Presence XDMS.

What does it mean, based on the AUID? the "GET" request did not contain the AUID in the same format mentioned above, so by which part do we base the conclusion that this should be forwarded to the Presence XDMS??

Thanks

Noga

------=_Part_6011_15389643.1156837809761-- --===============1486518254== 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 --===============1486518254==-- From simple-bounces@ietf.org Tue Aug 29 11:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5Eb-0006nY-MN; Tue, 29 Aug 2006 11:10:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GI5EZ-0006nN-Op; Tue, 29 Aug 2006 11:10:35 -0400 Received: from [2001:5c0:8fff:fffe::4c49] (helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GI5ET-0008TX-Kz; Tue, 29 Aug 2006 11:10:35 -0400 Received: from [172.17.2.252] (vicuna.estacado.net [72.1.129.69]) (authenticated bits=0) by nostrum.com (8.13.6/8.13.6) with ESMTP id k7TFAJ5F092087 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 29 Aug 2006 10:10:19 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <7FEE86DE-A536-4B2A-90D2-7E429B9D2913@nostrum.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: IETF SIP List , sipping , simple@ietf.org, sip-implementors@cs.columbia.edu From: Robert Sparks Date: Tue, 29 Aug 2006 10:10:23 -0500 X-Mailer: Apple Mail (2.752.2) Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Simple] SIPit 19 registration X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A couple of reminders: SIPit19 registration is open. The event will be Oct 16-20 at the University of New Hampshire InterOperability Laboratory. While the registration deadline is still a few weeks away (9/29), we are already over 70% full. If you are planning to attend and have not yet registered, you should do so soon. Also, please make your hotel reservations early - this is prime leaf- peeping season in New Hampshire and last minute hotels will be very hard to find. See www.sipit.net for more information. RjS _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 30 07:03:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINpr-0002jI-F2; Wed, 30 Aug 2006 07:02:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GINpq-0002jD-HJ for simple@ietf.org; Wed, 30 Aug 2006 07:02:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIMSF-0001Kt-Ks for simple@ietf.org; Wed, 30 Aug 2006 05:33:51 -0400 Received: from mail2.ics.ntts.co.jp ([202.32.24.42]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIMOW-0008OI-4k for simple@ietf.org; Wed, 30 Aug 2006 05:30:01 -0400 Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.7/NTTSOFT) with ESMTP id k7U9Twu9017863 for ; Wed, 30 Aug 2006 18:29:58 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.7/NTTSOFT) id k7U9Tw8v009380 for simple@ietf.org; Wed, 30 Aug 2006 18:29:58 +0900 (JST) Received: from mail26.silk.ntts.co.jp [10.7.18.26] by sadoku34.silk.ntts.co.jp with SMTP id UAA09379; Wed, 30 Aug 2006 18:29:58 +0900 Received: from localhost (localhost [127.0.0.1]) by mail26.silk.ntts.co.jp (8.13.7/8.13.4/mail26-5.4) with ESMTP id k7U9Tvwe023189 for ; Wed, 30 Aug 2006 18:29:57 +0900 (JST) Date: Wed, 30 Aug 2006 18:29:57 +0900 (JST) Message-Id: <20060830.182957.465784127.takamiya@po.ntts.co.jp> To: simple@ietf.org From: Noriaki TAKAMIYA X-Face: +<)&j!Ce24nM@a.\f6TA, ]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 4.2 on XEmacs 21.4.17 (Jumbo Shrimp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Simple] About discover MSRP relay X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, I'm newbie about this WG, but I have a question. When MSRP client wants to know the MSRP relay as the first hop, how does it work? In the draft-ietf-simple-msrp-relays-08.txt, it is described in the section 5.1 as the following: ---- Clients can be configured (typically through discovery or manual provisioning) with a list of relays they need to use. They MUST be ---- And then, the following method is described in section 8: ---- When resolving an MSRP URL which contains an explicit port number, an MSRP node follows the rules in section 6 of the MSRP base specification. MSRP URLs exchanged in SDP and in To-Path and From- Path headers in non-AUTH requests MUST have an explicit port number. (The only message in this specification that can have an MSRP URL without an explicit port number is in the To-Path header in an AUTH request.) The following rules allow MSRP clients to discover MSRP relays more easily in AUTH requests. If the hostport of an msrps: URL is an IPv4 address or an IPv6 reference and no port number is provided, use the default port number assigned by IANA. If the hostport is a domain name and an explicit port number is provided, attempt to look up a valid address record (A or AAAA) for the domain name. Connect using TLS over the default transport (TCP) with the default port number. If a domain name is provided but no port number, perform a DNS SRV [4] lookup for the '_msrps' service and '_tcp' transport at the domain name, and follow the SRV selection algorithm defined in that specification to select the entry. (An '_msrp' service is not defined, since AUTH are only sent over TLS.) If no SRV records are found, try an address lookup (A or AAAA) using the default port number procedures described in the previous paragraph. Note that AUTH requests MUST only be sent over a TLS-protected channel. An SRV lookup in the example.com domain might return: : ---- Some books describe that SIP INVITE is sent after AUTH requests are completed. In this situation, MSRP client can't know the first MSRP relay.... So, I have a qeustion: o Is the above discovery applied to find the first MSRP relay? o If yes, what does domain mean in this case? Is it the domain of MSRP client issuing the MSRP message, that of the peer MSRP client or configured MSRP relay's domain? If I misses some points, could you point any references? Regards, -- Noriaki Takamiya _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Wed Aug 30 10:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRQ9-0003Lu-Kj; Wed, 30 Aug 2006 10:52:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRQ7-0003LA-Ty for simple@ietf.org; Wed, 30 Aug 2006 10:51:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIQCG-0006xp-V5 for simple@ietf.org; Wed, 30 Aug 2006 09:33:37 -0400 Received: from dsl001-129-069.dfw1.dsl.speakeasy.net ([72.1.129.69] helo=vicuna.estacado.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GIPxN-0007Ja-E5 for simple@ietf.org; Wed, 30 Aug 2006 09:18:15 -0400 Received: from [192.168.1.100] (c-67-174-92-207.hsd1.tx.comcast.net [67.174.92.207]) (authenticated bits=0) by vicuna.estacado.net (8.13.6/8.13.4) with ESMTP id k7UDHtSv086395 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 30 Aug 2006 08:17:59 -0500 (CDT) (envelope-from ben@estacado.net) In-Reply-To: <20060830.182957.465784127.takamiya@po.ntts.co.jp> References: <20060830.182957.465784127.takamiya@po.ntts.co.jp> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <020DE9F2-4F45-4C42-A8DE-BF11825A36D4@estacado.net> Content-Transfer-Encoding: 7bit From: Ben Campbell Subject: Re: [Simple] About discover MSRP relay Date: Wed, 30 Aug 2006 08:17:49 -0500 To: Noriaki TAKAMIYA X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org HI, The text you quote merely talks about how your figure the IP address and port to use based on a known MSRP URL. We have not defined a mechanism to discover that. Currently an MSRP client will need to be configured to know if it should use a relay, and if so, the URL for that relay. It is possible we could define a more automatic discovery mechanism in the future, but we do not have one at present. Hope this helps! Ben. On Aug 30, 2006, at 4:29 AM, Noriaki TAKAMIYA wrote: > Hi, > > I'm newbie about this WG, but I have a question. > > When MSRP client wants to know the MSRP relay as the first hop, how > does it work? > > In the draft-ietf-simple-msrp-relays-08.txt, it is described in the > section 5.1 as the following: > ---- > Clients can be configured (typically through discovery or manual > provisioning) with a list of relays they need to use. They MUST be > ---- > > And then, the following method is described in section 8: > ---- > When resolving an MSRP URL which contains an explicit port > number, an > MSRP node follows the rules in section 6 of the MSRP base > specification. MSRP URLs exchanged in SDP and in To-Path and From- > Path headers in non-AUTH requests MUST have an explicit port > number. > (The only message in this specification that can have an MSRP URL > without an explicit port number is in the To-Path header in an AUTH > request.) > > The following rules allow MSRP clients to discover MSRP relays more > easily in AUTH requests. If the hostport of an msrps: URL is an > IPv4 > address or an IPv6 reference and no port number is provided, use > the > default port number assigned by IANA. If the hostport is a domain > name and an explicit port number is provided, attempt to look up a > valid address record (A or AAAA) for the domain name. Connect > using > TLS over the default transport (TCP) with the default port number. > > If a domain name is provided but no port number, perform a DNS SRV > [4] lookup for the '_msrps' service and '_tcp' transport at the > domain name, and follow the SRV selection algorithm defined in that > specification to select the entry. (An '_msrp' service is not > defined, since AUTH are only sent over TLS.) If no SRV records are > found, try an address lookup (A or AAAA) using the default port > number procedures described in the previous paragraph. Note that > AUTH requests MUST only be sent over a TLS-protected channel. > An SRV > lookup in the example.com domain might return: > : > ---- > > Some books describe that SIP INVITE is sent after AUTH requests are > completed. In this situation, MSRP client can't know the first MSRP > relay.... > > So, I have a qeustion: > > o Is the above discovery applied to find the first MSRP relay? > o If yes, what does domain mean in this case? Is it the domain of > MSRP client issuing the MSRP message, that of the peer MSRP client > or configured MSRP relay's domain? > > If I misses some points, could you point any references? > > Regards, > > -- > Noriaki Takamiya > > _______________________________________________ > 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 Aug 31 00:59:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIedj-0001uj-Il; Thu, 31 Aug 2006 00:58:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIedh-0001uT-Iu for simple@ietf.org; Thu, 31 Aug 2006 00:58:53 -0400 Received: from mail2.ics.ntts.co.jp ([202.32.24.42]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIedg-0003gj-25 for simple@ietf.org; Thu, 31 Aug 2006 00:58:53 -0400 Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.7/NTTSOFT) with ESMTP id k7V4wh27007097; Thu, 31 Aug 2006 13:58:43 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.7/NTTSOFT) id k7V4whJo014059; Thu, 31 Aug 2006 13:58:43 +0900 (JST) Received: from mail26.silk.ntts.co.jp [10.7.18.26] by sadoku34.silk.ntts.co.jp with SMTP id PAA14030; Thu, 31 Aug 2006 13:58:28 +0900 Received: from localhost (localhost [127.0.0.1]) by mail26.silk.ntts.co.jp (8.13.7/8.13.4/mail26-5.4) with ESMTP id k7V4wR3t024134; Thu, 31 Aug 2006 13:58:28 +0900 (JST) Date: Thu, 31 Aug 2006 13:58:28 +0900 (JST) Message-Id: <20060831.135828.304098361.takamiya@po.ntts.co.jp> To: ben@estacado.net Subject: Re: [Simple] About discover MSRP relay From: Noriaki TAKAMIYA In-Reply-To: <020DE9F2-4F45-4C42-A8DE-BF11825A36D4@estacado.net> References: <20060830.182957.465784127.takamiya@po.ntts.co.jp> <020DE9F2-4F45-4C42-A8DE-BF11825A36D4@estacado.net> X-Face: +<)&j!Ce24nM@a.\f6TA, ]^9Q76[_QN_[QR-(bT&>b40Oo[:`R(>b7!b-|q5k&.8CO[_Oh_ !9Nk0rikK70~?|08EFH|:]iF6pwPlnfEn-wo-voY:rP?%7p%cxjnbf'hglO'se&QwZN7/RVX!U7*P% cTV('HfHp+?g1+hx7\+J.W]G zYWv%LsDc X-Mailer: Mew version 4.2 on XEmacs 21.4.17 (Jumbo Shrimp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: simple@ietf.org X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Hi, Ben, >> Wed, 30 Aug 2006 08:17:49 -0500 >> [Subject: Re: [Simple] About discover MSRP relay] >> Ben Campbell wrote... > The text you quote merely talks about how your figure the IP address > and port to use based on a known MSRP URL. We have not defined a > mechanism to discover that. Currently an MSRP client will need to be > configured to know if it should use a relay, and if so, the URL for > that relay. I see. Thanks. -- Noriaki Takamiya _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 31 08:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlTu-0007Rp-LR; Thu, 31 Aug 2006 08:17:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIlTt-0007Qu-IY for simple@ietf.org; Thu, 31 Aug 2006 08:17:13 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIlTs-00051t-Qu for simple@ietf.org; Thu, 31 Aug 2006 08:17:13 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id k7VCH1p8032075; Thu, 31 Aug 2006 15:17:07 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 15:16:59 +0300 Received: from [172.21.35.180] ([172.21.35.180]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 31 Aug 2006 15:16:58 +0300 Message-ID: <44F6D33C.2040901@nokia.com> Date: Thu, 31 Aug 2006 15:17:00 +0300 From: Miguel Garcia User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) MIME-Version: 1.0 To: Ranjan Rajeev-RRANJAN1 Subject: Re: Progressive reports [Was Re: [Simple] IMDN Issue 4: Disposition Notification Types] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Aug 2006 12:16:58.0554 (UTC) FILETIME=[5B30A1A0:01C6CCF7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: simple@ietf.org, Eric Burger X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org Ranjan: First, the discussion will flow a bit faster if you copy me directly in e-mails you expect me to response, otherwise you need to wait until I catch up with this mailing list (as it is happening). Now, some inline comments. See below. Ranjan Rajeev-RRANJAN1 wrote: > Hi Hisham, Garcia, > > First of all I will like to introduce my self as I am responding on this > reflector for the first time. > > While reviewing this email thread I am thinking about the implications > of enabling the "in-progress" state and generating multiple "processing" > IMDNs. I have few questions regarding your proposed changes: > > As I understand, according to your suggested proposal to enable progress > report in a MSRP centralized conference, following will happen: > 1. all the reporting UAS need to enable the "In-processing" state and > send the "Processing" IMDN at frequent periodic Interval to the MSRP > conferencing server. Well, I disagree here. You don't need ALL the endpoints to generate progressive IMDNs. In fact, generation of progressive reports, like any other IMDN, is subject to a policy at the endpoint that generates the IMDN. Such policy may dictate not sending IMDNs, or sending some classes only, or sending all. The conference MSRP switch will have to aggregate them while they are received (if any is received). But other than that, I don't see if there is a problem. You want progressive reports, right? So the endpoints have to send them. > 2. The MSRP conferencing server also need to enable the "In-processing" > state, collect frequent periodic "Processing" IMDN's from all the > reporting UAS, collate all the results and generate "processing" IMDN at > frequent regular Interval to the Sender. True > > Questions: > 1. According to the current "draft-burger-simple-imdn-03" the reporting > UAS sends only one disposition IMDN per file transfer, this seems quite > reasonable. If IMDN's are enabled for progress report the number of > IMDN's generated will be huge. I am wondering what will be the > implication on the performance of the end points, the conferencing > server, and the network while handling these IMDN's? So, don't send/disable progressive reports. If you want detailed information, endpoints have to submit that detailed information, in whatever protocol format you want. If think that is not according to the local policy, the the policy in the MSRP switch has to disable progressive reporting. > > 2. With Progress reports enabled, A reporting UAS is supposed to send > frequent periodic IMDNs. The MSRP conferencing server may not be able to > ignore any IMDN and need to process all the received IMDNs. In this > situation it will be quite difficult for the MSRP conferencing server or > the sender to counter the "Denial of Service attack". Does this elevates > the security concerns? NO, I don't think so. The MSRP switch has the capability of disabling any kind of reports the policy says. If a malicious user would like to insert those report, first it should discover the MSRP URL, including the session ID, and if it has done it and fake the TCP connection. TLS would solve this problem. Further more, if this malicious user would manage to be able to insert IMDNs to the MSRP switch, why would it limit to sending IMDNs? It would be inserting malicious IMs. Once again, TLS solves this issue, IMHO. BR, Miguel > > Shall appreciate your response. > > Regards, > > Rajeev Ranjan > Network Advanced Technology > Motorola Inc, Arlington Heights, USA > > Hisham Khartabil wrote: > > Miguel, > > > After a discussion on the mailing list about IMDN types, I added the > "processing" IMDN type to my working copy of the draft (that I am > now finalising for submission). This "processing" IMDN type has 2 > states: "processed" and "stored". I guess you would need something > like "in-progress" as a state. > > In my working copy, the text forbids endpoints from generating > "processing" IMDNs, but if we add the state you suggest, I can relax > that restriction for "in-progress" state. > > Comments? (by Miguel and others :) > > > Hisham > > > On Aug 21, 2006, at 12:46 PM, Miguel Garcia wrote: > > > Hi: > > > I recently got into a discussion of a related use case, I > believe this is being under discussion in the OMA PoC WG. > Imagine you are in an MSRP centralized conference, and you are > sending a (large) file to to the roster through an MSRP switch. > The sender would like to receive end-to-end progress reports of > the file transfer for each individual participant. > > I've heard of a few proposals to enable this use case, but in my > opinion, the simplest one is to reuse IMDN to provide > progressive positive reports. So that would add a third type of > report to IMDN to the existing two. So, the current ones are > positive-delivery and negative-delivery. I think a third one, > progressive-delivery would be nice to have, and will solve this > requirement. > > Do people have any thoughts? > > > /Miguel > > > Hisham Khartabil wrote: > > In the draft, we have 2: delivered and read. There has been > suggestions to add a least 2 more, namely processed and stored. > Stored is sent by a store-and-forward server to indicate > that an IM has been stored. > Processed is sent by intermediaries to indicate that the IM > has been processed (like a 202). > I personally am against those additions. > The sender of the IM is the one that requests any type of > IMDN. So, through the UI, the user has to answer all the > following questions for every IM: > - Do I want to know if the IM is delivered > - Do I want to know if the IM has failed > - Do I want to know if the IM is read > and the new states you are asking for: > - Do I want to know if the IM is processed > - Do I want to know if the IM is stored > Of course these can be global settings, but still, too many. > when sending a SIP MESSAGE request, you will get the > transactional response 202 if the MESSAGE has been > processed. I don't see the need for IMDN to indicate so. I > also don't see why a user would want to know if a message is > stored or not. In any case, isn't this the same as processed? > Hisham > _______________________________________________ > Simple mailing list > Simple at ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia at neonsite.net > Nokia Research Center Helsinki, Finland > > > > > -- > Miguel A. Garcia tel:+358-50-4804586 > sip:miguel.garcia at neonsite.net > Nokia Research Center Helsinki, Finland > > > _______________________________________________ > Simple mailing list > Simple at ietf.org > https://www1.ietf.org/mailman/listinfo/simple > > > > > ------------------------------------------------------------------------ > > * *References*: > o *[Simple] IMDN Issue 4: Disposition Notification Types > * > + /From:/ Hisham Khartabil > o *Progressive reports [Was Re: [Simple] IMDN Issue 4: > Disposition Notification Types] * > + /From:/ Miguel Garcia > o *Re: Progressive reports [Was Re: [Simple] IMDN Issue 4: > Disposition Notification Types] * > + /From:/ Hisham Khartabil > > * Prev by Date: *Progressive reports [Was Re: [Simple] IMDN Issue 4: > Disposition Notification Types] * > * Next by Date: *Re: Progressive reports [Was Re: [Simple] IMDN > Issue 4: Disposition Notification Types] * > * Previous by thread: *Re: Progressive reports [Was Re: [Simple] > IMDN Issue 4: Disposition Notification Types] * > * Next by thread: *RE: [Simple] IMDN Issue 4: Disposition > Notification Types * > * Index(es): > o *Date* > o *Thread* > > > ------------------------------------------------------------------------ > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.garcia@neonsite.net Nokia Research Center Helsinki, Finland _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple From simple-bounces@ietf.org Thu Aug 31 13:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqPx-0003aU-7A; Thu, 31 Aug 2006 13:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIqPw-0003aI-CO for simple@ietf.org; Thu, 31 Aug 2006 13:33:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GImue-000656-Mu for simple@ietf.org; Thu, 31 Aug 2006 09:48:56 -0400 Received: from host5-122-static.103-195-b.business.telecomitalia.it ([195.103.122.5] helo=mail.ELIS.ORG) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GImuY-00005t-6W for simple@ietf.org; Thu, 31 Aug 2006 09:48:53 -0400 Received: from exchange2003.ELIS.ORG ([10.150.150.27]) by mail.ELIS.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Aug 2006 15:47:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [simple] About MSRP endpoint authentication Date: Thu, 31 Aug 2006 15:48:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [simple] About MSRP endpoint authentication Thread-Index: AcbNBBArkm+VhGIjS5iOjaLQV9a8/g== From: "Massimo Lupini" To: X-OriginalArrivalTime: 31 Aug 2006 13:47:36.0000 (UTC) FILETIME=[04290C00:01C6CD04] X-Spam-Score: -1.2 (-) X-Scan-Signature: d3308915082aec5bdcb405956a0eb0ae 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="===============1941709850==" Errors-To: simple-bounces@ietf.org This is a multi-part message in MIME format. --===============1941709850== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6CD04.1C1F8E92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6CD04.1C1F8E92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm newbie to this WG, but I have a couple of questions about the authentication mechanism. =20 In the draft-ietf-simple-msrp-relays-08.txt, the following scenario is described, in the section 3: ----------------- The following example show a typical MSRP session. The AUTH requests=20 are explained in a later section but left in the example for call=20 flow completeness.=20 =20 Alice a.example.org b.example.net Bob=20 | | | |=20 |::::::::::::::::::::>| connection opened |<::::::::::::::::::::|=20 |--- AUTH ----------->| |<-- AUTH ------------|=20 |<-- 200 OK-----------| |--- 200 OK---------->|=20 | | | |=20 .... time passes ....=20 | | | |=20 |--- SEND ----------->| | |=20 |<-- 200 OK ----------|:::::::::::::::::::>| (slow link) |=20 | |--- SEND ---------->| |=20 | |<-- 200 OK ---------|--- SEND ----------->|=20 | | | ....>|=20 | | | ..>|=20 | | |<-- 200 OK ----------|=20 | | |<-- REPORT ----------|=20 | |<-- REPORT ---------| |=20 |<-- REPORT ----------| | |=20 | | | |=20 =20 ---------------------------------- =20 My first question is: =20 When the MSRP client wants to initiate an MSRP session, how does the peer know that it must open a TLS connection and authenticate to relays of his realm? =20 The other one is: =20 Are the keys generated by the relay itself? Are username and password kept by the relay? If not, who would keep them and how would the relay obtain them?=20 =20 =20 If I've miss any points, could you point me to any references? =20 Regards, =20 Massimo Lupini =20 ---------------------------------- =20 Massimo Lupini CONSEL - Consulting Academy=20 Via S. Sandri 45, 00159 Roma=20 mobile: +39 3333600591 mail: m.lupini@elis.org=20 =20 ------_=_NextPart_001_01C6CD04.1C1F8E92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I'm newbie to this WG, but I have a couple of questions about the = authentication mechanism.

In the draft-ietf-simple-msrp-relays-08.txt, the following scenario is = described, in the

section<= /span> = 3:

-----------------=

The following example = show a typical MSRP session. The AUTH requests

are explained in a later section but left in the example for call =

flow completeness.

Alice &nbs= p; a.example.org b.e= xample.net &nbs= p; Bob

| &nbs= p; = ; | &nbs= p; | &nbs= p; = ; |

|::::::::::::::::::::>= ;| connection opened |<::::::::::::::::::::|

|--- AUTH ----------->| &nbs= p; |<-- AUTH ------------|

|<-- 200 OK-----------| &nbs= p; |--- 200 OK---------->|

| &nbs= p; = ; | &nbs= p; | &nbs= p; = ; |

.... time passes ....

| &nbs= p; = ; | &nbs= p; | &nbs= p; = ; |

|--- SEND ----------->| &nbs= p; | &nbs= p; = ; |

|<-- 200 OK = ----------|:::::::::::::::::::>| (slow link) &nbs= p; |

| &nbs= p; = ; |--- SEND ---------->| &nbs= p; = ; |

| &nbs= p; = ; |<-- 200 OK ---------|--- SEND ----------->| =

| &nbs= p; = ; | &nbs= p; | &nbs= p; ....>|

| &nbs= p; = ; | &nbs= p; | &nbs= p; ..>|

| &nbs= p; | &nbs= p; |<-- 200 OK ----------|

| &nbs= p; = ; | &nbs= p; |<-- REPORT ----------|

| &nbs= p; = ; |<-- REPORT ---------| &nbs= p; = ; |

|<-- REPORT ----------| &nbs= p; | &nbs= p; = ; |

| &nbs= p; | &nbs= p; | &nbs= p; = ; |

----------------------= ------------

My first question = is:

When the MSRP client = wants to initiate an MSRP session, how does the peer know that it must open a TLS = connection and authenticate to relays of his realm?

The other one = is:

Are the keys = generated by the relay itself? Are username and password kept by the relay? If not, who = would keep them and how would the relay obtain them? =

If I’ve miss = any points, could you point me to any references?

Regards,

Massimo = Lupini

-----------= -----------------------

Massimo = Lupini

CONSEL - = Consulting Academy
Via S. Sandri 45, 00159 Roma
mobile: +39 3333600591
mail: m.lupini@elis.org

=00 ------_=_NextPart_001_01C6CD04.1C1F8E92-- --===============1941709850== 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 --===============1941709850==-- From simple-bounces@ietf.org Thu Aug 31 18:51:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIvNn-0005Uv-0D; Thu, 31 Aug 2006 18:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIvNg-00056u-CO; Thu, 31 Aug 2006 18:51:28 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIvNe-00044F-Py; Thu, 31 Aug 2006 18:51:28 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k7VMpQeu020494; Thu, 31 Aug 2006 15:51:26 -0700 Received: (from apache@localhost) by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k7VMpQH7020493; Thu, 31 Aug 2006 15:51:26 -0700 Date: Thu, 31 Aug 2006 15:51:26 -0700 Message-Id: <200608312251.k7VMpQH7020493@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org X-Spam-Score: -14.8 (--------------) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] RFC 4662 on A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: simple-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4662 Title: A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists Author: A. B. Roach, B. Campbell, J. Rosenberg Status: Standards Track Date: August 2006 Mailbox: adam@estacado.net, ben@estacado.net, jdrosen@cisco.com Pages: 39 Characters: 82778 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-simple-event-list-07.txt URL: http://www.rfc-editor.org/rfc/rfc4662.txt This document presents an extension to the Session Initiation Protocol (SIP)-Specific Event Notification mechanism for subscribing to a homogeneous list of resources. Instead of sending a SUBSCRIBE for each resource individually, the subscriber can subscribe to an entire list and then receive notifications when the state of any of the resources in the list changes. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple

Test Case Id	Pr= esence-1.0-int-0123
Test Object	UE= s with Presence Source, Presence Watcher and XDMC functionality, Presence S= erver, and Shared XDMS.
Test Case Description	Verify t= hat a Presence Server can handle the Presence Rules document for groups of = watchers stored in the Shared XDMS.=20 TEST CASE GOAL: = Verify that a UE, a= cting as a XDMC, can modify his permissions for groups of watcher stored in= the Shared XDMS, and the PS handles these permissions properly.
Specification Reference	Refer to Appendix A
SCR Reference	Re= fer to Appendix A
Tool <= /td>	N/= A
Test Code=	N/= A
Preconditions	=B7 &nbs= p; <= span style=3D"mso-ansi-language: EN-US"> Equipment: o = 2 UEs (with User1, User2 credentials) o = Presence Server o = Presence XDMS o = Shared XDMS =B7 &nbs= p; <= span style=3D"mso-ansi-language: EN-US"> Prerequisite for this test: o = In the Presence XDMS, the Presence Authorization Rules document contains in= formation that Group A is authorized to see any of the presence information= belonging to User1. o = User2 is a member of Group A as defined by User1 o = UE2 capable of displaying presence information. o = User1 and User2 will have a set of commonly supported Presence elements. o = User1 has no active publications. o = User1 has the ability of changing the content of its Presence Authorization= Rules Document. o = User2 has no active subscriptions.
Test Procedure	1. &= nbsp; User1 publishes presence information for all co= mmonly supported mandatory Presence elements. 2. &= nbsp; User2 subscribe to presence information from Us= er1. 3. &= nbsp; User1 updates the Authorization Rules Document = in PS XDMS to block Group A to see his presence. 4. &= nbsp; User1 modifies the active presence information = that has been published.
Pass-Criteria	2. &= nbsp; UE2 display the presence information from User1= . 4. &= nbsp; UE2 does not display any presence information f= rom User1.