From simple-bounces@ietf.org Mon Aug 01 03:59:46 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVD8-00053A-A9; Mon, 01 Aug 2005 03:59:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVD6-00052Q-CE; Mon, 01 Aug 2005 03:59:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02947;
	Mon, 1 Aug 2005 03:59:42 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DzVjK-0002MS-UP; Mon, 01 Aug 2005 04:33:03 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j717sj8J011701; Mon, 1 Aug 2005 10:54:50 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 1 Aug 2005 10:58:40 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 1 Aug 2005 10:58:39 +0300
Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com
	([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; 
	Mon,  1 Aug 2005 07:58:39 +0000
Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com;
	01 Aug 2005 10:58:39 +0300
Subject: Re: [Simple] Presence Relax NG schemas
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
In-Reply-To: <42ECDEBF.9080502@cisco.com>
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 01 Aug 2005 10:58:39 +0300
Message-Id: <1122883119.8484.40.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.2 (2.2.2-5) 
X-OriginalArrivalTime: 01 Aug 2005 07:58:39.0606 (UTC)
	FILETIME=[D3ED9960:01C5966E]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Sun, 2005-07-31 at 10:22 -0400, ext Jonathan Rosenberg wrote:
> I don't have any particular views on the pros/cons of XML schema vs. 
> relax NG. However, my concern about this is whether there is value in 
> having TWO definitions of the grammar for these documents. It seems that 
> this is a recipe for interoperability problems. An XML-schema-using 
> implementation might define a document that is valid according to the 
> schema, but invalid according to the RELAX-NG definition. That would be 
> a problem. If that never happens, and neither can the converse (a 
> RELAX-NG compliant document that is not schema compliant), then the 
> RELAX-NG description is isomorphic to the XML schema, and so what is the 
> value exactly?
> 
> -Jonathan R.
I'll agree that it is not definitely an optimal solution to have two
definitions. Anyway, as you know, with the current W3C schemas you
cannot express where to put e.g. some extension elements when there are
many possible extension points: you could add e.g. <dm:person> element
under <presence>, <tuple> and <status>. And once you add new schemas
extension points just increase. However, these Relax NG schemas do not
allow this ambiguity. So they follow more strictly the intention of the
specs. Of course if these schemas don't correctly follow the specs, I am
glad to receive fixes.

Secondly, I am aware that ietf/xml-dev had these schema tool discussions
awhile back ago. AFAIK the recommendation does not mandate to use only
W3C schemas, it just seems to be the prevailing habit. At least in this
particular case Relax NG fits better for the task, imo.
As Aki notes, SIMPLEt might be the best "home" for this, but the schemas
have to be available somewhere (and bug free) 

thanks,
Jari

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 01 04:07:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVKc-0007RS-S1; Mon, 01 Aug 2005 04:07:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVKb-0007R7-2h
	for simple@megatron.ietf.org; Mon, 01 Aug 2005 04:07:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03752
	for <simple@ietf.org>; Mon, 1 Aug 2005 04:07:27 -0400 (EDT)
From: oran@cisco.com
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.43)
	id 1DzVqo-0002tu-OJ
	for simple@ietf.org; Mon, 01 Aug 2005 04:40:48 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 01 Aug 2005 01:07:18 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7187HJL022057;
	Mon, 1 Aug 2005 01:07:17 -0700 (PDT)
Received: from [86.255.4.42] (sjc-vpn7-411.cisco.com [10.21.145.155])
	by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7184kk0017245;
	Mon, 1 Aug 2005 01:04:46 -0700
In-Reply-To: <42E59B17.2080808@cs.columbia.edu>
References: <B0C588289108FAono.kumiko@lab.ntt.co.jp>
	<42E5597B.8030003@cisco.com> <42E59B17.2080808@cs.columbia.edu>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <5E98F2A2-E498-413A-8612-9AFC4B25B10C@cisco.com>
Content-Transfer-Encoding: 7bit
Subject: Re: [Simple] New draft on trust_path_discovery
Date: Mon, 1 Aug 2005 04:07:12 -0400
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.733)
DKIM-Signature: a=rsa-sha1;  q=dns; l=3364; t=1122883488; x=1123315688;
	c=nowsp; s=nebraska;
	h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=oran@cisco.com; 
	z=Subject:Re=3A=20[Simple]=20New=20draft=20on=20trust_path_discovery|
	From:oran@cisco.com|
	Date:Mon,=201=20Aug=202005=2004=3A07=3A12=20-0400|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=LAHfZzv3I4X2sqaGwiMdXgMqN44EUbx8Aj/w8kGojvz4t8kkRoZYAqwOiqlONkqLofEwbott
	qZX+g499u7uI9G4T1BGRdI+CXVT0cqt3xqr/gKX9v09Pp6VX8xKRln21QQH+CvrXS6urRc1/XEI
	cLVZRHFWSPObfMA38onVCzOA=
Authentication-Results: imail.cisco.com; header.From=oran@cisco.com;
	dkim=pass ( message from cisco.com verified; ); 
X-Spam-Score: 0.3 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Content-Transfer-Encoding: 7bit
Cc: kumiko@cs.columbia.edu, Kumiko Ono <ono.kumiko@lab.ntt.co.jp>,
	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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Jul 25, 2005, at 10:08 PM, Henning Schulzrinne wrote:

> Thanks for the comments. I agree that scaling is going to be a  
> challenge, although one has to be careful to compare distribution  
> with local caching with queries in terms of overall efficiency.  
> (This is something we have not done yet, unfortunately.) Unlike BGP  
> routing data, these trust relationships are likely to be stable  
> over very long time periods, measured at least in days or weeks, so  
> that the total volume of information may not be all that large,  
> particularly if one constrains the propagation. (This is the  
> converse to BGP aggregation - you need to advertise every prefix  
> that can't be aggregated, even if across ten AS hops, while long- 
> haul trust relationships are probably of little interest. A friend  
> ten links removed is not too meaningful.)
>
OTOH rapid revocation of trust when somebody on the trust chain gets  
indicted may be as bad rapid route withdrawal globally in BGP.

> In general, if this type of trust path discovery is useful, it is  
> likely to be useful for a somewhat enlarged group beyond one's own  
> immediate acquaintances. I would expect to find most IETFers and  
> networking faculty on my list of trust paths, but not a random  
> teenager from New Zealand. Those strangers may just have to send me  
> email first ("don't call me, I'll call you").
>
> The problem with query-based protocols is to find the trusting  
> parties, i.e., answering "who is trusting John Doe (who is sending  
> me an IM)?". It would be very difficult to go ask all my friends  
> and then have them ask their friends.
>
> As to the privacy issues, I think the only viable solution is to  
> only declare "public" trust, i.e., for people that one is willing  
> to stand up  for in public, similar to the links in the various  
> social network sites like Friendster. This will reduce the number  
> of trust relationships, but for most people, I suspect that the  
> large majority of "do I trust this person not to be selling  
> aluminum siding" cases won't fall into the category of friends that  
> need to be hidden from the world. This clearly needs more  
> discussion in the draft.
>
> Henning
>
> Jonathan Rosenberg wrote:
>
>> This is a very interesting draft. This kind of presence-based  
>> reputation system is definitely a strong contender for a piece of  
>> the anti-spam puzzle.
>> Building a protocol to do this is very challenging. One of the  
>> design decisions is whether or not it is pushed based, akin to a  
>> vector routing protocl (as you have proposed) or whether it is  
>> query-based. I am concerned that a push-based routing protocol  
>> type of solution is simply not going to scale, as the level of  
>> aggregation will not be sufficient. Though there is a form of  
>> aggregation, in terms of combining paths to the same recipient,  
>> there is no way to aggregate decisions across recipients. The  
>> latter is analagous to combining prefixes in BGP, and that is not  
>> possible here since the identifiers are from a flat namespace.
>> Furthermore, I may not want to reveal all of my trust  
>> relationships to everyone, indeed, I may not want to reveal the  
>> same trust relationships to different people. Consider this  
>> example. I have a buddy list with lots of buddies on it. Those  
>> buddies include colleagues from work, family, and certain business  
>> associates that I deal with, but confidentially (example: the  
>> business development manager from a company about to acquire my  
>> company). I don't want everyone I trust to actually know that I  
>> trust this biz dev guy, since that reveals confidential information.
>> Because of this, I think that these trust chains need to be query  
>> based. Indeed, care must be taken to make sure the privacy issues  
>> I mention above can be dealt with. Indeed, if you allow transitive  
>> queries - user A queries B that queries C, it can get really hard  
>> to preserve the privacy needed.
>> Thanks,
>> Jonathan R.
>>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 01 04:26:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVch-0006is-Q3; Mon, 01 Aug 2005 04:26:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1DzVcf-0006il-Sq
	for simple@megatron.ietf.org; Mon, 01 Aug 2005 04:26:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05056
	for <simple@ietf.org>; Mon, 1 Aug 2005 04:26:08 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzW8u-0003sa-6e
	for simple@ietf.org; Mon, 01 Aug 2005 04:59:29 -0400
Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j718Pssw010859
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 1 Aug 2005 04:25:57 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j718Pp67010207;
	Mon, 1 Aug 2005 04:25:51 -0400
Message-ID: <42EDDC95.9050301@cs.columbia.edu>
Date: Mon, 01 Aug 2005 04:25:57 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: oran@cisco.com
Subject: Re: [Simple] New draft on trust_path_discovery
References: <B0C588289108FAono.kumiko@lab.ntt.co.jp>
	<42E5597B.8030003@cisco.com> <42E59B17.2080808@cs.columbia.edu>
	<5E98F2A2-E498-413A-8612-9AFC4B25B10C@cisco.com>
In-Reply-To: <5E98F2A2-E498-413A-8612-9AFC4B25B10C@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_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Cc: kumiko@cs.columbia.edu, Kumiko Ono <ono.kumiko@lab.ntt.co.jp>,
	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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

> OTOH rapid revocation of trust when somebody on the trust chain gets  
> indicted may be as bad rapid route withdrawal globally in BGP.

Agreed; but unless you hang out with CEOs of companies specializing in 
communications or health care (or the local branch of the Cosa Nostra), 
indictments of friends are hopefully rare event. Thus, the facility of 
rapid withdrawal must be there, but seems unlikely to add much traffic.

Henning

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 01 04:43:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVtS-0002x2-El; Mon, 01 Aug 2005 04:43:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzVtR-0002vR-2B; Mon, 01 Aug 2005 04:43:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05755;
	Mon, 1 Aug 2005 04:43:27 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DzWPg-0004dl-7a; Mon, 01 Aug 2005 05:16:48 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 10:43:14 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com
	[144.254.231.87])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j718gHEA029511; 
	Mon, 1 Aug 2005 10:43:11 +0200 (MEST)
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by
	xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); 
	Mon, 1 Aug 2005 10:43:03 +0200
Received: from [86.255.25.104] ([10.58.48.83]) by xfe-ams-332.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 10:43:02 +0200
Message-ID: <42EDE096.2090406@cisco.com>
Date: Mon, 01 Aug 2005 04:43:02 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Urpalainen <jari.urpalainen@nokia.com>
Subject: Re: [Simple] Presence Relax NG schemas
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>	
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
In-Reply-To: <1122883119.8484.40.camel@hed034-145.research.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Aug 2005 08:43:02.0645 (UTC)
	FILETIME=[07391A50:01C59675]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
Cc: Simple WG <simple@ietf.org>, xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Jari Urpalainen wrote:

> On Sun, 2005-07-31 at 10:22 -0400, ext Jonathan Rosenberg wrote:
> 
>>I don't have any particular views on the pros/cons of XML schema vs. 
>>relax NG. However, my concern about this is whether there is value in 
>>having TWO definitions of the grammar for these documents. It seems that 
>>this is a recipe for interoperability problems. An XML-schema-using 
>>implementation might define a document that is valid according to the 
>>schema, but invalid according to the RELAX-NG definition. That would be 
>>a problem. If that never happens, and neither can the converse (a 
>>RELAX-NG compliant document that is not schema compliant), then the 
>>RELAX-NG description is isomorphic to the XML schema, and so what is the 
>>value exactly?
>>
>>-Jonathan R.
> 
> I'll agree that it is not definitely an optimal solution to have two
> definitions. Anyway, as you know, with the current W3C schemas you
> cannot express where to put e.g. some extension elements when there are
> many possible extension points: you could add e.g. <dm:person> element
> under <presence>, <tuple> and <status>. And once you add new schemas
> extension points just increase. However, these Relax NG schemas do not
> allow this ambiguity. So they follow more strictly the intention of the
> specs. Of course if these schemas don't correctly follow the specs, I am
> glad to receive fixes.
> 
> Secondly, I am aware that ietf/xml-dev had these schema tool discussions
> awhile back ago. AFAIK the recommendation does not mandate to use only
> W3C schemas, it just seems to be the prevailing habit. At least in this
> particular case Relax NG fits better for the task, imo.

Sure, working groups should always be able to discuss XML schema vs. 
RELAX vs. DTD. However, that discussion is appropriate in the beginning 
of the cycle. The group has already chosen XML schema, and I don't 
believe you are proposing to change that decision. As such, I think its 
far more important to have a single definition of the grammar.


> As Aki notes, SIMPLEt might be the best "home" for this, but the schemas
> have to be available somewhere (and bug free) 

XML schema definitions, sure, the IANA registry will provide that for 
us. I am concerned about having any home for a second, independent 
definition of the grammar.

-Jonathan R.
-- 
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 Mon Aug 01 16:12:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzge5-0006t8-7v; Mon, 01 Aug 2005 16:12:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzge2-0006qh-Jc; Mon, 01 Aug 2005 16:12:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12476;
	Mon, 1 Aug 2005 16:12:16 -0400 (EDT)
Received: from zak.ecotroph.net ([216.93.167.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DzhAN-0004rq-0v; Mon, 01 Aug 2005 16:45:44 -0400
Received: from [86.255.16.43] ([::ffff:86.255.16.43])
	(AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA)
	by zak.ecotroph.net with esmtp; Mon, 01 Aug 2005 16:12:06 -0400
	id 0016035B.42EE8216.0000308E
In-Reply-To: <01LRBBOCHK6S000091@mauve.mrochek.com>
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4B8429D2-EFAD-4E44-B905-0811192DCD65@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
Date: Mon, 1 Aug 2005 16:12:03 -0400
To: Ned Freed <ned.freed@mrochek.com>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Aug 1, 2005, at 3:33 PM, Ned Freed wrote:

> I guess having more than one defintion is OK as long as only one of  
> them is
> considered to be normative.

I agree with this.  If somebody is using an informative schema for  
validation purposes, it is probably better they use one that has been  
reviewed rather than one they derive privately.

> There's some similarity between this issue and the issue of  
> recasting existing
> data formats in XML. It may make sense to define, say, an XML  
> variant of the
> iCalendar format, but unless a wholesale migration to the XML  
> format is planned the original format needs to be the normative  
> one. Imposing additional
> constraints, or worse, adding extensions in a secondary format is a  
> really
> bad idea IMO.

Though I don't view it this way.  I view it as there are multiple  
ways to describe valid XML for a particular application but they all  
describe the same XML.

-andy

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 01 17:45:39 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzi6N-0002Oo-5o; Mon, 01 Aug 2005 17:45:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzi6L-0002OK-Lg; Mon, 01 Aug 2005 17:45:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24840;
	Mon, 1 Aug 2005 17:45:35 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dzich-0002vh-Hk; Mon, 01 Aug 2005 18:19:03 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 23:45:28 +0200
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	j71LjODg027500; Mon, 1 Aug 2005 23:45:24 +0200 (MEST)
Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by
	xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 1 Aug 2005 23:45:23 +0200
Received: from [86.255.17.86] ([10.58.48.12]) by xfe-ams-331.emea.cisco.com
	with Microsoft SMTPSVC(6.0.3790.0); Mon, 1 Aug 2005 23:45:23 +0200
Message-ID: <42EE97F1.5080601@cisco.com>
Date: Mon, 01 Aug 2005 17:45:21 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
In-Reply-To: <01LRBBOCHK6S000091@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Aug 2005 21:45:23.0624 (UTC)
	FILETIME=[523A1280:01C596E2]
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Ned Freed wrote:

>> > I'll agree that it is not definitely an optimal solution to have two
>> > definitions. Anyway, as you know, with the current W3C schemas you
>> > cannot express where to put e.g. some extension elements when there are
>> > many possible extension points: you could add e.g. <dm:person> element
>> > under <presence>, <tuple> and <status>. And once you add new schemas
>> > extension points just increase. However, these Relax NG schemas do not
>> > allow this ambiguity. So they follow more strictly the intention of the
>> > specs. Of course if these schemas don't correctly follow the specs, 
>> I am
>> > glad to receive fixes.
> 
> 
>> > Secondly, I am aware that ietf/xml-dev had these schema tool 
>> discussions
>> > awhile back ago. AFAIK the recommendation does not mandate to use only
>> > W3C schemas, it just seems to be the prevailing habit. At least in this
>> > particular case Relax NG fits better for the task, imo.
> 
> 
>> Sure, working groups should always be able to discuss XML schema vs.
>> RELAX vs. DTD. However, that discussion is appropriate in the beginning
>> of the cycle. The group has already chosen XML schema, and I don't
>> believe you are proposing to change that decision. As such, I think its
>> far more important to have a single definition of the grammar.
> 
> 
> I'm afraid I have to agree with Jonathan here. I don't especially care what
> definition tool is used (although I like it when one is used...), but using
> more than one could lead to all sorts of unnecessary excitement. I 
> personally
> haven't used Relax NG for much, but I use both DTDs and Schemata all the 
> time
> and the overlaps between the two can be... well, interesting.
> 
> I guess having more than one defintion is OK as long as only one of them is
> considered to be normative.

What is it mean for a grammar definition to be informative though? If 
its used in any way at all, its for validation of message content, and 
that fundamentally leads to the interoperability problems I'm talking 
about above.

> 
> There's some similarity between this issue and the issue of recasting 
> existing
> data formats in XML. It may make sense to define, say, an XML variant of 
> the
> iCalendar format, but unless a wholesale migration to the XML format is 
> planned the original format needs to be the normative one.

I think thats different though. The XML version of iCal is a different 
document than the existing one. When you receive a calendar document, 
there is no confusion about which grammar it complies to. Its either 
XML, or its not. Here, we're talking about the same document, but with 
two different syntaxes that define the rules for its construction. There 
is no way from looking at the document to know which it was actually 
created from and validated against.

-Jonathan R.

-- 
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 Tue Aug 02 02:56:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzqhh-00048E-8D; Tue, 02 Aug 2005 02:56:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1Dzqhe-000403-SP; Tue, 02 Aug 2005 02:56:43 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24627;
	Tue, 2 Aug 2005 02:56:38 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1DzrE1-0006O0-Ut; Tue, 02 Aug 2005 03:30:11 -0400
Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j726uYsw019628
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 2 Aug 2005 02:56:34 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j726uVWD016702;
	Tue, 2 Aug 2005 02:56:32 -0400
Message-ID: <42EF1926.8020902@cs.columbia.edu>
Date: Tue, 02 Aug 2005 02:56:38 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>	<42ECDEBF.9080502@cisco.com>	<1122883119.8484.40.camel@hed034-145.research.nokia.com>	<42EDE096.2090406@cisco.com>
	<01LRBBOCHK6S000091@mauve.mrochek.com> <42EE97F1.5080601@cisco.com>
In-Reply-To: <42EE97F1.5080601@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_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Would the following requirements solve the problem:

(1) All documents MUST comply with the relevant schema definitions (and 
the non-schema constraints in the normative documents);

(2) Senders MAY also verify that their document passes the Relax NG 
test. It captures some of the non-schema constraints.

(3) Receivers SHOULD accept any schema-compliant document.

If these steps are followed, senders may be more strict in sending than 
the schema indicates, but there is no danger of emitting a non-compliant 
document. Step (3) is a version of what we discussed, namely the "be 
liberal in what you accept". (Obviously, many of the likely violations, 
such as use of elements in the wrong encapsulating element, will not be 
processed at all, but just be ignored since the receiver won't look for 
them.)

Henning

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 03 05:19:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0FPK-0002HV-EJ; Wed, 03 Aug 2005 05:19:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0FPE-0002EN-VO; Wed, 03 Aug 2005 05:19:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27448;
	Wed, 3 Aug 2005 05:19:18 -0400 (EDT)
Received: from ams-iport-1.cisco.com ([144.254.224.140])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E0Fvs-0005YH-Q9; Wed, 03 Aug 2005 05:53:06 -0400
Received: from ams-core-1.cisco.com (144.254.224.150)
	by ams-iport-1.cisco.com with ESMTP; 03 Aug 2005 11:19:11 +0200
Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71])
	by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	j739ILEI026905; Wed, 3 Aug 2005 11:19:07 +0200 (MEST)
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by
	xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 3 Aug 2005 11:18:35 +0200
Received: from [86.255.27.246] ([10.58.48.82]) by xfe-ams-332.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 11:18:35 +0200
Message-ID: <42F08BEA.4070900@cisco.com>
Date: Wed, 03 Aug 2005 05:18:34 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>	<42ECDEBF.9080502@cisco.com>	<1122883119.8484.40.camel@hed034-145.research.nokia.com>	<42EDE096.2090406@cisco.com>
	<01LRBBOCHK6S000091@mauve.mrochek.com>
	<42EE97F1.5080601@cisco.com> <42EF1926.8020902@cs.columbia.edu>
In-Reply-To: <42EF1926.8020902@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Aug 2005 09:18:35.0083 (UTC)
	FILETIME=[5314D1B0:01C5980C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This captures the spirit of we want, I think. My concern is simply that, 
in practice, having two definitions that specify the grammar for the 
same document might cause interop problems:

   a. there are subtle differences in the schemas, not noticed during 
the design, that result in a mismatch in compliance - that is, a 
document is compliant to the XML schema but NOT the relax-ng definition. 
It seems hard to PROVE that this cannot happen...

   b. folks who really like one type of schema definition over the other 
(i.e., really like relax-ng over schema), decide to ignore the advice 
below, and use the informational schema for validating documents received

To be really clear, I have no problem with relax-ng. I trust experts in 
this space who say its better. My concern is having TWO specs that 
define the grammar for a single document, whatever those schemas are.

-Jonathan R.

Henning Schulzrinne wrote:

> Would the following requirements solve the problem:
> 
> (1) All documents MUST comply with the relevant schema definitions (and 
> the non-schema constraints in the normative documents);
> 
> (2) Senders MAY also verify that their document passes the Relax NG 
> test. It captures some of the non-schema constraints.
> 
> (3) Receivers SHOULD accept any schema-compliant document.
> 
> If these steps are followed, senders may be more strict in sending than 
> the schema indicates, but there is no danger of emitting a non-compliant 
> document. Step (3) is a version of what we discussed, namely the "be 
> liberal in what you accept". (Obviously, many of the likely violations, 
> such as use of elements in the wrong encapsulating element, will not be 
> processed at all, but just be ignored since the receiver won't look for 
> them.)
> 
> Henning
> 

-- 
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 Aug 03 05:29:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0FYq-0007x0-MH; Wed, 03 Aug 2005 05:29:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0FYn-0007uH-JN; Wed, 03 Aug 2005 05:29:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28352;
	Wed, 3 Aug 2005 05:29:11 -0400 (EDT)
Received: from cs.columbia.edu ([128.59.16.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E0G5P-000601-Kl; Wed, 03 Aug 2005 06:02:58 -0400
Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8])
	by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j739T6sw023834
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 3 Aug 2005 05:29:06 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by razor.cs.columbia.edu (8.12.11/8.12.11) with ESMTP id j739T3x4025934;
	Wed, 3 Aug 2005 05:29:04 -0400
Message-ID: <42F08E67.80609@cs.columbia.edu>
Date: Wed, 03 Aug 2005 05:29:11 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>	<42ECDEBF.9080502@cisco.com>	<1122883119.8484.40.camel@hed034-145.research.nokia.com>	<42EDE096.2090406@cisco.com>	<01LRBBOCHK6S000091@mauve.mrochek.com>	<42EE97F1.5080601@cisco.com>
	<42EF1926.8020902@cs.columbia.edu> <42F08BEA.4070900@cisco.com>
In-Reply-To: <42F08BEA.4070900@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_TEXT_ONLY 0,
	__MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0'
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

>   a. there are subtle differences in the schemas, not noticed during the 
> design, that result in a mismatch in compliance - that is, a document is 
> compliant to the XML schema but NOT the relax-ng definition. It seems 
> hard to PROVE that this cannot happen...

Agreed - but I believe that the "algorithm" I proposed will make this 
problem harmless. Implementors using only the schema are no worse off, 
but those doing the additional checking won't generate such documents.

> 
>   b. folks who really like one type of schema definition over the other 
> (i.e., really like relax-ng over schema), decide to ignore the advice 
> below, and use the informational schema for validating documents received

These same folks probably code from the examples in the draft and think 
that schema verification is for wimps. I don't think we can help 
maliciously lazy implementors but shouldn't penalize the conscientious ones.


> 
> To be really clear, I have no problem with relax-ng. I trust experts in 
> this space who say its better. My concern is having TWO specs that 
> define the grammar for a single document, whatever those schemas are.

There are trade-offs, but given the limitations of what we have to deal 
with, I'm hopeful that this will, in this case, the average outcome will 
be better than not having this. In addition, I suspect that, in 
practice, any discrepancies will be discovered very quickly, 
particularly those where the Relax-NG scheme is more liberal (which is 
the only harmful case).

Henning

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 03 06:18:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0GK3-0002pe-13; Wed, 03 Aug 2005 06:18:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GK0-0002pW-JJ
	for simple@megatron.ietf.org; Wed, 03 Aug 2005 06:18:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02102
	for <simple@ietf.org>; Wed, 3 Aug 2005 06:17:58 -0400 (EDT)
Received: from hq-smtp-01.telio.no ([82.196.203.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Gqe-0008In-N9
	for simple@ietf.org; Wed, 03 Aug 2005 06:51:46 -0400
Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119])
	by hq-smtp-01.telio.no (Postfix) with ESMTP id B3142194449
	for <simple@ietf.org>; Wed,  3 Aug 2005 12:17:40 +0200 (CEST)
Received: from [86.255.24.173] ([86.255.24.173]) by office-owa-01.HQ.TELIO.NO
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 3 Aug 2005 12:23:15 +0200
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <a64b3057c90e69fffba79ede41deefb2@telio.no>
Content-Type: text/plain; charset=US-ASCII; format=flowed
To: "simple@ietf.org WG" <simple@ietf.org>
From: Hisham Khartabil <hisham.khartabil@telio.no>
Date: Wed, 3 Aug 2005 12:17:39 +0200
X-Mailer: Apple Mail (2.622)
X-OriginalArrivalTime: 03 Aug 2005 10:23:15.0641 (UTC)
	FILETIME=[5C12FA90:01C59815]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Content-Transfer-Encoding: 7bit
Subject: [Simple] Agenda
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

You will find the latest agenda at

http://www.softarmor.com/simple/meets/ietf63/agenda.html

Presentations slides will be added as they are delivered to me.

Thanks,
Hisham


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

From pwe3-bounces@ietf.org Wed Aug 03 06:17:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0GJF-0002eI-Pz; Wed, 03 Aug 2005 06:17:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GJB-0002bl-DC
	for pwe3@megatron.ietf.org; Wed, 03 Aug 2005 06:17:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02081
	for <pwe3@ietf.org>; Wed, 3 Aug 2005 06:17:07 -0400 (EDT)
Received: from tlv1.axerra.com ([80.74.100.68])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Gpq-0008FN-Py
	for pwe3@ietf.org; Wed, 03 Aug 2005 06:50:55 -0400
Received: by TLV1 with Internet Mail Service (5.5.2653.19)
	id <P6WC5CGM>; Wed, 3 Aug 2005 13:17:17 +0300
Message-ID: <AF5018AC03D1D411ABB70002A5091326025B6324@TLV1>
From: Sasha Vainshtein <Sasha@AXERRA.com>
To: "'chmetz@cisco.com'" <chmetz@cisco.com>
Date: Wed, 3 Aug 2005 13:17:16 +0300 
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: 68c8cc8a64a9d0402e43b8eee9fc4199
Cc: "'pwe3@ietf.org'" <pwe3@ietf.org>
Subject: [PWE3] IANA Consideration in draft-metz-aii-aggregate-00 
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org

Chris and all,
Sorry for misplacing my comment at the PWE3 session today.

Howeve, the substance is still there: the IANA Considerations section'of the
draft in question requests 3 new AII types but only lists 2.

I understand now (from a side discussion) that the original intent was 
to use one more AII type for the PWid/FEC 128 and I think that
it is worth keeping this AII type separate.

Regards,
                       Sasha

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3





From l2vpn-bounces@ietf.org Wed Aug 03 06:15:43 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0GHn-000218-6f; Wed, 03 Aug 2005 06:15:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GHl-000213-TK
	for l2vpn@megatron.ietf.org; Wed, 03 Aug 2005 06:15:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02035
	for <l2vpn@ietf.org>; Wed, 3 Aug 2005 06:15:39 -0400 (EDT)
Received: from radmail2.rad.co.il ([80.74.100.136] helo=antivir1.rad.co.il)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GoP-0008DD-R6
	for l2vpn@ietf.org; Wed, 03 Aug 2005 06:49:27 -0400
Received: from antivir1.rad.co.il (localhost [127.0.0.1])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73ADF3O000373
	for <l2vpn@ietf.org>; Wed, 3 Aug 2005 13:13:16 +0300 (IDT)
Received: from exrad2.ad.rad.co.il (exrad2 [192.114.24.112])
	by antivir1.rad.co.il (8.12.10/8.12.10) with ESMTP id j73ADEgd000364;
	Wed, 3 Aug 2005 13:13:14 +0300 (IDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 3 Aug 2005 13:16:03 +0200
Message-ID: <27A0F290348F8E45AEF79889DDE65A5205219C1E@exrad2.ad.rad.co.il>
Thread-Topic: A comment on draft-stein-ldp-auto-00.txt
Thread-Index: AcWYG4DlOgCsQhkPR7qvi/KOZ11iqwAACWpA
From: "Yaakov Stein" <yaakov_s@rad.com>
To: "Sasha Vainshtein" <Sasha@AXERRA.com>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Content-Transfer-Encoding: quoted-printable
Cc: l2vpn@ietf.org
Subject: RE: A comment on draft-stein-ldp-auto-00.txt
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l2vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>,
	<mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>,
	<mailto:l2vpn-request@ietf.org?subject=subscribe>
Sender: l2vpn-bounces@ietf.org
Errors-To: l2vpn-bounces@ietf.org

Sasha,=20

> IMO, sending a Label Mapping message with the appropriate FEC=20
> 129 to exactly the same set of adjacencies would suffice:
> - adjacencies that participate in the VPLS intstance defined by this
>   FEC would respond with their own Label Mapping message back
> - adjacencies that do NOT participate in the VPLS instance defined
>   by this FEC would respond with the Label Release message using
>   the LDP Status Code "Unassigned/Unrecognized TAI" as defined
>   in Section 5.3.3 of the current PWE3 control protocol draft
>   (draft-ietf-pwe3-control-protocol-17.txt).

Yes, this is one of the alternatives we considered.

Although it re-uses a TLV, it requires a procedure change,
which I am not sure is better.=20

Right now when an LDP peer receives a mapping
it may liberally retain it even though it has no use for it.
There certainly is no procedure for conditioning acceptance
on information maintained in a table.

In addition, in the naive way of doing this it would
require propagation of the label mapping into whole domains
where I don't (access networks where there are no PEs
belonging to the VPLS instance). Yes this could also be fixed
by having the S-PE snoop the mapping message, but then
it would have to process every LDP packet (even non-VPLS
joining ones) in this fashion.=20

Finally, PEs that are not VPLS-aware will mis-handle the mapping
request. In our case PEs that do not handle VPLS will silently
ignore the message.

>=20
> Please note that the information carried in the proposed Join=20
> message does not differ from one carried in the already=20
> defined FEC 129.

Yes, this is discussed in the draft.

>=20
> So why such a MAJOR (a new messsage, not just a new TLV!)=20
> extension to LDP?

I do not see a major advantage in saving IANA a little bit of  work
in allocating two new TLVs, if we have to overload a lot of logic
on existing ones.

Y(J)S



From simple-bounces@ietf.org Wed Aug 03 09:48:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0Jc8-0002dT-I2; Wed, 03 Aug 2005 09:48:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Jc6-0002dC-4c
	for simple@megatron.ietf.org; Wed, 03 Aug 2005 09:48:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17232
	for <simple@ietf.org>; Wed, 3 Aug 2005 09:48:52 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0K8m-0001yo-Gd
	for simple@ietf.org; Wed, 03 Aug 2005 10:22:41 -0400
Received: by zproxy.gmail.com with SMTP id 12so78007nzp
	for <simple@ietf.org>; Wed, 03 Aug 2005 06:48:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
	b=nOJILTXjjuycn/BQC6eGB7gW9YvIokUAo7bj1nJivb38vQpFc376xG3Nw6bEbvQMcAdL8Mi/lcXVLclgejH3lJCVeI50fk4gt4x3iJmxPaxxu3kiglcRvDLrcmsqUbdLS0TXh3q0ne7yVQwuJlNhMzRM3227Zqn35Xy4POSqpkU=
Received: by 10.36.71.5 with SMTP id t5mr262606nza;
	Wed, 03 Aug 2005 06:48:41 -0700 (PDT)
Received: by 10.36.57.10 with HTTP; Wed, 3 Aug 2005 06:48:41 -0700 (PDT)
Message-ID: <29ac328c050803064835c01b30@mail.gmail.com>
Date: Wed, 3 Aug 2005 21:48:41 +0800
From: destiny <zodist@gmail.com>
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: 7aefe408d50e9c7c47615841cb314bed
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] I want to implement MSRP?
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I want to implement MSRP(message session relay protocol), does there
has a opened source implementation?  or give me some suggestions.
thanks in advanced.

_______________________________
Reply mail in one business day.
Email: zodist@gmail.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 05:02:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0bcG-0007XR-GK; Thu, 04 Aug 2005 05:02:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzgAS-00080H-HX; Mon, 01 Aug 2005 15:41:44 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04594;
	Mon, 1 Aug 2005 15:41:40 -0400 (EDT)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dzggn-0001O7-Ed; Mon, 01 Aug 2005 16:15:09 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LRBAQ4IGF4000091@mauve.mrochek.com>; Mon,
	01 Aug 2005 12:41:27 -0700 (PDT)
To: Jonathan Rosenberg <jdrosen@cisco.com>
Message-id: <01LRBBOCHK6S000091@mauve.mrochek.com>
Date: Mon, 01 Aug 2005 12:33:13 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
In-reply-to: "Your message dated Mon, 01 Aug 2005 04:43:02 -0400"
	<42EDE096.2090406@cisco.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
X-Mailman-Approved-At: Thu, 04 Aug 2005 05:02:14 -0400
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

> > I'll agree that it is not definitely an optimal solution to have two
> > definitions. Anyway, as you know, with the current W3C schemas you
> > cannot express where to put e.g. some extension elements when there are
> > many possible extension points: you could add e.g. <dm:person> element
> > under <presence>, <tuple> and <status>. And once you add new schemas
> > extension points just increase. However, these Relax NG schemas do not
> > allow this ambiguity. So they follow more strictly the intention of the
> > specs. Of course if these schemas don't correctly follow the specs, I am
> > glad to receive fixes.

> > Secondly, I am aware that ietf/xml-dev had these schema tool discussions
> > awhile back ago. AFAIK the recommendation does not mandate to use only
> > W3C schemas, it just seems to be the prevailing habit. At least in this
> > particular case Relax NG fits better for the task, imo.

> Sure, working groups should always be able to discuss XML schema vs.
> RELAX vs. DTD. However, that discussion is appropriate in the beginning
> of the cycle. The group has already chosen XML schema, and I don't
> believe you are proposing to change that decision. As such, I think its
> far more important to have a single definition of the grammar.

I'm afraid I have to agree with Jonathan here. I don't especially care what
definition tool is used (although I like it when one is used...), but using
more than one could lead to all sorts of unnecessary excitement. I personally
haven't used Relax NG for much, but I use both DTDs and Schemata all the time
and the overlaps between the two can be... well, interesting.

I guess having more than one defintion is OK as long as only one of them is
considered to be normative.

There's some similarity between this issue and the issue of recasting existing
data formats in XML. It may make sense to define, say, an XML variant of the
iCalendar format, but unless a wholesale migration to the XML format is planned 
the original format needs to be the normative one. Imposing additional
constraints, or worse, adding extensions in a secondary format is a really
bad idea IMO.

				Ned

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 05:02:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0bcH-0007YO-Ff; Thu, 04 Aug 2005 05:02:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1DzmSj-0001QP-EK; Mon, 01 Aug 2005 22:25:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23672;
	Mon, 1 Aug 2005 22:24:59 -0400 (EDT)
Received: from mauve.mrochek.com ([209.55.107.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1Dzmz5-0004U4-Qa; Mon, 01 Aug 2005 22:58:30 -0400
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243)
	id <01LRBJ583FQO000092@mauve.mrochek.com>; Mon,
	01 Aug 2005 19:24:49 -0700 (PDT)
To: Jonathan Rosenberg <jdrosen@cisco.com>
Message-id: <01LRBPRFZUSU000092@mauve.mrochek.com>
Date: Mon, 01 Aug 2005 19:03:26 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
In-reply-to: "Your message dated Mon, 01 Aug 2005 17:45:21 -0400"
	<42EE97F1.5080601@cisco.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format=flowed
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
	<42EE97F1.5080601@cisco.com>
X-Spam-Score: 2.0 (++)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
X-Mailman-Approved-At: Thu, 04 Aug 2005 05:02:14 -0400
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

> inline.

> Ned Freed wrote:

> >> > I'll agree that it is not definitely an optimal solution to have two
> >> > definitions. Anyway, as you know, with the current W3C schemas you
> >> > cannot express where to put e.g. some extension elements when there are
> >> > many possible extension points: you could add e.g. <dm:person> element
> >> > under <presence>, <tuple> and <status>. And once you add new schemas
> >> > extension points just increase. However, these Relax NG schemas do not
> >> > allow this ambiguity. So they follow more strictly the intention of the
> >> > specs. Of course if these schemas don't correctly follow the specs,
> >> I am
> >> > glad to receive fixes.
> >
> >
> >> > Secondly, I am aware that ietf/xml-dev had these schema tool
> >> discussions
> >> > awhile back ago. AFAIK the recommendation does not mandate to use only
> >> > W3C schemas, it just seems to be the prevailing habit. At least in this
> >> > particular case Relax NG fits better for the task, imo.
> >
> >
> >> Sure, working groups should always be able to discuss XML schema vs.
> >> RELAX vs. DTD. However, that discussion is appropriate in the beginning
> >> of the cycle. The group has already chosen XML schema, and I don't
> >> believe you are proposing to change that decision. As such, I think its
> >> far more important to have a single definition of the grammar.
> >
> >
> > I'm afraid I have to agree with Jonathan here. I don't especially care what
> > definition tool is used (although I like it when one is used...), but using
> > more than one could lead to all sorts of unnecessary excitement. I
> > personally
> > haven't used Relax NG for much, but I use both DTDs and Schemata all the
> > time
> > and the overlaps between the two can be... well, interesting.
> >
> > I guess having more than one defintion is OK as long as only one of them is
> > considered to be normative.

> What is it mean for a grammar definition to be informative though?

It means the definition is provided for convenience only, it cannot
be used to determine compliance (or lack thereof).

> If
> its used in any way at all, its for validation of message content, and
> that fundamentally leads to the interoperability problems I'm talking
> about above.

We see this sort of thing all the time with language compilers. It is
common for such tools to perform checks that are simultaneously less and more
stringent than the language standard requires. As long as the compiler doesn't
call any more stringent checks it performs an error there isn't a problem.

> > There's some similarity between this issue and the issue of recasting
> > existing
> > data formats in XML. It may make sense to define, say, an XML variant of
> > the
> > iCalendar format, but unless a wholesale migration to the XML format is
> > planned the original format needs to be the normative one.

> I think thats different though. The XML version of iCal is a different
> document than the existing one. When you receive a calendar document,
> there is no confusion about which grammar it complies to. Its either
> XML, or its not. Here, we're talking about the same document, but with
> two different syntaxes that define the rules for its construction. There
> is no way from looking at the document to know which it was actually
> created from and validated against.

This is really a matter of intent, isn't it? If the intent in using an
additional specification language is simply to have an alternative in there,
then I see little purpose in it and some potential for harm. (This goes for the
XML variant of iCalendar, BTW.) If, OTOH, the intent is to provide, say, a test
for potentially expensive usage, or some other check for legal but potentially
problematic constructs, I think there could be some utillity in having a second
informative definition. In fact it might even make sense to have two
definitions in the same specification language.

However, I don't believe XML Schema lends itself to this sort of usage. (The
error messages I usually get from schema validators aren't exactly a model of
clarity...) I haven't used Relax NG enough to know if it does or not.

				Ned

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 05:02:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0bcI-0007Zs-DW; Thu, 04 Aug 2005 05:02:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E09G7-0008UB-Vo; Tue, 02 Aug 2005 22:45:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02414;
	Tue, 2 Aug 2005 22:45:28 -0400 (EDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E09mc-0006PL-2t; Tue, 02 Aug 2005 23:19:13 -0400
Received: from esunmail ([129.147.156.34])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j732jIr3005373; 
	Tue, 2 Aug 2005 20:45:18 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
	(iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
	with ESMTP id <0IKM00MYZKZHLY@edgemail1.Central.Sun.COM>; Tue,
	02 Aug 2005 20:45:17 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.202.7])
	by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21
	2004)) with ESMTPSA id <0IKM00KUPKZG2V@mail.sun.net>; Tue,
	02 Aug 2005 20:45:17 -0600 (MDT)
Date: Tue, 02 Aug 2005 11:59:52 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
In-reply-to: <01LRBBOCHK6S000091@mauve.mrochek.com>
To: Ned Freed <ned.freed@mrochek.com>
Message-id: <313EED7A-037F-4A13-81BD-07BAC46FAD0F@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.733)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7BIT
X-Mailman-Approved-At: Thu, 04 Aug 2005 05:02:14 -0400
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Aug 1, 2005, at 12:33 PM, Ned Freed wrote:

> I'm afraid I have to agree with Jonathan here. I don't especially  
> care what
> definition tool is used (although I like it when one is used...),  
> but using
> more than one could lead to all sorts of unnecessary excitement. I  
> personally
> haven't used Relax NG for much, but I use both DTDs and Schemata  
> all the time
> and the overlaps between the two can be... well, interesting.

The Atompub group, which I co-chair, is in the late stages of the  
IESG approval process for a document that includes a non-normative  
schema, provided in RelaxNG (the RNC compact format, to be precise).   
The XML expertise in this WG is substantial, and RelaxNG was chosen  
on that basis.  I think the following are material to this discussion:

- Many people in the XML community - I hesitate to say consensus, but  
would claim at least a plurality - feel that RNG is substantially  
technically superior to both DTDs and W3C XML Schemas.  DTDs are  
reasonably sound as far as they go, but that's not very far, and they  
are very deeply rooted in document-publishing applications.  W3C XML  
Schema is a profoundly bad design which exhibits very poor  
comprehensibility and interoperability.  It has become a boring non- 
event on the various XML-geek mailing lists for someone to want to do  
something fairly obvious in a language and be told "You can't do that  
in XML Schema, but here's a 5-line RelaxNG idiom that does it cleanly  
and exactly."
- There is an excellent open-source tool, trang, that converts  
reasonably well between DTDs, Relax, and XML Schema.  People who use  
this typically use the Relax as the primary format since it's  
simultaneously richer and simpler.  There is a problem in that many  
useful specifications fail to meet XML Schema's idiotic UPA  
requirements, and many designers refuse to cripple their designs to  
do so, so in fact many highly implementable languages simply cannot  
be expressed in XML Schema.

  -Tim



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 05:02:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0bcJ-0007bK-66; Thu, 04 Aug 2005 05:02:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0HjZ-0000MC-A0; Wed, 03 Aug 2005 07:48:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07497;
	Wed, 3 Aug 2005 07:48:28 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E0IG6-00045m-4J; Wed, 03 Aug 2005 08:22:12 -0400
Received: from esunmail ([129.147.156.34])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j73BmAvU004756; 
	Wed, 3 Aug 2005 05:48:10 -0600 (MDT)
Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM
	(iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004))
	with ESMTP id <0IKN00M1OA49LY@edgemail1.Central.Sun.COM>; Wed,
	03 Aug 2005 05:48:10 -0600 (MDT)
Received: from [192.168.1.100] ([216.113.202.7])
	by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21
	2004)) with ESMTPSA id <0IKN003XYA48YW@mail.sun.net>; Wed,
	03 Aug 2005 05:48:09 -0600 (MDT)
Date: Wed, 03 Aug 2005 04:48:24 -0700
From: Tim Bray <tbray@textuality.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
In-reply-to: <42EF1926.8020902@cs.columbia.edu>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Message-id: <4E41E432-C664-44E2-ABCD-BE1A45B54A9C@textuality.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.733)
Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Content-transfer-encoding: 7BIT
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
	<42EE97F1.5080601@cisco.com> <42EF1926.8020902@cs.columbia.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7BIT
X-Mailman-Approved-At: Thu, 04 Aug 2005 05:02:14 -0400
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Aug 1, 2005, at 11:56 PM, Henning Schulzrinne wrote:

> (3) Receivers SHOULD accept any schema-compliant document.

If you're talking about Presence, maybe.  In the general case, NO.   
It is common for languages to have validity requirements that cannot  
be expressed in a schema.  A trivial example: an IP address might  
appear as an element in a document, and the governing specification  
might state that the server at that address SHOULD be responsive to  
messages of type X on port Y.  Go schema that.  -Tim


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 08:31:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0esq-0005h6-1Q; Thu, 04 Aug 2005 08:31:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0eso-0005cw-Hu
	for simple@megatron.ietf.org; Thu, 04 Aug 2005 08:31:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01562
	for <simple@ietf.org>; Thu, 4 Aug 2005 08:31:33 -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.43) id 1E0fPg-0008BX-MQ
	for simple@ietf.org; Thu, 04 Aug 2005 09:05:34 -0400
Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j74CVGTr032002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <simple@ietf.org>; Thu, 4 Aug 2005 07:31:18 -0500 (CDT)
	(envelope-from adam@nostrum.com)
Message-ID: <42F20A82.2050607@nostrum.com>
Date: Thu, 04 Aug 2005 07:30:58 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'simple@ietf.org'" <simple@ietf.org>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 08e48e05374109708c00c6208b534009
Content-Transfer-Encoding: 7bit
Subject: [Simple] MSRP: Authentication and Relays
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

To make sure everyone is aware: the most recent draft of the MSRP relay 
draft defines Digest authentication instead of Basic authentication, and 
has a discussion of the security properties that arise from this change.

If you have any interest in this topic, please go read 
draft-ietf-simple-msrp-relays-05 and make comments as necessary.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 04 10:29:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E0gjA-00059y-46; Thu, 04 Aug 2005 10:29:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E0gj8-00059r-Bm
	for simple@megatron.ietf.org; Thu, 04 Aug 2005 10:29:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15178
	for <simple@ietf.org>; Thu, 4 Aug 2005 10:29:40 -0400 (EDT)
Received: from dsl-217-155-137-62.zen.co.uk ([217.155.137.62]
	helo=gw2.gestalt.entity.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0hG1-0005Do-FJ
	for simple@ietf.org; Thu, 04 Aug 2005 11:03:42 -0400
Received: from invsysm1 (open-30-14.ietf63.ietf.org [86.255.30.14])
	by gw2.gestalt.entity.net (Postfix) with ESMTP id 22AA115400D;
	Thu,  4 Aug 2005 14:29:06 +0000 (UTC)
Date: Thu, 04 Aug 2005 15:29:05 +0100
Subject: Re: [Simple] MSRP: Authentication and Relays
References: <42F20A82.2050607@nostrum.com>
In-Reply-To: <42F20A82.2050607@nostrum.com>
MIME-Version: 1.0
Message-Id: <16901.1123165745.953185@invsysm1>
From: Dave Cridland <dave@cridland.net>
To: Adam Roach <adam@nostrum.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Cc: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Thu Aug  4 03:30:58 2005, Adam Roach wrote:
> To make sure everyone is aware: the most recent draft of the MSRP 
> relay draft defines Digest authentication instead of Basic 
> authentication, and has a discussion of the security properties 
> that arise from this change.

FYI, there was lots of concerns raised about DIGEST-MD5 (SASL's 
version of Digest auth) and MD5 based authentication mechanisms in 
general at the IETF, in particular at the Apps open area meeting and 
both the SASL meeting and the Security Area meeting. It would appear 
that usage of both Digest *and* TLS might well be the best way, but 
quite honestly I'm a little unclear on the results of the discussion.

Dave.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 05 13:42:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E16DX-0002Tx-5x; Fri, 05 Aug 2005 13:42:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E16DV-0002Tn-R7
	for simple@megatron.ietf.org; Fri, 05 Aug 2005 13:42:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22977
	for <simple@ietf.org>; Fri, 5 Aug 2005 13:42:42 -0400 (EDT)
Received: from mtarwc.openwave.com ([12.25.200.46] helo=rwc-isa.openwave.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E16ke-0006Ee-0g
	for simple@ietf.org; Fri, 05 Aug 2005 14:17:00 -0400
Received: from rwc-exch-prd2.myopwv.com ([10.16.249.142]) by
	rwc-isa.openwave.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 5 Aug 2005 10:42:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 5 Aug 2005 10:42:26 -0700
Message-ID: <1B8231A47104E04889D95C8019073D1367AC47@rwc-exch-prd2.myopwv.com>
Thread-Topic: Questions on
	http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt
Thread-Index: AcWZ5QsJuMtV4PHzR7+Wl9ji1ttjnA==
From: "Yannis Pavlidis" <yannis.pavlidis@openwave.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 05 Aug 2005 17:42:35.0556 (UTC)
	FILETIME=[10A24E40:01C599E5]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53
Subject: [Simple] Questions on
	http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1317474473=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1317474473==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C599E5.10B1F3C8"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C599E5.10B1F3C8
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

I wanted to make some comments regarding this draft.

=20

1.	It is not clear in this document what the duration should be of
the back end subscriptions placed from the RLS to the Presence
Server(s). In the example while the event list subscription has a
duration of 7200 the back end subscriptions have a duration of 3600.
This will result in wasting resources in the RLS e.g. the event list
subscription will remain active for one more hour while the back end
subscriptions have been terminated. It would be reasonable to assume
that the duration of the back end subscriptions is the same with the
duration of the event list subscription (at least on the establishment
part as a PS may reduce the subscription duration of the back end
subscription). What are your thoughts?
2.	According with the text in section 4.1

	a.	Message flow  7 should not contain a require header as
ed is not a resource list
	b.	Message flow 10 should contain a require header as
adam-friends is a resource list

3.	The example in the draft assumes a co-location of a PS and RLS
server. What happens when in a domain they are separated (a separate RLS
and PS instance)? How is the request for a specific user will go to the
PS (flow 5) and how a request for a resource list will go to the RLS
(flow 9)?

=20

Thanks,

=20

Yannis.


------_=_NextPart_001_01C599E5.10B1F3C8
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:906647260;
	mso-list-type:hybrid;
	mso-list-template-ids:-1921229672 -2053352558 67698713 67698715 =
67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:1.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I wanted to make some comments regarding this =
draft.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<ol style=3D'margin-top:0in' start=3D1 type=3D1>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>It is not clear in =
this
     document what the duration should be of the back end subscriptions =
placed
     from the RLS to the Presence Server(s). In the example while the =
event
     list subscription has a duration of 7200 the back end subscriptions =
have a
     duration of 3600. This will result in wasting resources in the RLS =
e.g. the
     event list subscription will remain active for one more hour while =
the
     back end subscriptions have been terminated. It would be reasonable =
to
     assume that the duration of the back end subscriptions is the same =
with
     the duration of the event list subscription (at least on the =
establishment
     part as a PS may reduce the subscription duration of the back end
     subscription). What are your =
thoughts?<o:p></o:p></span></font></li>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>According with the =
text in
     section 4.1<o:p></o:p></span></font></li>
 <ol style=3D'margin-top:0in' start=3D1 type=3Da>
  <li class=3DMsoNormal style=3D'mso-list:l0 level2 lfo1'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>Message flow &nbsp;7 =
should not
      contain a require header as ed is not a resource =
list<o:p></o:p></span></font></li>
  <li class=3DMsoNormal style=3D'mso-list:l0 level2 lfo1'><font size=3D2 =
face=3DArial><span
      style=3D'font-size:10.0pt;font-family:Arial'>Message flow 10 =
should contain
      a require header as adam-friends is a resource =
list<o:p></o:p></span></font></li>
 </ol>
 <li class=3DMsoNormal style=3D'mso-list:l0 level1 lfo1'><font size=3D2 =
face=3DArial><span
     style=3D'font-size:10.0pt;font-family:Arial'>The example in the =
draft
     assumes a co-location of a PS and RLS server. What happens when in =
a
     domain they are separated (a separate RLS and PS instance)? How is =
the
     request for a specific user will go to the PS (flow 5) and how a =
request
     for a resource list will go to the RLS (flow =
9)?<o:p></o:p></span></font></li>
</ol>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Yannis.<o:p></o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C599E5.10B1F3C8--


--===============1317474473==
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

--===============1317474473==--




From simple-bounces@ietf.org Sun Aug 07 10:19:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E1m0E-00084U-A4; Sun, 07 Aug 2005 10:19:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E1m0C-00084M-F6
	for simple@megatron.ietf.org; Sun, 07 Aug 2005 10:19:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08994
	for <simple@ietf.org>; Sun, 7 Aug 2005 10:19:46 -0400 (EDT)
Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1mXh-0000yg-EG
	for simple@ietf.org; Sun, 07 Aug 2005 10:54:26 -0400
Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net
	[141.153.198.113]) (user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j77EJfNQ016077
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <simple@ietf.org>; Sun, 7 Aug 2005 10:19:42 -0400 (EDT)
Message-ID: <42F61879.1000207@cs.columbia.edu>
Date: Sun, 07 Aug 2005 10:19:37 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: simple@ietf.org
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.8
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Subject: [Simple] tel URIs in 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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

In a side conversation, Hannes suggested a solution to the tel URI 
problem we discussed during the WG meeting, akin to what's done in the 
geopriv coordinate system parameter, namely to have a parameter that 
identifies the scheme, as in

<one scheme="tel" id="+1-212-555-1234"/>

or

<one scheme="sip" id="alice@example.com"/>

if you really only want to match SIP identity sip:alice@example.com.

The default with no scheme parameter is "matches any user@domain scheme".

In order to complete finishing the section of the spec, I'd value quick 
feedback on the idea.

Henning

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Sun Aug 07 19:39:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E1uji-0002Pv-Pi; Sun, 07 Aug 2005 19:39:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E1ujh-0002Pq-Oe
	for simple@megatron.ietf.org; Sun, 07 Aug 2005 19:39:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04401
	for <simple@ietf.org>; Sun, 7 Aug 2005 19:39:18 -0400 (EDT)
Received: from ylpvm15-ext.prodigy.net ([207.115.57.46]
	helo=ylpvm15.prodigy.net) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E1vHH-00054t-MP
	for simple@ietf.org; Sun, 07 Aug 2005 20:14:04 -0400
Received: from pimout7-ext.prodigy.net (pimout7-int.prodigy.net
	[207.115.4.147])
	by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id
	j77NdEaR017349 for <simple@ietf.org>; Sun, 7 Aug 2005 19:39:15 -0400
X-ORBL: [70.249.147.57]
Received: from [192.168.0.102] (ppp-70-249-147-57.dsl.rcsntx.swbell.net
	[70.249.147.57])
	by pimout7-ext.prodigy.net (8.13.4 outbound domainkey aix/8.13.4) with
	ESMTP id j77Nd4ti517550; Sun, 7 Aug 2005 19:39:12 -0400
Message-ID: <42F69C1E.4060607@nostrum.com>
Date: Sun, 07 Aug 2005 18:41:18 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
Subject: Re: [Simple] MSRP: Authentication and Relays
References: <42F20A82.2050607@nostrum.com> <16901.1123165745.953185@invsysm1>
In-Reply-To: <16901.1123165745.953185@invsysm1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
Cc: SIP for Instant Messaging and Presence Leveraging Extensions
	<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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Dave Cridland wrote:

> On Thu Aug  4 03:30:58 2005, Adam Roach wrote:
>
>> To make sure everyone is aware: the most recent draft of the MSRP 
>> relay draft defines Digest authentication instead of Basic 
>> authentication, and has a discussion of the security properties that 
>> arise from this change.
>
>
> FYI, there was lots of concerns raised about DIGEST-MD5 (SASL's 
> version of Digest auth) and MD5 based authentication mechanisms in 
> general at the IETF, in particular at the Apps open area meeting and 
> both the SASL meeting and the Security Area meeting. It would appear 
> that usage of both Digest *and* TLS might well be the best way, but 
> quite honestly I'm a little unclear on the results of the discussion.
>


And that is exactly what is specified in the current draft. Thanks.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Sun Aug 07 21:15:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E1wEQ-0001Kx-BB; Sun, 07 Aug 2005 21:15:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E1wEM-0001Ki-VF
	for simple@megatron.ietf.org; Sun, 07 Aug 2005 21:15:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08564
	for <simple@ietf.org>; Sun, 7 Aug 2005 21:15:03 -0400 (EDT)
Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E1wlw-00078Q-F6
	for simple@ietf.org; Sun, 07 Aug 2005 21:49:48 -0400
Received: from zctwc060.asiapac.nortel.com (zctwc060.asiapac.nortel.com
	[47.153.200.67])
	by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP
	id j781EH108597; Sun, 7 Aug 2005 20:14:17 -0500 (CDT)
Received: by zctwc060.asiapac.nortel.com with Internet Mail Service
	(5.5.2653.19) id <QKQ4YQGW>; Mon, 8 Aug 2005 11:13:46 +1000
Message-ID: <C0FA66CBDDF5D411B82E00508BE3A72211A69704@zctwc059.asiapac.nortel.com>
From: "Martin Thomson" <martin.thomson@nortel.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>, simple@ietf.org
Subject: RE: [Simple] tel URIs in common policy
Date: Mon, 8 Aug 2005 11:13:42 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1260117104=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--===============1260117104==
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C59BB6.6AE1D3A8"

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C59BB6.6AE1D3A8
Content-Type: text/plain

You might want to make the scheme attribute a list:

<one scheme="sip sips mailto impp" id="alice@example.com" />

After all, scheme implies a URI scheme and sip and sips are different
(irrespective of any higher level decisions that may suggest otherwise).  If
you want it simpler, then use a different name.

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
Henning Schulzrinne
Sent: Monday, 8 August 2005 12:20 AM
To: simple@ietf.org
Subject: [Simple] tel URIs in common policy


In a side conversation, Hannes suggested a solution to the tel URI 
problem we discussed during the WG meeting, akin to what's done in the 
geopriv coordinate system parameter, namely to have a parameter that 
identifies the scheme, as in

<one scheme="tel" id="+1-212-555-1234"/>

or

<one scheme="sip" id="alice@example.com"/>

if you really only want to match SIP identity sip:alice@example.com.

The default with no scheme parameter is "matches any user@domain scheme".

In order to complete finishing the section of the spec, I'd value quick 
feedback on the idea.

Henning

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

------_=_NextPart_001_01C59BB6.6AE1D3A8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: [Simple] tel URIs in common policy</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>You might want to make the scheme attribute a =
list:</FONT>
</P>

<P><FONT SIZE=3D2>&lt;one scheme=3D&quot;sip sips mailto impp&quot; =
id=3D&quot;alice@example.com&quot; /&gt;</FONT>
</P>

<P><FONT SIZE=3D2>After all, scheme implies a URI scheme and sip and =
sips are different (irrespective of any higher level decisions that may =
suggest otherwise).&nbsp; If you want it simpler, then use a different =
name.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: simple-bounces@ietf.org [<A =
HREF=3D"mailto:simple-bounces@ietf.org">mailto:simple-bounces@ietf.org</=
A>] On Behalf Of Henning Schulzrinne</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, 8 August 2005 12:20 AM</FONT>
<BR><FONT SIZE=3D2>To: simple@ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: [Simple] tel URIs in common policy</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>In a side conversation, Hannes suggested a solution =
to the tel URI </FONT>
<BR><FONT SIZE=3D2>problem we discussed during the WG meeting, akin to =
what's done in the </FONT>
<BR><FONT SIZE=3D2>geopriv coordinate system parameter, namely to have =
a parameter that </FONT>
<BR><FONT SIZE=3D2>identifies the scheme, as in</FONT>
</P>

<P><FONT SIZE=3D2>&lt;one scheme=3D&quot;tel&quot; =
id=3D&quot;+1-212-555-1234&quot;/&gt;</FONT>
</P>

<P><FONT SIZE=3D2>or</FONT>
</P>

<P><FONT SIZE=3D2>&lt;one scheme=3D&quot;sip&quot; =
id=3D&quot;alice@example.com&quot;/&gt;</FONT>
</P>

<P><FONT SIZE=3D2>if you really only want to match SIP identity =
sip:alice@example.com.</FONT>
</P>

<P><FONT SIZE=3D2>The default with no scheme parameter is &quot;matches =
any user@domain scheme&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>In order to complete finishing the section of the =
spec, I'd value quick </FONT>
<BR><FONT SIZE=3D2>feedback on the idea.</FONT>
</P>

<P><FONT SIZE=3D2>Henning</FONT>
</P>

<P><FONT =
SIZE=3D2>_______________________________________________</FONT>
<BR><FONT SIZE=3D2>Simple mailing list</FONT>
<BR><FONT SIZE=3D2>Simple@ietf.org</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/simple" =
TARGET=3D"_blank">https://www1.ietf.org/mailman/listinfo/simple</A></FON=
T>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C59BB6.6AE1D3A8--


--===============1260117104==
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

--===============1260117104==--




From simple-bounces@ietf.org Mon Aug 08 03:36:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E22Be-0002C2-FL; Mon, 08 Aug 2005 03:36:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E22Bc-0002Bv-HD
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 03:36:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05257
	for <simple@ietf.org>; Mon, 8 Aug 2005 03:36:38 -0400 (EDT)
Received: from brinza.cc.columbia.edu ([128.59.29.8] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E22jG-0006zN-MI
	for simple@ietf.org; Mon, 08 Aug 2005 04:11:27 -0400
Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net
	[141.153.198.113]) (user=hgs10 mech=PLAIN bits=0)
	by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j787aZHq011381
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Mon, 8 Aug 2005 03:36:36 -0400 (EDT)
Message-ID: <42F70B5A.4010800@cs.columbia.edu>
Date: Mon, 08 Aug 2005 03:35:54 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@nortel.com>
Subject: Re: [Simple] tel URIs in common policy
References: <C0FA66CBDDF5D411B82E00508BE3A72211A69704@zctwc059.asiapac.nortel.com>
In-Reply-To: <C0FA66CBDDF5D411B82E00508BE3A72211A69704@zctwc059.asiapac.nortel.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.8
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Martin Thomson wrote:
> You might want to make the scheme attribute a list:
> 
> <one scheme="sip sips mailto impp" id="alice@example.com" />
> 
> After all, scheme implies a URI scheme and sip and sips are different 
> (irrespective of any higher level decisions that may suggest 
> otherwise).  If you want it simpler, then use a different name.

Yes, that was the intent. I'm doubtful of the utility of distinguishing 
sip and sips, but that's a separate issue.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 08 06:27:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E24qX-0004BN-03; Mon, 08 Aug 2005 06:27:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E24qU-0004B4-QH
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 06:27:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11494
	for <simple@ietf.org>; Mon, 8 Aug 2005 06:27:00 -0400 (EDT)
From: Martin.Hynar@tietoenator.com
Received: from ebb04.tietoenator.com ([194.142.141.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E25OA-0002y4-Vv
	for simple@ietf.org; Mon, 08 Aug 2005 07:01:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 8 Aug 2005 12:25:53 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F729@carrera.eu.tieto.com>
Thread-Topic: SIP multisubscription
Thread-Index: AcWcA44kHPfZTrP3To62YTp26Gmg+A==
To: <simple@ietf.org>
X-OriginalArrivalTime: 08 Aug 2005 10:25:55.0042 (UTC)
	FILETIME=[8F266420:01C59C03]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] SIP multisubscription
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi all,

because of some misunderstandings in handling of multisubscription there =
becomes a need to some discussion.

What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE =
request from the client side that does not specify document parameter in =
its Event header. The request is then considered as subscription to all =
documents that owns the user specified in To header. As far as I know, =
no specification explains sufficiently how this request should be =
interpreted.=20

There are three fundamental ways how to process the request.

1. Process the multisubscription as it is, so treat it as single =
subscription in single dialogue. One initial Notification is sent; the =
client is informed about changes in this dialogue.

2. Internaly divide the multisubscription into several single =
subscriptions to single documents but the subscription is served in =
single dialog. In case the user owns N document, there is sent N initial =
subscription, each expires individually; the client is then informed =
about changes of single documents.

3. Internaly divide the multisubscription into several single =
subscriptions to single documents and establish multiple diagolues. The =
client is then informed about changes in separate dialogues. Rest of =
behavior is the same as in the previous case.

However, in the subsequent handing there could occur some problems.

(ad1) If we consider the multisusbcription as the subscription to all =
documents in-one then what about the documents that are created after =
that subscription. Should the server subscribe document created after =
the subscribe request ? Another problem: notification shall contain =
information about affected document and header Subscription-State holds =
the state of the subscription. If more changes occur (one document is =
deleted, one document is modified) - the diff format holds both changes =
but contains only one Subscription-State header.

(ad2) If we divide multisubscription into separate subscriptions how to =
handle subsequent multisubscription refreshment if some of these =
subscriptions changed its state (e.g. the document was deleted), or one =
of them has been expired during subscription refresh activity (ie. there =
is an inconsistence in state of the subscriptions).

(ad3) This option is from the logical point of view the most suitable, =
but it not used because it is little bit unnatural according to model: 1 =
request - 1 confirmation.

The general question could be stated as "How to handle the =
multisubscription with the respect to subsequent events involving =
documents removal, subscription refreshments and expirations?".


Thanks for suggestions, explanataions, comments in advance,

Martin Hynar=20

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail martin.hynar@tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava=20

www.tietoenator.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 08 09:56:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E286z-00033L-CQ; Mon, 08 Aug 2005 09:56:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E286v-00030P-Mw
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 09:56:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21664
	for <simple@ietf.org>; Mon, 8 Aug 2005 09:56:11 -0400 (EDT)
Received: from lizzard.sbs.de ([194.138.37.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28ec-0000Ex-N4
	for simple@ietf.org; Mon, 08 Aug 2005 10:31:04 -0400
Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j78DtfLO015793;
	Mon, 8 Aug 2005 15:55:41 +0200
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j78DteSt030138;
	Mon, 8 Aug 2005 15:55:40 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); 
	Mon, 8 Aug 2005 15:55:38 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Subject: AW: [Simple] tel URIs in common policy
Date: Mon, 8 Aug 2005 15:55:37 +0200
Message-ID: <ECDC9C7BC7809340842C0E7FCF48C39363CCBE@MCHP7IEA.ww002.siemens.net>
Thread-Topic: [Simple] tel URIs in common policy
Thread-Index: AcWbtxmlhQQ2QKReSV2EFSQ2/2Ag6QAaPZuQ
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: "Martin Thomson" <martin.thomson@nortel.com>,
	"Henning Schulzrinne" <hgs@cs.columbia.edu>, <simple@ietf.org>
X-OriginalArrivalTime: 08 Aug 2005 13:55:38.0085 (UTC)
	FILETIME=[DB3A6150:01C59C20]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

hi martin,=20

i think that we do not need a list. here are the reasons:=20
we don't need to differentiate between sip and sips since we already do =
this with the identity conditions in the authorization policies.=20
with regard to something like mailto and other application domains =
someone has to write a document how the authorization policies apply to =
their particular protocol and application domain anyway (similar to what =
jonathan did with the presence authorization policies).=20

within the common-policy document we only need to indicate that there is =
an additional attribute that goes along with the id element (and a =
request for an iana registry). introducing the tel uri scheme (as a =
value in this newly defined attribute of the id element) would be done =
in the presence authz document since it makes sense there.=20

ciao
hannes

-----Urspr=FCngliche Nachricht-----
Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im Auftrag =
von Martin Thomson
Gesendet: Montag, 8. August 2005 03:14
An: Henning Schulzrinne; simple@ietf.org
Betreff: RE: [Simple] tel URIs in common policy


You might want to make the scheme attribute a list:=20
<one scheme=3D"sip sips mailto impp" id=3D"alice@example.com" />=20
After all, scheme implies a URI scheme and sip and sips are different =
(irrespective of any higher level decisions that may suggest otherwise). =
 If you want it simpler, then use a different name.
-----Original Message-----=20
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf =
Of Henning Schulzrinne=20
Sent: Monday, 8 August 2005 12:20 AM=20
To: simple@ietf.org=20
Subject: [Simple] tel URIs in common policy=20


In a side conversation, Hannes suggested a solution to the tel URI=20
problem we discussed during the WG meeting, akin to what's done in the=20
geopriv coordinate system parameter, namely to have a parameter that=20
identifies the scheme, as in=20
<one scheme=3D"tel" id=3D"+1-212-555-1234"/>=20
or=20
<one scheme=3D"sip" id=3D"alice@example.com"/>=20
if you really only want to match SIP identity sip:alice@example.com.=20
The default with no scheme parameter is "matches any user@domain =
scheme".=20
In order to complete finishing the section of the spec, I'd value quick=20
feedback on the idea.=20
Henning=20
_______________________________________________=20
Simple mailing list=20
Simple@ietf.org=20
https://www1.ietf.org/mailman/listinfo/simple=20

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 08 14:59:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2Cqh-0004Zk-CP; Mon, 08 Aug 2005 14:59:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Cqg-0004Zf-4w
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 14:59:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09154
	for <simple@ietf.org>; Mon, 8 Aug 2005 14:59:44 -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.43) id 1E2DOQ-0000MI-UL
	for simple@ietf.org; Mon, 08 Aug 2005 15:34:39 -0400
Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j78IxTg6057316
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Aug 2005 13:59:35 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <42F7AB7F.4090606@nostrum.com>
Date: Mon, 08 Aug 2005 13:59:11 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] SIP multisubscription
References: <3ACC9A25264A684F82C71840111F979847F729@carrera.eu.tieto.com>
In-Reply-To: <3ACC9A25264A684F82C71840111F979847F729@carrera.eu.tieto.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

After we nailed down the requirements, I was actually going to propose 
something very similar (except that the requested packages would be 
explicitly specified -- you don't want a devices getting MWI unless it 
supports it, for example). My initial thoughts are that the mechanism 
would be nearly identical to the work we did in the event-list 
specification.

However, I think it would be prudent to defer the discussion of 
mechanism until after we come to agreement on requirements. And, once we 
do get to mechanism, I believe we'll want to pursue most of the 
specification in SIP rather than SIMPLE. (We made what appears, in 
retrospect, to be a mistake in pursuing event-list in SIMPLE, and it has 
suffered some severe procedural delays as a consequence).

After this and a few related conversations converge, I will likely be 
starting a discussion in SIP around spinning up a 3265bis draft -- both 
to fix know errors in the existing specification and to take into 
account additional requirements that have been discovered as a result of 
operational experience. Given that such work is likely to start 
relatively soon, I would be inclined to include the ability to subscribe 
to multiple event packages in a single subscription in that updated 
draft rather than pursue it as a separate effort.

/a

Martin.Hynar@tietoenator.com wrote:

>Hi all,
>
>because of some misunderstandings in handling of multisubscription there becomes a need to some discussion.
>
>What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE request from the client side that does not specify document parameter in its Event header. The request is then considered as subscription to all documents that owns the user specified in To header. As far as I know, no specification explains sufficiently how this request should be interpreted. 
>
>There are three fundamental ways how to process the request.
>
>1. Process the multisubscription as it is, so treat it as single subscription in single dialogue. One initial Notification is sent; the client is informed about changes in this dialogue.
>
>2. Internaly divide the multisubscription into several single subscriptions to single documents but the subscription is served in single dialog. In case the user owns N document, there is sent N initial subscription, each expires individually; the client is then informed about changes of single documents.
>
>3. Internaly divide the multisubscription into several single subscriptions to single documents and establish multiple diagolues. The client is then informed about changes in separate dialogues. Rest of behavior is the same as in the previous case.
>
>However, in the subsequent handing there could occur some problems.
>
>(ad1) If we consider the multisusbcription as the subscription to all documents in-one then what about the documents that are created after that subscription. Should the server subscribe document created after the subscribe request ? Another problem: notification shall contain information about affected document and header Subscription-State holds the state of the subscription. If more changes occur (one document is deleted, one document is modified) - the diff format holds both changes but contains only one Subscription-State header.
>
>(ad2) If we divide multisubscription into separate subscriptions how to handle subsequent multisubscription refreshment if some of these subscriptions changed its state (e.g. the document was deleted), or one of them has been expired during subscription refresh activity (ie. there is an inconsistence in state of the subscriptions).
>
>(ad3) This option is from the logical point of view the most suitable, but it not used because it is little bit unnatural according to model: 1 request - 1 confirmation.
>
>The general question could be stated as "How to handle the multisubscription with the respect to subsequent events involving documents removal, subscription refreshments and expirations?".
>
>
>Thanks for suggestions, explanataions, comments in advance,
>
>Martin Hynar 
>
>Senior Developer
>
>TietoEnator
>Czech Software Centre
>
>Direct +420 599 096 022
>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 Mon Aug 08 19:06:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2GhL-0008J5-VL; Mon, 08 Aug 2005 19:06:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GhK-0008J0-3f
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 19:06:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00850
	for <simple@ietf.org>; Mon, 8 Aug 2005 19:06:19 -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.43) id 1E2HF7-0001Bt-4Y
	for simple@ietf.org; Mon, 08 Aug 2005 19:41:17 -0400
Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j78N6EtB077039
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 8 Aug 2005 18:06:19 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <42F7E554.6040601@nostrum.com>
Date: Mon, 08 Aug 2005 18:05:56 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Yannis Pavlidis <yannis.pavlidis@openwave.com>
Subject: Re: [Simple] Questions
	on	http://www.ietf.org/internet-drafts/draft-ietf-simple-event-list-07.txt
References: <1B8231A47104E04889D95C8019073D1367AC47@rwc-exch-prd2.myopwv.com>
In-Reply-To: <1B8231A47104E04889D95C8019073D1367AC47@rwc-exch-prd2.myopwv.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Yannis Pavlidis wrote:

> Hi,
>
>  
>
> I wanted to make some comments regarding this draft.
>
>  
>
>    1. It is not clear in this document what the duration should be of
>       the back end subscriptions placed from the RLS to the Presence
>       Server(s). In the example while the event list subscription has
>       a duration of 7200 the back end subscriptions have a duration of
>       3600. This will result in wasting resources in the RLS e.g. the
>       event list subscription will remain active for one more hour
>       while the back end subscriptions have been terminated. It would
>       be reasonable to assume that the duration of the back end
>       subscriptions is the same with the duration of the event list
>       subscription (at least on the establishment part as a PS may
>       reduce the subscription duration of the back end subscription).
>       What are your thoughts?
>

Your assertion isn't exactly correct, as any failure on the back-end 
will trigger notification to the ultimate subscriber letting them know 
that one of the resources in the list has gone away:

   If an instance of a resource was previously reported to the
   subscriber but is no longer available (i.e.  the virtual subscription
   to that instance has been terminated), the resource list server
   SHOULD include that resource instance in the meta-information in the
   first NOTIFY message sent to the subscriber following the instance's
   unavailability.  The RLS MAY continue to do so for future
   notifications.



In any case, the handling of back-end subscriptions is completely up to 
the implementation (modulo some of the security issues discussed in the 
draft), including duration of subscriptions. If you have a valid network 
purpose to making those subscriptions 10 seconds, go ahead. If you think 
8 hours is a better choice, feel free. (Both of those values are 
dubious, by the way). If you think you want to make them match the 
front-end subscriptions, nothing stops you. Make it random. Choose 
100*pi. This is where you, as an engineer, add value. If we wanted 
everything to work exactly the same, then the IETF would be creating and 
standardizing software instead of protocol specifications.

>
>    1. According with the text in section 4.1
>          1. Message flow  7 should not contain a require header as ed
>             is not a resource list
>          2. Message flow 10 should contain a require header as
>             adam-friends is a resource list
>

Good catch. I will fix these errors in auth48.

>    1. The example in the draft assumes a co-location of a PS and RLS
>       server. What happens when in a domain they are separated (a
>       separate RLS and PS instance)? How is the request for a specific
>       user will go to the PS (flow 5) and how a request for a resource
>       list will go to the RLS (flow 9)?
>

That's a network architecture question, not a protocol question -- and a 
lot of that comes down to how you otherwise design your network. At a 
high level, once you start using different servers for different 
functions within a single domain (and such is usually the case), you 
need to figure out how you're going to perform that distribution. Event 
lists are no exception.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 08 19:20:03 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2GuZ-0004v1-0x; Mon, 08 Aug 2005 19:20:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2GuW-0004pp-BT
	for simple@megatron.ietf.org; Mon, 08 Aug 2005 19:20:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01375
	for <simple@ietf.org>; Mon, 8 Aug 2005 19:19:57 -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.43)
	id 1E2HSH-0001Wx-45
	for simple@ietf.org; Mon, 08 Aug 2005 19:54:55 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 08 Aug 2005 16:19:48 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j78NJdoq027767;
	Mon, 8 Aug 2005 16:19:45 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 8 Aug 2005 19:19:40 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 19:19:39 -0400
Message-ID: <42F7E88A.207@cisco.com>
Date: Mon, 08 Aug 2005 19:19:38 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Adam Roach <adam@nostrum.com>
Subject: Re: [Simple] SIP multisubscription
References: <3ACC9A25264A684F82C71840111F979847F729@carrera.eu.tieto.com>
	<42F7AB7F.4090606@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Aug 2005 23:19:39.0336 (UTC)
	FILETIME=[A62F7C80:01C59C6F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I would like to emphasize the need to carefully address requirements. 
While lots of people seem interested in some form of unsolicited NOTIFY, 
or implicit subscription, or multisubscrption, or register coupled 
subscription, and all seem to want this in order to minimize 
*something*, its pretty clear that all the people aren't thinking of 
minimizing the same thing. Some things that may be large for a lot of 
subscriptions that might want to be optimized are:

- total number of watcher messages
- total number of notifier messages
- watcher bandwidth
- notifier bandwidth
- amount of watcher subscription state
- amount of notifier subscription state
- total number of message hops overall
- peak message rate at some event
   (e.g. at initial registration)
   experienced at:
   - watcher
   - notifier
   - state agent
- minimizing reliance on network servers
- maximizing reliance on network servers

The ideal mechanism will depend on which optimization we are trying to 
achieve.

	Paul

Adam Roach wrote:
> After we nailed down the requirements, I was actually going to propose 
> something very similar (except that the requested packages would be 
> explicitly specified -- you don't want a devices getting MWI unless it 
> supports it, for example). My initial thoughts are that the mechanism 
> would be nearly identical to the work we did in the event-list 
> specification.
> 
> However, I think it would be prudent to defer the discussion of 
> mechanism until after we come to agreement on requirements. And, once we 
> do get to mechanism, I believe we'll want to pursue most of the 
> specification in SIP rather than SIMPLE. (We made what appears, in 
> retrospect, to be a mistake in pursuing event-list in SIMPLE, and it has 
> suffered some severe procedural delays as a consequence).
> 
> After this and a few related conversations converge, I will likely be 
> starting a discussion in SIP around spinning up a 3265bis draft -- both 
> to fix know errors in the existing specification and to take into 
> account additional requirements that have been discovered as a result of 
> operational experience. Given that such work is likely to start 
> relatively soon, I would be inclined to include the ability to subscribe 
> to multiple event packages in a single subscription in that updated 
> draft rather than pursue it as a separate effort.
> 
> /a
> 
> Martin.Hynar@tietoenator.com wrote:
> 
>> Hi all,
>>
>> because of some misunderstandings in handling of multisubscription 
>> there becomes a need to some discussion.
>>
>> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE 
>> request from the client side that does not specify document parameter 
>> in its Event header. The request is then considered as subscription to 
>> all documents that owns the user specified in To header. As far as I 
>> know, no specification explains sufficiently how this request should 
>> be interpreted.
>> There are three fundamental ways how to process the request.
>>
>> 1. Process the multisubscription as it is, so treat it as single 
>> subscription in single dialogue. One initial Notification is sent; the 
>> client is informed about changes in this dialogue.
>>
>> 2. Internaly divide the multisubscription into several single 
>> subscriptions to single documents but the subscription is served in 
>> single dialog. In case the user owns N document, there is sent N 
>> initial subscription, each expires individually; the client is then 
>> informed about changes of single documents.
>>
>> 3. Internaly divide the multisubscription into several single 
>> subscriptions to single documents and establish multiple diagolues. 
>> The client is then informed about changes in separate dialogues. Rest 
>> of behavior is the same as in the previous case.
>>
>> However, in the subsequent handing there could occur some problems.
>>
>> (ad1) If we consider the multisusbcription as the subscription to all 
>> documents in-one then what about the documents that are created after 
>> that subscription. Should the server subscribe document created after 
>> the subscribe request ? Another problem: notification shall contain 
>> information about affected document and header Subscription-State 
>> holds the state of the subscription. If more changes occur (one 
>> document is deleted, one document is modified) - the diff format holds 
>> both changes but contains only one Subscription-State header.
>>
>> (ad2) If we divide multisubscription into separate subscriptions how 
>> to handle subsequent multisubscription refreshment if some of these 
>> subscriptions changed its state (e.g. the document was deleted), or 
>> one of them has been expired during subscription refresh activity (ie. 
>> there is an inconsistence in state of the subscriptions).
>>
>> (ad3) This option is from the logical point of view the most suitable, 
>> but it not used because it is little bit unnatural according to model: 
>> 1 request - 1 confirmation.
>>
>> The general question could be stated as "How to handle the 
>> multisubscription with the respect to subsequent events involving 
>> documents removal, subscription refreshments and expirations?".
>>
>>
>> Thanks for suggestions, explanataions, comments in advance,
>>
>> Martin Hynar
>> Senior Developer
>>
>> TietoEnator
>> Czech Software Centre
>>
>> Direct +420 599 096 022
>> 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
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 09 03:26:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2OVe-00035g-1D; Tue, 09 Aug 2005 03:26:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2OVb-00035V-Uk
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 03:26:47 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17349
	for <simple@ietf.org>; Tue, 9 Aug 2005 03:26:46 -0400 (EDT)
From: Martin.Hynar@tietoenator.com
Received: from ebb04.tietoenator.com ([194.142.141.101])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2P3S-0005PI-Bg
	for simple@ietf.org; Tue, 09 Aug 2005 04:01:47 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 9 Aug 2005 09:25:52 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F72C@carrera.eu.tieto.com>
Thread-Topic: SIP multisubscription (some more details)
Thread-Index: AcWcs5K8VJ4HyFleS/24X71aH/bV1A==
To: <simple@ietf.org>
X-OriginalArrivalTime: 09 Aug 2005 07:25:53.0918 (UTC)
	FILETIME=[939769E0:01C59CB3]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] SIP multisubscription (some more details)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi all again,

I'd like to add some more detailed view on the problem I'm trying to =
solve.

I'm using specification draft-ietf-sipping-config-framework-06 that in =
section 4.6 allows to subscribe arbitrary AUID. This means, I'm sending =
to server a request in form (only significant headers listed)

SUBSCRIBE sip:user@domain.com SIP/2.0
To: "Example" sip:user@domain.com
From: "Example" sip:user@domain.com;tag=3D12345
Call-ID: 1@localhost
CSeq: 1000 SUBSCRIBE
Event: sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists
Accept: message/external-body, application/sdp

This means, I'm not specifying particular document, so the server =
retrieves all documents owned by user in request and subscribes them. =
The server sends exatly one response (200 OK) if all documents were =
subscribed correctly. Then, the server sends multiple NOTIFY requests, =
one for each of subscribed documents. The established dialogue then =
lasts until some of the created subscriptions is in different state than =
"terminated". The problems with this solution were stated in my previous =
email.

Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
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



From simple-bounces@ietf.org Tue Aug 09 08:53:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2TbS-0000gB-Ec; Tue, 09 Aug 2005 08:53:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2TbP-0000d9-Bv
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 08:53:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04131
	for <simple@ietf.org>; Tue, 9 Aug 2005 08:53:05 -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.43)
	id 1E2U9I-0006Y3-OQ
	for simple@ietf.org; Tue, 09 Aug 2005 09:28:10 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 09 Aug 2005 05:52:56 -0700
X-IronPort-AV: i="3.96,91,1122879600"; 
	d="scan'208"; a="330418218:sNHT29884420"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j79Cqn0L008927;
	Tue, 9 Aug 2005 05:52:53 -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, 9 Aug 2005 08:52:45 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 08:52:45 -0400
Message-ID: <42F8A716.90604@cisco.com>
Date: Tue, 09 Aug 2005 08:52:38 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] SIP multisubscription (some more details)
References: <3ACC9A25264A684F82C71840111F979847F72C@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2005 12:52:45.0199 (UTC)
	FILETIME=[3CD369F0:01C59CE1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Martin,

OK, that is different than I thought. Your question is then specifically 
about the sip-profile event type, not about the subscription mechanism 
in general.

	Paul

Martin.Hynar@tietoenator.com wrote:
> Hi all again,
> 
> I'd like to add some more detailed view on the problem I'm trying to solve.
> 
> I'm using specification draft-ietf-sipping-config-framework-06 that in section 4.6 allows to subscribe arbitrary AUID. This means, I'm sending to server a request in form (only significant headers listed)
> 
> SUBSCRIBE sip:user@domain.com SIP/2.0
> To: "Example" sip:user@domain.com
> From: "Example" sip:user@domain.com;tag=12345
> Call-ID: 1@localhost
> CSeq: 1000 SUBSCRIBE
> Event: sip-profile;profile-type=application;app-id=resource-lists
> Accept: message/external-body, application/sdp
> 
> This means, I'm not specifying particular document, so the server retrieves all documents owned by user in request and subscribes them. The server sends exatly one response (200 OK) if all documents were subscribed correctly. Then, the server sends multiple NOTIFY requests, one for each of subscribed documents. The established dialogue then lasts until some of the created subscriptions is in different state than "terminated". The problems with this solution were stated in my previous email.
> 
> Martin Hynar
> 
> Senior Developer
> 
> TietoEnator
> Czech Software Centre
> 
> Direct +420 599 096 022
> 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 Tue Aug 09 09:19:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2U17-0001gG-VT; Tue, 09 Aug 2005 09:19:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2U15-0001fz-KK
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 09:19:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05384
	for <simple@ietf.org>; Tue, 9 Aug 2005 09:19:37 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2UYz-0007G4-0Y
	for simple@ietf.org; Tue, 09 Aug 2005 09:54:42 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2005 09:19:29 -0400
X-IronPort-AV: i="3.96,91,1122868800"; d="scan'208"; a="65793846:sNHT31842248"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j79DJNQp006008; 
	Tue, 9 Aug 2005 09:19:27 -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);
	Tue, 9 Aug 2005 09:19:21 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 09:19:21 -0400
Message-ID: <42F8AD58.4070908@cisco.com>
Date: Tue, 09 Aug 2005 09:19:20 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] SIP multisubscription
References: <3ACC9A25264A684F82C71840111F979847F729@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2005 13:19:21.0433 (UTC)
	FILETIME=[F4416490:01C59CE4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Based on your clarification in another message I think I now understand 
enough to comment. Inline...

	Paul

Martin.Hynar@tietoenator.com wrote:
> Hi all,
> 
> because of some misunderstandings in handling of multisubscription there becomes a need to some discussion.
> 
> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE request from the client side that does not specify document parameter in its Event header. The request is then considered as subscription to all documents that owns the user specified in To header. As far as I know, no specification explains sufficiently how this request should be interpreted. 

The parameters that refer to documents are strictly a part of the 
sip-profile event package, not a feature of the general event mechanism.

> There are three fundamental ways how to process the request.
> 
> 1. Process the multisubscription as it is, so treat it as single subscription in single dialogue. One initial Notification is sent; the client is informed about changes in this dialogue.
> 
> 2. Internaly divide the multisubscription into several single subscriptions to single documents but the subscription is served in single dialog. In case the user owns N document, there is sent N initial subscription, each expires individually; the client is then informed about changes of single documents.
> 
> 3. Internaly divide the multisubscription into several single subscriptions to single documents and establish multiple diagolues. The client is then informed about changes in separate dialogues. Rest of behavior is the same as in the previous case.

 From the point of view of 3265, this is a single subscription. The 
parameters to the event type merely qualify how the notifier processes 
this subscription. They cannot cause it to become more than one 
subscription, or more than one dialog.

> However, in the subsequent handing there could occur some problems.
> 
> (ad1) If we consider the multisusbcription as the subscription to all documents in-one then what about the documents that are created after that subscription. Should the server subscribe document created after the subscribe request ? Another problem: notification shall contain information about affected document and header Subscription-State holds the state of the subscription. If more changes occur (one document is deleted, one document is modified) - the diff format holds both changes but contains only one Subscription-State header.

The interpretation of how the parameters affect the subsequent 
processing is something that must be addressed by the specification of 
the particular event package. It must simply specify under what 
circumstances it will send notifications and what they will contain.

> (ad2) If we divide multisubscription into separate subscriptions how to handle subsequent multisubscription refreshment if some of these subscriptions changed its state (e.g. the document was deleted), or one of them has been expired during subscription refresh activity (ie. there is an inconsistence in state of the subscriptions).

IMO, as noted above, there is way this can be a valid interpretation of 
what is to be done.

> (ad3) This option is from the logical point of view the most suitable, but it not used because it is little bit unnatural according to model: 1 request - 1 confirmation.

Same comment as for ad2.

	Paul

> The general question could be stated as "How to handle the multisubscription with the respect to subsequent events involving documents removal, subscription refreshments and expirations?".
> 
> 
> Thanks for suggestions, explanataions, comments in advance,
> 
> Martin Hynar 
> 
> Senior Developer
> 
> TietoEnator
> Czech Software Centre
> 
> Direct +420 599 096 022
> 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 Tue Aug 09 10:55:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2VW2-0001c4-7E; Tue, 09 Aug 2005 10:55:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2VVy-0001bU-TX; Tue, 09 Aug 2005 10:55:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13315;
	Tue, 9 Aug 2005 10:55:36 -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.43)
	id 1E2W3t-00027t-6g; Tue, 09 Aug 2005 11:30:42 -0400
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j79EtGa6043840
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 9 Aug 2005 09:55:17 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <b73c172eee68bc321dab19c5e0a973a3@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Date: Tue, 9 Aug 2005 09:57:31 -0500
To: Simple WG <simple@ietf.org>, sip-implementors@cs.columbia.edu,
	"sip@ietf.org WG" <sip@ietf.org>
X-Mailer: Apple Mail (2.622)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2
Content-Transfer-Encoding: 7bit
Cc: 
Subject: [Simple] SIPIT 17 registration closes this week
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


SIPIT 17 will take place Sep 12-16 in Stockholm, Sweden, hosted by 
Hotsip.
Information about the event is available at sipit17.hotsip.com and 
www.sipit.net.

Registration closes August 14 (this Sunday). If you plan to attend but 
have not yet
registered, please do so now.

Thanks,

RjS


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 09 11:42:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2WEx-0005BP-4C; Tue, 09 Aug 2005 11:42:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2WEw-0005BJ-BE
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 11:42:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16379
	for <simple@ietf.org>; Tue, 9 Aug 2005 11:42:03 -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.43) id 1E2Wmq-0003fq-HR
	for simple@ietf.org; Tue, 09 Aug 2005 12:17:10 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] SIP multisubscription
Date: Tue, 9 Aug 2005 17:41:45 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F72D@carrera.eu.tieto.com>
Thread-Topic: [Simple] SIP multisubscription
Thread-Index: AcWc5QLtNaxiZWr2TrGp5hGi+274BwADJX42
To: <pkyzivat@cisco.com>
X-OriginalArrivalTime: 09 Aug 2005 15:41:47.0992 (UTC)
	FILETIME=[DA66CD80:01C59CF8]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,


I understand that rfc 3265 does not specify what to do with particular =
event-template. My problem lies in fact that there is no event-package =
for working with resource-lists (that is the only AUID I'm supporting). =
The only possibility is to use the sipping-config which introduces some =
workaround. The subsequent problem is that on one hand it allows "too =
much liberty" when selecting the target of subscription and on the other =
hand it does not specify how to handle it. What I am asking is if there =
is some way how to solve it now without the specification but complying =
everything stated in e.g. rfc3261, rfc3265.


Imagine the fundamental problem,

1. user U_1 has three documents with resource-lists AUID
2. another user U_2 subscribes them in one SUBECRIBE request
   ...
   Event: sip-profile;app-id=3Dresource-lists
   ...
3. user U_1 deletes one of his documents
4. user U_2 is notified with NOTIFY request
   ...
   Event: sip-profile;app-id=3Dresource-lists;document=3Ddoc1
   Subscription-State: terminated;reason=3Dnoresource

Questions:
Shall now the user U_2 consider its dialogue as terminated or not, there =
are still some documents that could be subscribed in this dialogue.
Shall the server consider the dialogue terminated?


Thanks much for helping response.



Based on your clarification in another message I think I now understand=20
enough to comment. Inline...

	Paul

Martin.Hynar@tietoenator.com wrote:
> Hi all,
>=20
> because of some misunderstandings in handling of multisubscription =
there becomes a need to some discussion.
>=20
> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE =
request from the client side that does not specify document parameter in =
its Event header. The request is then considered as subscription to all =
documents that owns the user specified in To header. As far as I know, =
no specification explains sufficiently how this request should be =
interpreted.=20

The parameters that refer to documents are strictly a part of the=20
sip-profile event package, not a feature of the general event mechanism.

> There are three fundamental ways how to process the request.
>=20
> 1. Process the multisubscription as it is, so treat it as single =
subscription in single dialogue. One initial Notification is sent; the =
client is informed about changes in this dialogue.
>=20
> 2. Internaly divide the multisubscription into several single =
subscriptions to single documents but the subscription is served in =
single dialog. In case the user owns N document, there is sent N initial =
subscription, each expires individually; the client is then informed =
about changes of single documents.
>=20
> 3. Internaly divide the multisubscription into several single =
subscriptions to single documents and establish multiple diagolues. The =
client is then informed about changes in separate dialogues. Rest of =
behavior is the same as in the previous case.

 From the point of view of 3265, this is a single subscription. The=20
parameters to the event type merely qualify how the notifier processes=20
this subscription. They cannot cause it to become more than one=20
subscription, or more than one dialog.

> However, in the subsequent handing there could occur some problems.
>=20
> (ad1) If we consider the multisusbcription as the subscription to all =
documents in-one then what about the documents that are created after =
that subscription. Should the server subscribe document created after =
the subscribe request ? Another problem: notification shall contain =
information about affected document and header Subscription-State holds =
the state of the subscription. If more changes occur (one document is =
deleted, one document is modified) - the diff format holds both changes =
but contains only one Subscription-State header.

The interpretation of how the parameters affect the subsequent=20
processing is something that must be addressed by the specification of=20
the particular event package. It must simply specify under what=20
circumstances it will send notifications and what they will contain.

> (ad2) If we divide multisubscription into separate subscriptions how =
to handle subsequent multisubscription refreshment if some of these =
subscriptions changed its state (e.g. the document was deleted), or one =
of them has been expired during subscription refresh activity (ie. there =
is an inconsistence in state of the subscriptions).

IMO, as noted above, there is way this can be a valid interpretation of=20
what is to be done.

> (ad3) This option is from the logical point of view the most suitable, =
but it not used because it is little bit unnatural according to model: 1 =
request - 1 confirmation.

Same comment as for ad2.

	Paul

> The general question could be stated as "How to handle the =
multisubscription with the respect to subsequent events involving =
documents removal, subscription refreshments and expirations?".
>=20
>=20
> Thanks for suggestions, explanataions, comments in advance,
>=20
Martin Hynar=20

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail martin.hynar@tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava=20

www.tietoenator.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 09 12:34:23 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2X3X-0005eg-Iu; Tue, 09 Aug 2005 12:34:23 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2X3V-0005eY-U9
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 12:34:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21577
	for <simple@ietf.org>; Tue, 9 Aug 2005 12:34:18 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2XbR-0005qh-1K
	for simple@ietf.org; Tue, 09 Aug 2005 13:09:26 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2005 12:34:11 -0400
X-IronPort-AV: i="3.96,92,1122868800"; d="scan'208"; a="65830565:sNHT30111346"
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 j79GY4TA004997; 
	Tue, 9 Aug 2005 12:34:09 -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);
	Tue, 9 Aug 2005 12:33:58 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 12:33:57 -0400
Message-ID: <42F8DAF5.6010009@cisco.com>
Date: Tue, 09 Aug 2005 12:33:57 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] SIP multisubscription
References: <3ACC9A25264A684F82C71840111F979847F72D@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2005 16:33:57.0861 (UTC)
	FILETIME=[23F2E950:01C59D00]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Martin.Hynar@tietoenator.com wrote:
> Hi,
> 
> 
> I understand that rfc 3265 does not specify what to do with particular event-template. My problem lies in fact that there is no event-package for working with resource-lists (that is the only AUID I'm supporting). The only possibility is to use the sipping-config which introduces some workaround. The subsequent problem is that on one hand it allows "too much liberty" when selecting the target of subscription and on the other hand it does not specify how to handle it. What I am asking is if there is some way how to solve it now without the specification but complying everything stated in e.g. rfc3261, rfc3265.
> 
> 
> Imagine the fundamental problem,
> 
> 1. user U_1 has three documents with resource-lists AUID
> 2. another user U_2 subscribes them in one SUBECRIBE request
>    ...
>    Event: sip-profile;app-id=resource-lists
>    ...

This results in *one* subscription.

> 3. user U_1 deletes one of his documents

This changes the state of the resource that has been subscribed to.

> 4. user U_2 is notified with NOTIFY request
>    ...
>    Event: sip-profile;app-id=resource-lists;document=doc1
>    Subscription-State: terminated;reason=noresource

If there were multiple documents subscribed to, then why would this 
cause the subscription to be terminated? I guess the server can do so if 
it wants, but it seems like the wrong thing to do. After all, the 
subscriber could reissue the same subscription request and it would be 
valid, so it is not the case that the resource is gone. It is only 
*part* of the resource that is gone.

> Questions:
> Shall now the user U_2 consider its dialogue as terminated or not,

Given that it received the above response, then yes.

> there are still some documents that could be subscribed in this dialogue.
> Shall the server consider the dialogue terminated?

I think not. The "resource" that is being subscribed to in this case is 
determined by the R-URI, the event package, and the event package 
parameters. If that happened to correspond to a collection of documents, 
then it is the collection of documents that is the resource.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 09 17:23:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2bZY-0002Fv-P3; Tue, 09 Aug 2005 17:23:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2bZW-0002Fq-Mx
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 17:23:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15540
	for <simple@ietf.org>; Tue, 9 Aug 2005 17:23:39 -0400 (EDT)
Received: from c243-111.rim.net ([216.9.243.111] helo=MHS02YKF.rim.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2c7S-0007mo-Ve
	for simple@ietf.org; Tue, 09 Aug 2005 17:58:49 -0400
Received: from ngw01ykf.rim.net ([10.102.108.30]) by MHS02YKF.rim.net with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 17:23:27 -0400
Importance: normal
Priority: normal
Received: from XCH20YKF.rim.net ([10.102.100.35]) by ngw01ykf.rim.net (SAVSMTP
	3.1.6.45) with SMTP id M2005080917232732553 ;
	Tue, 09 Aug 2005 17:23:27 -0400
Received: from XCH30YKF.rim.net ([10.102.100.42]) by XCH20YKF.rim.net with
	Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Aug 2005 17:23:27 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Simple] SIP multisubscription
Date: Tue, 9 Aug 2005 17:23:26 -0400
Message-ID: <AABA1AE6F5565C4E9979704419B3B8990ABB161B@XCH30YKF.rim.net>
Thread-Topic: [Simple] SIP multisubscription
thread-index: AcWccCMfGhlFAepoTQCRz8PHLa/LQAAuHXSR
From: "Andrew Allen" <aallen@rim.com>
To: <pkyzivat@cisco.com>, <adam@nostrum.com>
X-OriginalArrivalTime: 09 Aug 2005 21:23:27.0817 (UTC)
	FILETIME=[953FDB90:01C59D28]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Paul

Another one the number of refresh Subscriptions. Big battery issue for =
mobile devices.


Andrew
--------------------------
Andrew Allen
Manager Standards
Research In Motion Ltd
BlackBerry Mobile  +1 847 809 8636
http://www.rim.com/

Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: simple-bounces@ietf.org <simple-bounces@ietf.org>
To: Adam Roach <adam@nostrum.com>
CC: simple@ietf.org <simple@ietf.org>
Sent: Mon Aug 08 19:19:38 2005
Subject: Re: [Simple] SIP multisubscription

I would like to emphasize the need to carefully address requirements.=20
While lots of people seem interested in some form of unsolicited NOTIFY, =

or implicit subscription, or multisubscrption, or register coupled=20
subscription, and all seem to want this in order to minimize=20
*something*, its pretty clear that all the people aren't thinking of=20
minimizing the same thing. Some things that may be large for a lot of=20
subscriptions that might want to be optimized are:

- total number of watcher messages
- total number of notifier messages
- watcher bandwidth
- notifier bandwidth
- amount of watcher subscription state
- amount of notifier subscription state
- total number of message hops overall
- peak message rate at some event
   (e.g. at initial registration)
   experienced at:
   - watcher
   - notifier
   - state agent
- minimizing reliance on network servers
- maximizing reliance on network servers

The ideal mechanism will depend on which optimization we are trying to=20
achieve.

	Paul

Adam Roach wrote:
> After we nailed down the requirements, I was actually going to propose =

> something very similar (except that the requested packages would be=20
> explicitly specified -- you don't want a devices getting MWI unless it =

> supports it, for example). My initial thoughts are that the mechanism=20
> would be nearly identical to the work we did in the event-list=20
> specification.
>=20
> However, I think it would be prudent to defer the discussion of=20
> mechanism until after we come to agreement on requirements. And, once =
we=20
> do get to mechanism, I believe we'll want to pursue most of the=20
> specification in SIP rather than SIMPLE. (We made what appears, in=20
> retrospect, to be a mistake in pursuing event-list in SIMPLE, and it =
has=20
> suffered some severe procedural delays as a consequence).
>=20
> After this and a few related conversations converge, I will likely be=20
> starting a discussion in SIP around spinning up a 3265bis draft -- =
both=20
> to fix know errors in the existing specification and to take into=20
> account additional requirements that have been discovered as a result =
of=20
> operational experience. Given that such work is likely to start=20
> relatively soon, I would be inclined to include the ability to =
subscribe=20
> to multiple event packages in a single subscription in that updated=20
> draft rather than pursue it as a separate effort.
>=20
> /a
>=20
> Martin.Hynar@tietoenator.com wrote:
>=20
>> Hi all,
>>
>> because of some misunderstandings in handling of multisubscription=20
>> there becomes a need to some discussion.
>>
>> What exactly I call multisubscribe: Multisubscribe is SIP SUBSCRIBE=20
>> request from the client side that does not specify document parameter =

>> in its Event header. The request is then considered as subscription =
to=20
>> all documents that owns the user specified in To header. As far as I=20
>> know, no specification explains sufficiently how this request should=20
>> be interpreted.
>> There are three fundamental ways how to process the request.
>>
>> 1. Process the multisubscription as it is, so treat it as single=20
>> subscription in single dialogue. One initial Notification is sent; =
the=20
>> client is informed about changes in this dialogue.
>>
>> 2. Internaly divide the multisubscription into several single=20
>> subscriptions to single documents but the subscription is served in=20
>> single dialog. In case the user owns N document, there is sent N=20
>> initial subscription, each expires individually; the client is then=20
>> informed about changes of single documents.
>>
>> 3. Internaly divide the multisubscription into several single=20
>> subscriptions to single documents and establish multiple diagolues.=20
>> The client is then informed about changes in separate dialogues. Rest =

>> of behavior is the same as in the previous case.
>>
>> However, in the subsequent handing there could occur some problems.
>>
>> (ad1) If we consider the multisusbcription as the subscription to all =

>> documents in-one then what about the documents that are created after =

>> that subscription. Should the server subscribe document created after =

>> the subscribe request ? Another problem: notification shall contain=20
>> information about affected document and header Subscription-State=20
>> holds the state of the subscription. If more changes occur (one=20
>> document is deleted, one document is modified) - the diff format =
holds=20
>> both changes but contains only one Subscription-State header.
>>
>> (ad2) If we divide multisubscription into separate subscriptions how=20
>> to handle subsequent multisubscription refreshment if some of these=20
>> subscriptions changed its state (e.g. the document was deleted), or=20
>> one of them has been expired during subscription refresh activity =
(ie.=20
>> there is an inconsistence in state of the subscriptions).
>>
>> (ad3) This option is from the logical point of view the most =
suitable,=20
>> but it not used because it is little bit unnatural according to =
model:=20
>> 1 request - 1 confirmation.
>>
>> The general question could be stated as "How to handle the=20
>> multisubscription with the respect to subsequent events involving=20
>> documents removal, subscription refreshments and expirations?".
>>
>>
>> Thanks for suggestions, explanataions, comments in advance,
>>
>> Martin Hynar
>> Senior Developer
>>
>> TietoEnator
>> Czech Software Centre
>>
>> Direct +420 599 096 022
>> 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
>>
>> =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



---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential =
information, privileged material (including material protected by the =
solicitor-client or other applicable privileges), or constitute =
non-public information. Any use of this information by anyone other than =
the intended recipient is prohibited. If you have received this =
transmission in error, please immediately reply to the sender and delete =
this information from your system. Use, dissemination, distribution, or =
reproduction of this transmission by unintended recipients is not =
authorized and may be unlawful.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 09 18:49:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2cuV-0003gE-Bd; Tue, 09 Aug 2005 18:49:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2cuQ-0003g3-Rz
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 18:49:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20887
	for <simple@ietf.org>; Tue, 9 Aug 2005 18:49:19 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2dSQ-0001Nt-Ft
	for simple@ietf.org; Tue, 09 Aug 2005 19:24:30 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2005 18:49:14 -0400
X-IronPort-AV: i="3.96,94,1122868800"; d="scan'208"; a="65892076:sNHT30008240"
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 j79Mn9T8013731; 
	Tue, 9 Aug 2005 18:49:11 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 9 Aug 2005 18:49:09 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 18:49:08 -0400
Message-ID: <42F932E4.4010004@cisco.com>
Date: Tue, 09 Aug 2005 18:49:08 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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 <hgs@cs.columbia.edu>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Aug 2005 22:49:08.0780 (UTC)
	FILETIME=[8D808EC0:01C59D34]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I haven't been following common policy closely for awhile, so I may put 
my foot in my mouth here. But anyway...

You have mentioned the desire to ignore the difference between sip and 
sips. This probably makes sense, at least most of the time. (But not 
always - you may only want to grant full access to your presence state, 
with sensitive info, over a sips connection.)

Also, schemes are more than just distinct namespaces. There are 
significant differences from scheme to scheme about how equivalence of 
names is defined. Tel URIs must be compared differently for equivalence 
than sip (user=ip) URIs. Separator characters must be ignored, and 
parameters must be properly compared. (e.g. phone-context).

Just as sip and sips URIs might be considered equivalent for purposes of 
identity equivalence, so may tel and sip/sips;user=phone. It seems many 
people prefer to use sip URIs for phone numbers, using whatever domain 
name is handy for them. This can cause a huge mess in determining 
equivalence. Technically one should not consider to sip URIs with 
different domains to be equivalent even if they both seem to represent 
the same phone number, and it gives me heartburn to suggest doing so, 
but pragmatically I think it must probably be supported. Specifically, I 
think all the following need to be considered equivalent:

	tel:+1-555-987-6543
	tel:+15559876543
	sip:+1(555)987.6543@foo.com;user=phone
	sip:+15.55.98.76.543@bar.net;user=phone

If we don't get this right, people will end up not being able to set 
policy for callers without understanding how the caller is identified 
from each different device he uses. If you end up needing a call log to 
figure out how your callers are identified before you can authorize 
them, then the system will be nearly unusable.

We also talked last week about wildcarding. I think there will be 
demand/need for this. Things like:

	tel:+1-900-nnn-nnnn

Even this assumes that global form numbers are being used. Various forms 
of dial strings make more of a mess. But lets not discuss that for now.

	Paul

Henning Schulzrinne wrote:
> In a side conversation, Hannes suggested a solution to the tel URI 
> problem we discussed during the WG meeting, akin to what's done in the 
> geopriv coordinate system parameter, namely to have a parameter that 
> identifies the scheme, as in
> 
> <one scheme="tel" id="+1-212-555-1234"/>
> 
> or
> 
> <one scheme="sip" id="alice@example.com"/>
> 
> if you really only want to match SIP identity sip:alice@example.com.
> 
> The default with no scheme parameter is "matches any user@domain scheme".
> 
> In order to complete finishing the section of the spec, I'd value quick 
> feedback on the idea.
> 
> 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 Aug 09 19:52:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2dth-0003CW-Lp; Tue, 09 Aug 2005 19:52:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2dtg-0003CR-9Q
	for simple@megatron.ietf.org; Tue, 09 Aug 2005 19:52:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24397
	for <simple@ietf.org>; Tue, 9 Aug 2005 19:52:34 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2eRe-0002yJ-Dd
	for simple@ietf.org; Tue, 09 Aug 2005 20:27:46 -0400
Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net
	[141.153.198.113]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j79NqUQx026027
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Tue, 9 Aug 2005 19:52:30 -0400 (EDT)
Message-ID: <42F941C7.6000406@cs.columbia.edu>
Date: Tue, 09 Aug 2005 19:52:39 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F932E4.4010004@cisco.com>
In-Reply-To: <42F932E4.4010004@cisco.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: 31247fb3be228bb596db9127becad0bc
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Paul Kyzivat wrote:
> 
> You have mentioned the desire to ignore the difference between sip and 
> sips. This probably makes sense, at least most of the time. (But not 
> always - you may only want to grant full access to your presence state, 
> with sensitive info, over a sips connection.)




> 
> Also, schemes are more than just distinct namespaces. There are 
> significant differences from scheme to scheme about how equivalence of 
> names is defined. Tel URIs must be compared differently for equivalence 
> than sip (user=ip) URIs. Separator characters must be ignored, and 
> parameters must be properly compared. (e.g. phone-context).

I don't think there's any disagreement that E.164-style and 
user@host-style URIs are sufficiently different that treating them as 
the same space is not likely to be productive or intuitive.


> 
> Just as sip and sips URIs might be considered equivalent for purposes of 
> identity equivalence, so may tel and sip/sips;user=phone. It seems many 
> people prefer to use sip URIs for phone numbers, using whatever domain 
> name is handy for them. This can cause a huge mess in determining 
> equivalence. Technically one should not consider to sip URIs with 
> different domains to be equivalent even if they both seem to represent 
> the same phone number, and it gives me heartburn to suggest doing so, 
> but pragmatically I think it must probably be supported. Specifically, I 
> think all the following need to be considered equivalent:
> 
>     tel:+1-555-987-6543
>     tel:+15559876543
>     sip:+1(555)987.6543@foo.com;user=phone
>     sip:+15.55.98.76.543@bar.net;user=phone

This seems like an item for the 'ID management' document to consider.


> 
> If we don't get this right, people will end up not being able to set 
> policy for callers without understanding how the caller is identified 
> from each different device he uses. If you end up needing a call log to 
> figure out how your callers are identified before you can authorize 
> them, then the system will be nearly unusable.

I fully agree. This discussion is very much tied to the 'ID management' 
draft discussion. I'm on the "usability" hobby horse these days, but I 
think in general, these equivalences should be as consistent as 
possible. It is very confusing if two identifiers are treated the same 
in one context and then suddenly differ in another - unless there's some 
explicit "loose/strict" flag or other obvious indication.


> 
> We also talked last week about wildcarding. I think there will be 
> demand/need for this. Things like:
> 
>     tel:+1-900-nnn-nnnn
> 
> Even this assumes that global form numbers are being used. Various forms 
> of dial strings make more of a mess. But lets not discuss that for now.

How useful is this likely to be, at least for presence and access to geo 
information?

Would we need to support the equivalent for domains, so that

domain="cisco.com"

matches

cisco.com
engineering.cisco.com
host17.engineering.cisco.com

[and other permutations]
?




_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 05:57:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2nKg-0007nA-RE; Wed, 10 Aug 2005 05:57:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nKe-0007mJ-MJ
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 05:57:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17344
	for <simple@ietf.org>; Wed, 10 Aug 2005 05:57:06 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2nsi-0000ij-O6
	for simple@ietf.org; Wed, 10 Aug 2005 06:32:22 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7A9uoYo009311; Wed, 10 Aug 2005 12:56:55 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 10 Aug 2005 12:56:56 +0300
Received: from [172.21.38.245] ([172.21.38.245]) by esebh001.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Wed, 10 Aug 2005 12:56:57 +0300
Message-ID: <42F9CF66.2070604@nokia.com>
Date: Wed, 10 Aug 2005 12:56:54 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu>
In-Reply-To: <42F61879.1000207@cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Aug 2005 09:56:57.0156 (UTC)
	FILETIME=[D81D8840:01C59D91]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I kind of grew fond of the idea Cullen and I came up with in a private 
conversation, namely treating telephone numbers as domains similar to 
when issuing a DNS ENUM query.

In essence, to match +1-232-555-1234, you'd have an identity conditions 
such as:

<many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />

This has an interesting additional property of being able to match based 
on country code, area code, etc. For example, to match all Finnish 
telephone numbers, you'd have:

<many domain="8.5.3.e164.arpa" />

Not being an expert on ENUM or E.164 in general, I suspect this is 
horribly broken, but it pleases the aesthethic eye.

Cheers,
Aki

ext Henning Schulzrinne wrote:
> In a side conversation, Hannes suggested a solution to the tel URI 
> problem we discussed during the WG meeting, akin to what's done in the 
> geopriv coordinate system parameter, namely to have a parameter that 
> identifies the scheme, as in
> 
> <one scheme="tel" id="+1-212-555-1234"/>
> 
> or
> 
> <one scheme="sip" id="alice@example.com"/>
> 
> if you really only want to match SIP identity sip:alice@example.com.
> 
> The default with no scheme parameter is "matches any user@domain scheme".
> 
> In order to complete finishing the section of the spec, I'd value quick 
> feedback on the idea.
> 
> 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 Wed Aug 10 07:33:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2opf-0000Mf-D7; Wed, 10 Aug 2005 07:33:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2opc-0000Ij-EI
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 07:33:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21027
	for <simple@ietf.org>; Wed, 10 Aug 2005 07:33:11 -0400 (EDT)
Received: from seldrel01.sonyericsson.com ([212.209.106.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2pNh-00039c-RW
	for simple@ietf.org; Wed, 10 Aug 2005 08:08:27 -0400
Received: from seldrel01.sonyericsson.com(212.209.106.2) by
	seldrel01.sonyericsson.com via smtp
	id 2ae1_cc27842e_0992_11da_97c0_0002b3a9a21a;
	Wed, 10 Aug 2005 13:35:06 +0200
Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by
	seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 10 Aug 2005 13:32:51 +0200
Received: from SELDCON01.corpusers.net ([10.129.0.26]) by
	seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 10 Aug 2005 13:32:51 +0200
Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by
	SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 10 Aug 2005 13:32:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 10 Aug 2005 13:32:50 +0200
Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
Thread-Topic: XCAP and its problem with Namespaces caused by using only the
	XML fragment body.
Thread-Index: AcWdnz2DXG4XDnX0RFiD1PpI60mxXg==
From: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 10 Aug 2005 11:32:51.0120 (UTC)
	FILETIME=[3DBEC300:01C59D9F]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186
Subject: [Simple] XCAP and its problem with Namespaces caused by using only
	the XML fragment body.
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0275884498=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0275884498==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C59D9F.3D868BF0"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C59D9F.3D868BF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
=20
As I see it there is a major problem with retrieving elements in an XML
document using XCAP. The problem has to do with that the XDM clients has
to know all the namespace prefix bindings in the server document prio
the fetch of an element.
=20
The problem is that the current XCAP specification only mandates that a
XCAP fragment body is sent between server and client when performing
XCAP operations. Not being an fcs document with the fragment context
specification leads to problems now when the XCAP URL has been made
independent of the namespaces prefixes used in the document on the
server.
=20
The XML data returned in the 200 OK answer on a fetch of an element will
contain the exact content of that element in the XML document on the
server. If this element or any child elements use namespace prefixes
declared earlier in the document they will not be included in the
response to the client. Hence the only way to know all the prefixes is
to have done a fetch of the whole document.

Just to clarify the problem I have made these examples (inspiration from
the XCAP specification..)
=20
Bill has not fetched the whole server document, and it looks like this:
=20
   <?xml version=3D"1.0" encoding=3D"UTF-8"?>
   <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
      xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
      xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance> ">
    <service uri=3D"sip:marketing@example.com">
      <a:list name=3D"marketing">
        <a:entry uri=3D"sip:joe@example.com"/>
        <a:entry uri=3D"sip:sudhir@example.com"/>
      </a:list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
   </rls-services>
=20

Bill decides to get the service information for uri
sip:marketing@example.com
=20
   GET
   /rls-services/users/bill/index/~~/rls-services/
   service%5b@uri=3D%22sip:marketing@example.com%5d
<mailto:service%5b@uri=3D%22sip:marketing@example.com%5d>=20
    HTTP/1.1
=20
   and the server responds:
=20
   HTTP/1.1 200 OK
   Etag: "ad88"
   Content-Type:application/xcap-el+xml
=20
    <service uri=3D"sip:marketing@example.com">
      <a:list name=3D"marketing">
        <a:entry uri=3D"sip:joe@example.com"/>
        <a:entry uri=3D"sip:sudhir@example.com"/>
      </a:list>
      <packages>
        <package>presence</package>
      </packages>
    </service>
=20
Bill is now confused as he has no idea what namespace the tags that are
using the namespace prefix a: belongs to, so he has to fetch the whole
document to find out....
=20
=20
Also as disscussed earlier:
http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html
<http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html>
the XDM client has to always send the xmlns declaration with the XML
elements that are sent in a PUT in order to be sure that it will be a
valid part of the complete XML document on the server..
=20
This would be a situation where the client would have a problem if the
xmlns declaration is missing in the XML fragment body:

The server document looks like this:
=20
   <?xml version=3D"1.0" encoding=3D"UTF-8"?>
   <a:resource-lists xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
    xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
    <a:list name=3D"close-friends">
     <a:display-name>Close Friends</a:display-name>
     <a:entry uri=3D"sip:joe@example.com">
      <a:display-name>Joe Smith</a:display-name>
     </a:entry>
    </a:list>
   </a:resource-lists>
=20
Bill creates an element in the resource-lists document (Section 7.4).
In particular, he creates a list with an entry:

   PUT
   /services/resource-lists/users/bill/fr.xml
   /~~/resource-lists/list%5b@name=3D%22friends%22%5d HTTP/1.1
   Content-Type:application/xcap-el+xml
   Host: xcap.example.com
=20
   <list name=3D"friends">
     <entry uri=3D"sip:bob@example.com">
       <display-name>Bob Jones</display-name>
     </entry>
   </list>
=20
Bill will cry as the validation of the document after the tentatively
insertion will fail as this will produce a invalid XML document..
=20
=20

/Per
=20
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 (MSN/E-mail)=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.

=20

------_=_NextPart_001_01C59D9F.3D868BF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1506" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3D"Courier New" size=3D2>Hello,</FONT></DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>As I see it there is a major =
problem with=20
retrieving elements in an XML document using XCAP. The problem has to do =
with=20
that the XDM clients has to know all the namespace prefix bindings in =
the server=20
document prio the fetch of an element.</FONT></DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>The problem is that the current =
XCAP=20
specification only mandates that a XCAP fragment body is sent between =
server and=20
client when performing XCAP operations. Not being an fcs document with =
the=20
fragment context specification leads to problems now when the XCAP URL =
has been=20
made independent of the namespaces prefixes used in the document on the=20
server.</FONT></DIV>
<DIV><FONT face=3D"Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>The XML data returned in the =
200 OK answer=20
on a fetch of an element will contain the exact content of that element =
in the=20
XML document on the server. If this element or any child elements use =
namespace=20
prefixes declared earlier in the document they will not be included in =
the=20
response to the client. Hence the only way to know all the prefixes is =
to have=20
done a fetch of the whole document.</FONT></DIV>
<DIV><FONT face=3DArial></FONT><BR><FONT face=3D"Courier New" =
size=3D2>Just to clarify=20
the problem I have made these examples (inspiration from the XCAP=20
specification..)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D654291011-10082005><FONT face=3D"Courier New" =
size=3D2>Bill has not=20
fetched the whole server document, and it&nbsp;l</FONT></SPAN><FONT=20
face=3D"Courier New" size=3D2>ooks like this:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; &lt;?xml =
version=3D"1.0"=20
encoding=3D"UTF-8"?&gt;<BR>&nbsp;&nbsp; &lt;rls-services=20
xmlns=3D"urn:ietf:params:xml:ns:rls-services"<BR>&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"<BR>&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
xmlns:xsi=3D"</FONT><A =
href=3D"http://www.w3.org/2001/XMLSchema-instance"><FONT=20
face=3D"Courier New"=20
size=3D2>http://www.w3.org/2001/XMLSchema-instance</FONT></A><FONT=20
face=3D"Courier New" size=3D2>"&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;service=20
uri=3D"sip:marketing@example.com"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;a:list=20
name=3D"marketing"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;a:entry=20
uri=3D"sip:joe@example.com"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
&lt;a:entry =
uri=3D"sip:sudhir@example.com"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/a:list&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;packages&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;package&gt;presence&lt;/package&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
&lt;/packages&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;/service&gt;<BR>&nbsp;&nbsp; =

&lt;/rls-services&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR><FONT face=3D"Courier New" =
size=3D2>Bill=20
decides to get the service information for uri=20
sip:marketing@example.com</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; =
GET<BR>&nbsp;&nbsp;=20
/rls-services/users/bill/index/~~/rls-services/<BR>&nbsp;&nbsp; =
</FONT><A=20
href=3D"mailto:service%5b@uri=3D%22sip:marketing@example.com%5d"><FONT=20
face=3D"Courier New"=20
size=3D2>service%5b@uri=3D%22sip:marketing@example.com%5d</FONT></A><BR><=
FONT=20
face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; HTTP/1.1</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; and the server=20
responds:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; HTTP/1.1 200=20
OK<BR>&nbsp;&nbsp; Etag: "ad88"<BR>&nbsp;&nbsp;=20
Content-Type:application/xcap-el+xml</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp; &lt;service=20
uri=3D"sip:marketing@example.com"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;a:list=20
name=3D"marketing"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;a:entry=20
uri=3D"sip:joe@example.com"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
&lt;a:entry =
uri=3D"sip:sudhir@example.com"/&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/a:list&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;packages&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;package&gt;presence&lt;/package&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
=20
&lt;/packages&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;/service&gt;</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Bill is now confused as he has =
no idea what=20
namespace the tags that are using the namespace prefix a: belongs to, so =
he has=20
to fetch the whole document to find out....</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D654291011-10082005><FONT face=3D"Courier New" =
size=3D2>Also as=20
disscussed earlier: </FONT></SPAN><A=20
href=3D"http://www1.ietf.org/mail-archive/web/simple/current/msg04937.htm=
l"><FONT=20
face=3D"Courier New"=20
size=3D2>http://www1.ietf.org/mail-archive/web/simple/current/msg04937.ht=
ml</FONT></A><FONT=20
face=3D"Courier New"><FONT size=3D2>&nbsp;<SPAN =
class=3D654291011-10082005>the XDM=20
client has to always send the xmlns declaration with the XML elements =
that are=20
sent in a PUT in order to be sure that it will be a valid part of the =
complete=20
XML document on the server..</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN=20
class=3D654291011-10082005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New"><FONT size=3D2><SPAN =
class=3D654291011-10082005>This=20
would be a situation where the client would have a problem if the xmlns=20
declaration is missing in the XML fragment =
body:</SPAN></FONT></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><BR>The server document looks =
like=20
this:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; &lt;?xml =
version=3D"1.0"=20
encoding=3D"UTF-8"?&gt;<BR>&nbsp;&nbsp; &lt;a:resource-lists=20
xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"<BR>&nbsp;&nbsp;&nbsp;=20
xmlns:xsi=3D"<A=20
href=3D"http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001=
/XMLSchema-instance</A>"&gt;<BR>&nbsp;&nbsp;&nbsp;=20
&lt;a:list name=3D"close-friends"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;a:display-name&gt;Close=20
Friends&lt;/a:display-name&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; &lt;a:entry=20
uri=3D"sip:joe@example.com"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;a:display-name&gt;Joe=20
Smith&lt;/a:display-name&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/a:entry&gt;<BR>&nbsp;&nbsp;&nbsp; &lt;/a:list&gt;<BR>&nbsp;&nbsp;=20
&lt;/a:resource-lists&gt;</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Bill creates an element in the=20
resource-lists document (Section 7.4).&nbsp; In particular, he creates a =
list=20
with an entry:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><FONT =
face=3DArial></FONT><BR>&nbsp;&nbsp;=20
PUT<BR>&nbsp;&nbsp; =
/services/resource-lists/users/bill/fr.xml<BR>&nbsp;&nbsp;=20
<A>/~~/resource-lists/list%5b@name=3D%22friends%22%5d</A> =
HTTP/1.1<BR>&nbsp;&nbsp;=20
Content-Type:application/xcap-el+xml<BR>&nbsp;&nbsp; Host:=20
xcap.example.com</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; &lt;list =
name=3D"friends"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;entry =
uri=3D"sip:bob@example.com"&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;display-name&gt;Bob =
Jones&lt;/display-name&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
&lt;/entry&gt;<BR>&nbsp;&nbsp; &lt;/list&gt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Bill will cry as the validation of the document after the =
tentatively=20
insertion will fail as this will produce a invalid XML document..</DIV>
<DIV></FONT><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><BR><FONT face=3D"Courier New" size=3D2>/Per</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><B><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Verdana">Per=20
Hyttfors</SPAN></B> <BR><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: gray; FONT-FAMILY: =
Verdana">___________________________________________________________</SPA=
N>=20
<BR><SPAN style=3D"FONT-SIZE: 8pt; COLOR: teal; FONT-FAMILY: =
Verdana">Development=20
Engineer - Messaging Application Development</SPAN> <BR><B><SPAN=20
style=3D"FONT-SIZE: 9pt; COLOR: teal; FONT-FAMILY: Verdana">Sony =
Ericsson Mobile=20
Communications AB</SPAN></B> <BR><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Verdana">SE-221 88 =
Lund,=20
Sweden</SPAN> <BR><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: Verdana">+46 46 =
2126534</SPAN>=20
<BR><SPAN=20
style=3D"FONT-SIZE: 8pt; COLOR: gray; FONT-FAMILY: =
Verdana">per.hyttfors@sonyericsson.com=20
(MSN/E-mail)</SPAN> <BR><SPAN=20
style=3D"FONT-SIZE: 7pt; COLOR: gray; FONT-FAMILY: =
Verdana">___________________________________________________________</SPA=
N>=20
</DIV>
<P><SPAN style=3D"FONT-SIZE: 7pt; COLOR: gray; FONT-FAMILY: Verdana">The =

information in this email, and attachment(s) thereto, is strictly =
confidential=20
and may be legally privileged. It is intended solely for the named =
recipient(s),=20
and access to this e-mail, or any attachment(s) thereto, by anyone else =
is=20
unauthorized. Violations hereof may result in legal actions. Any =
attachment(s)=20
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=20
name and address to facilitate communications in the matter concerned. =
If you do=20
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=20
inform the sender by replying to this transmission, and delete the =
e-mail, its=20
attachment(s), and any copies of it without, disclosing it.</SPAN></P>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C59D9F.3D868BF0--


--===============0275884498==
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

--===============0275884498==--




From simple-bounces@ietf.org Wed Aug 10 07:40:02 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2owE-0001wT-Fj; Wed, 10 Aug 2005 07:40:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2owD-0001w4-1t
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 07:40:01 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21259
	for <simple@ietf.org>; Wed, 10 Aug 2005 07:40:00 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2pUH-0003I7-Mn
	for simple@ietf.org; Wed, 10 Aug 2005 08:15:15 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7ABdviR002231 for <simple@ietf.org>; Wed, 10 Aug 2005 14:39:57 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 10 Aug 2005 14:39:57 +0300
Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 10 Aug 2005 14:39:57 +0300
Received: from 172.21.36.244 ([172.21.36.244]) by esebe102.NOE.Nokia.com
	([172.21.138.217]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 10 Aug 2005 11:39:57 +0000
Received: from hed040-040103.research.nokia.com by esebe102;
	10 Aug 2005 14:39:56 +0300
From: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
To: simple@ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: Nokia-NRC/Helsinki
Message-Id: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-14) 
Date: Wed, 10 Aug 2005 14:39:56 +0300
X-OriginalArrivalTime: 10 Aug 2005 11:39:57.0066 (UTC)
	FILETIME=[3BA0F6A0:01C59DA0]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Content-Transfer-Encoding: 7bit
Subject: [Simple] Questions regarding MSRP drafts
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

	Hello,

I'm new here. Below are a few non-editorial concerns I have encountered
with draft-ietf-simple-message-sessions-11 and
draft-ietf-simple-msrp-relays-05.

Sessions and connections
-------------------------

  draft-ietf-simple-message-sessions-11 mandates that clients only use
one connection for a given session. Besides, these are supposed to
reject any request belonging to a session that is already attached to
another TCP connection that the one the request came from. That is not
only good for security's sake, but also helps TCP congestion detection
work properly.

  It might be a good idea to explicit that relays do have to obey this
requirement as well, otherwise last-hop MSRP connections may fail. Also
a policy in case of TCP connection failure ought to to be defined:
 - stall all attached sessions (like in the case of client), or,
 - keep trying to establish a new connection for sometime and, if
 successful, retransmit all requests until, not including, the last one
 that was acknolegded somehow, or,
 - something else...


Re-ordering
------------

  Given chunks are sent in order, there are two reasons why chunks might
be seem disordered at the receiving endpoint:
 - chunk loss if an intermediary relay-to-relay connection failed,
 - use of multiple TCP connections for the same hop.

  Both problems are specific to the use of MSRP relays, i.e. ALG.
Because there is no receive window in MSRP, end point should accept
chunks way ahead of the current offset of orderly received data for a
given message.
  In practice, it can probably be assumed that MSRP-using software will
expect ordered data, like TCP-using software expects the IP stack to
perform re-ordering transparently. Without receive window, the receiving
end point could easily be made memory exhausted, as someone could
(purposedly or not) not send a given chunk, of a very long message and
force the MSRP layer into queuing a huge amount of data in its input
buffer. This problem is actually very likely to show up in case a chunk
is lost, but the sender is not notified (e.g., if it doesn't want to).

  To avoid the problem, the receiver is bound to send a defensive 413
error and stall the entire message.

  It is unclear to me whether relays have to use a single TCP connection
for every requests belonging to a given session (while that is
explicitly what clients have to do). I however assume they have to (see
previous note).
  Then why not mandate that relays do NOT re-order chunks. That is,
relays would have to forward all SEND requests in the same order has
they received them (do not actually have to check Byte-Range for that).
Splitting requests into smaller chunk can still be allowed. By the way,
that also helps the sender decide how to prioritize multiple messages in
the same session. If I am not mistaken that is sufficient to ensure that
reordering will never happen and need not be supported by MSRP clients.


Buffer overwriting
-------------------

  draft-ietf-simple-message-sessions-11 recommends that, in case of
chunk retransmit, the end point overwrites already received data with
newly received one. While it is only a SHOULD, there does not seem to be
any reason for this. It is illegal to receive new data that would not
match previously received chunks anyway. Actually, I'd rather consider
this as the sign of a hack attempt. So why should clients do that?



Slow hop after two relays
--------------------------

  If the first relay (I mean, that directly after the sender) detects a
slow/congested link with the subsequent hop, it may stop dequeuing TCP
data from the client. However, that could negatively impact other faster
sessions between the client and other peers.

  If a relay that is not directly after the sender, the only way to
handle a slow downstream connection is to store requests and responses
in some buffer. Otherwise, it would be open to a trivial DoS whereby a
fast malicious client behind a "major" entity (typically an ISP) relay
sends a lot of data to be relayed to a purposedly slow receiver behind
another major entity relay. The TCP connection between the second relay
and the slow receiver would quickly fulfill its TCP window.

  MSRP is meant to allow forwarding of huge files. In the current draft,
the example of a gigabyte-worth message is eventually provided. On the
one hand, buffering such a big amount of data for a single message is
obviously inappropriate. On the other hand, returning an error that the
message is too big to be queued is not satisfying given the
applicability of the MSRP drafts. IMHO, that needs to be addressed
somehow.

  One solution would be to redesign MSRP relays so that they work more
like HTTP CONNECT proxying, or SOCK servers, that is, blindly forwards
data between two TCP connections, and leave it up to the TCP/IP stack to
handle congestion end-to-end.
  Other advantages of this solution include relying on TCP for
retransmission and reordering, making REPORT acknowledgement
potentialy much simpler and less costly, and allowing end-to-end TLS for
security's sake.
  The main limitation is the need for a reverse connection proxy, such
as draft-rosenberg-midcom-turn-08.

  An alternative would consist of allowing relays to drop chunk if they
want to, recommending that partial Failure-Report be always used for big
messages, and allowing the sender to retransmit chunk (or is that
allowed already?).
  However, this is very much like reimplementing sort of TCP on top of
TCP, which is probably highly suboptimal.

  Another alternative is to mandate the use of a limited window (say
64k) that would be the biggest amount of bytes a sender can safely send
without receiving REPORTs acknowledgements. That implies mandating some
kind of positive acknowledgement from the receiver (at the moment, it is
only mandatory at the end of a full message).
  Also, both alternatives could probably be mixed together. Again, that
sounds like reimplementing TCP on top of TCP.


No 500 error code
------------------

  There is no error code like 500 in other protocols to tell the other
side than processing its request failed for a reason that is independant
from the protocol itself (too busy, not enough memory, etc).

-- 
Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Nokia-NRC/Helsinki

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 08:02:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2pIN-0007nr-Pz; Wed, 10 Aug 2005 08:02:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pIN-0007n1-09
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 08:02:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22408
	for <simple@ietf.org>; Wed, 10 Aug 2005 08:02:53 -0400 (EDT)
Received: from serrano.cc.columbia.edu ([128.59.29.6] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2pqT-0003t1-GX
	for simple@ietf.org; Wed, 10 Aug 2005 08:38:09 -0400
Received: from [192.168.0.31] (pool-141-153-198-113.mad.east.verizon.net
	[141.153.198.113]) (user=hgs10 mech=PLAIN bits=0)
	by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id j7AC2mUR006177
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 10 Aug 2005 08:02:49 -0400 (EDT)
Message-ID: <42F9ED00.7000600@cs.columbia.edu>
Date: Wed, 10 Aug 2005 08:03:12 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Aki Niemi <aki.niemi@nokia.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
In-Reply-To: <42F9CF66.2070604@nokia.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: 0.2 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Aki,

I have a few concerns about this:

- user interface: ENUM-style identifiers are not exactly the most 
user-friendly domain names, given the reversal of digits; I suspect that 
in many cases, applications will generate the rules, but probably not in 
all cases.

- confusion: There's lots of talk about carrier ENUM, using TLDs other 
than e164.arpa. I suspect we'd see "my number is in e164.org, so let me 
use that postfix instead".

- user expectation: it seems that a user would expect the ENUM entry to 
exist if one specifies the domain name; this is not likely to be the case;

- consistency: the presence of a "domain" parameter signals that this 
has 'id' entries with user names in that domain. This clearly makes no 
sense here.

I don't see which problem this would solve compared to the scheme 
parameter proposal. You'd still have to flag the domain as being 
"special", as "sip:alice@4.3.2.1.5.5.5.2.3.2.1.e164.arpa" doesn't make a 
whole lot of sense.

Henning


Aki Niemi wrote:
> Hi,
> 
> I kind of grew fond of the idea Cullen and I came up with in a private 
> conversation, namely treating telephone numbers as domains similar to 
> when issuing a DNS ENUM query.
> 
> In essence, to match +1-232-555-1234, you'd have an identity conditions 
> such as:
> 
> <many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
> 
> This has an interesting additional property of being able to match based 
> on country code, area code, etc. For example, to match all Finnish 
> telephone numbers, you'd have:
> 
> <many domain="8.5.3.e164.arpa" />
> 
> Not being an expert on ENUM or E.164 in general, I suspect this is 
> horribly broken, but it pleases the aesthethic eye.

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 14:19:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2vAU-0008CU-6k; Wed, 10 Aug 2005 14:19:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vAT-0008CO-B1
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 14:19:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15063
	for <simple@ietf.org>; Wed, 10 Aug 2005 14:19:08 -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.43)
	id 1E2vid-0006cl-3O
	for simple@ietf.org; Wed, 10 Aug 2005 14:54:27 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 10 Aug 2005 11:19:00 -0700
X-IronPort-AV: i="3.96,97,1122879600"; 
	d="scan'208"; a="330888968:sNHT32559892"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7AIIsoq018121;
	Wed, 10 Aug 2005 11:18:57 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 10 Aug 2005 14:18:39 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 14:18:39 -0400
Message-ID: <42FA44FE.7020703@cisco.com>
Date: Wed, 10 Aug 2005 14:18:38 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Aki Niemi <aki.niemi@nokia.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Aug 2005 18:18:39.0312 (UTC)
	FILETIME=[EE660500:01C59DD7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org, ext Henning Schulzrinne <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Aki,



Aki Niemi wrote:
> Hi,
> 
> I kind of grew fond of the idea Cullen and I came up with in a private 
> conversation, namely treating telephone numbers as domains similar to 
> when issuing a DNS ENUM query.
> 
> In essence, to match +1-232-555-1234, you'd have an identity conditions 
> such as:
> 
> <many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />

Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?

I don't think you can convert it to:

    4.3.2.1.5.5.5.2.3.2.1.foo.com

and if you could then it it wouldn't match the e164.arpa form.

> This has an interesting additional property of being able to match based 
> on country code, area code, etc. For example, to match all Finnish 
> telephone numbers, you'd have:
> 
> <many domain="8.5.3.e164.arpa" />

It only does if you declare that a domain matches anything it is the 
tail of. You may sometimes want that, but I don't think you do in general.

	Paul

> Not being an expert on ENUM or E.164 in general, I suspect this is 
> horribly broken, but it pleases the aesthethic eye.
> 
> Cheers,
> Aki
> 
> ext Henning Schulzrinne wrote:
> 
>> In a side conversation, Hannes suggested a solution to the tel URI 
>> problem we discussed during the WG meeting, akin to what's done in the 
>> geopriv coordinate system parameter, namely to have a parameter that 
>> identifies the scheme, as in
>>
>> <one scheme="tel" id="+1-212-555-1234"/>
>>
>> or
>>
>> <one scheme="sip" id="alice@example.com"/>
>>
>> if you really only want to match SIP identity sip:alice@example.com.
>>
>> The default with no scheme parameter is "matches any user@domain scheme".
>>
>> In order to complete finishing the section of the spec, I'd value 
>> quick feedback on the idea.
>>
>> 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 Wed Aug 10 14: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 1E2vbn-0000My-9D; Wed, 10 Aug 2005 14: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 1E2vbi-0000MU-RA
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 14:47:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17418
	for <simple@ietf.org>; Wed, 10 Aug 2005 14:47:17 -0400 (EDT)
Message-Id: <200508101847.OAA17418@ietf.org>
Received: from dx28.winwebhosting.com ([70.85.77.84])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2w9s-0007iF-Tl
	for simple@ietf.org; Wed, 10 Aug 2005 15:22:37 -0400
Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41xp)
	by dx28.winwebhosting.com with esmtpa (Exim 4.52)
	id 1E2vbB-0001TV-JN; Wed, 10 Aug 2005 13:46:45 -0500
From: "Brian Rosen" <br@brianrosen.net>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, "'Aki Niemi'" <aki.niemi@nokia.com>
Subject: RE: [Simple] tel URIs in common policy
Date: Wed, 10 Aug 2005 14:46:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <42FA44FE.7020703@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcWd2DIpsgu8HBJORLuRokaO8lloIAAAb3CQ
X-AntiAbuse: This header was added to track abuse,
	please include it with any abuse report
X-AntiAbuse: Primary Hostname - dx28.winwebhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - brianrosen.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org, 'ext Henning Schulzrinne' <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Paul

Not sure yet what I think of the basic idea, but
   sip:+1-232-1234@foo.com;user=phone
should be equivalent to
   tel:+1-232-1234

So I think you CAN convert it to "enum" form.

You might have more problems with
   sip:1234@foo.com

That may be equivalent to
   tel:1234;phone-context=foo.com
but you don't know that a priori.

Brian

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Wednesday, August 10, 2005 2:19 PM
To: Aki Niemi
Cc: simple@ietf.org; ext Henning Schulzrinne
Subject: Re: [Simple] tel URIs in common policy

Aki,



Aki Niemi wrote:
> Hi,
> 
> I kind of grew fond of the idea Cullen and I came up with in a private 
> conversation, namely treating telephone numbers as domains similar to 
> when issuing a DNS ENUM query.
> 
> In essence, to match +1-232-555-1234, you'd have an identity conditions 
> such as:
> 
> <many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />

Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?

I don't think you can convert it to:

    4.3.2.1.5.5.5.2.3.2.1.foo.com

and if you could then it it wouldn't match the e164.arpa form.

> This has an interesting additional property of being able to match based 
> on country code, area code, etc. For example, to match all Finnish 
> telephone numbers, you'd have:
> 
> <many domain="8.5.3.e164.arpa" />

It only does if you declare that a domain matches anything it is the 
tail of. You may sometimes want that, but I don't think you do in general.

	Paul

> Not being an expert on ENUM or E.164 in general, I suspect this is 
> horribly broken, but it pleases the aesthethic eye.
> 
> Cheers,
> Aki
> 
> ext Henning Schulzrinne wrote:
> 
>> In a side conversation, Hannes suggested a solution to the tel URI 
>> problem we discussed during the WG meeting, akin to what's done in the 
>> geopriv coordinate system parameter, namely to have a parameter that 
>> identifies the scheme, as in
>>
>> <one scheme="tel" id="+1-212-555-1234"/>
>>
>> or
>>
>> <one scheme="sip" id="alice@example.com"/>
>>
>> if you really only want to match SIP identity sip:alice@example.com.
>>
>> The default with no scheme parameter is "matches any user@domain scheme".
>>
>> In order to complete finishing the section of the spec, I'd value 
>> quick feedback on the idea.
>>
>> 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



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 16:02:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2wml-0007oP-7f; Wed, 10 Aug 2005 16:02:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2wmj-0007nN-LQ
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 16:02:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27328
	for <simple@ietf.org>; Wed, 10 Aug 2005 16:02:43 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xKt-000392-OS
	for simple@ietf.org; Wed, 10 Aug 2005 16:38:04 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2005 16:02:40 -0400
X-IronPort-AV: i="3.96,97,1122868800"; d="scan'208"; a="66040858:sNHT31853508"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7AK2IR5007844; 
	Wed, 10 Aug 2005 16:02:37 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 10 Aug 2005 16:02:29 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:02:29 -0400
Message-ID: <42FA5D55.9070600@cisco.com>
Date: Wed, 10 Aug 2005 16:02:29 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Brian Rosen <br@brianrosen.net>
Subject: Re: [Simple] tel URIs in common policy
References: <40qjfr$2mcqkp@sj-inbound-b.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Aug 2005 20:02:29.0463 (UTC)
	FILETIME=[6FDB9E70:01C59DE6]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Content-Transfer-Encoding: 7bit
Cc: 'ext Henning Schulzrinne' <hgs@cs.columbia.edu>,
	'Aki Niemi' <aki.niemi@nokia.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Brian,

Brian Rosen wrote:
> Paul
> 
> Not sure yet what I think of the basic idea, but
>    sip:+1-232-1234@foo.com;user=phone
> should be equivalent to
>    tel:+1-232-1234

Well, I am suggesting that, when the purpose is identifying a caller for 
purposes of authorization.

According to 3261, only someone responsible for the foo.com domain can 
decide that these are equivalent. If you are not responsible for that 
domain then you are not permitted to conclude they are equivalent. So I 
am in some sense advocating violating 3261 in this case.

Unless we plan to change 3261, or look the other way while people 
violate it, this is a fundamental problem with using sip;user=phone 
address forms.

> So I think you CAN convert it to "enum" form.

According to sip routing rules, if you are not responsible for the 
foo.com domain, you *definitely* can't do this to route the sip address! 
You must simply route it based on the domain name.

I see this as a key difference between the two forms. With the tel form, 
anybody can just go to the PSTN, or use enum to find possible ways of 
reaching it. With the sip form, you can only reach the address via sip.

> You might have more problems with
>    sip:1234@foo.com
> 
> That may be equivalent to
>    tel:1234;phone-context=foo.com
> but you don't know that a priori.

There is certainly nothing written down anywhere that would lead you to 
believe you could do that. If it can be done, it is only on a 
domain-specific basis, and so can only be done by someone responsible 
for the domain.

	Paul

> Brian
> 
> -----Original Message-----
> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
> Paul Kyzivat
> Sent: Wednesday, August 10, 2005 2:19 PM
> To: Aki Niemi
> Cc: simple@ietf.org; ext Henning Schulzrinne
> Subject: Re: [Simple] tel URIs in common policy
> 
> Aki,
> 
> 
> 
> Aki Niemi wrote:
> 
>>Hi,
>>
>>I kind of grew fond of the idea Cullen and I came up with in a private 
>>conversation, namely treating telephone numbers as domains similar to 
>>when issuing a DNS ENUM query.
>>
>>In essence, to match +1-232-555-1234, you'd have an identity conditions 
>>such as:
>>
>><many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
> 
> 
> Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?
> 
> I don't think you can convert it to:
> 
>     4.3.2.1.5.5.5.2.3.2.1.foo.com
> 
> and if you could then it it wouldn't match the e164.arpa form.
> 
> 
>>This has an interesting additional property of being able to match based 
>>on country code, area code, etc. For example, to match all Finnish 
>>telephone numbers, you'd have:
>>
>><many domain="8.5.3.e164.arpa" />
> 
> 
> It only does if you declare that a domain matches anything it is the 
> tail of. You may sometimes want that, but I don't think you do in general.
> 
> 	Paul
> 
> 
>>Not being an expert on ENUM or E.164 in general, I suspect this is 
>>horribly broken, but it pleases the aesthethic eye.
>>
>>Cheers,
>>Aki
>>
>>ext Henning Schulzrinne wrote:
>>
>>
>>>In a side conversation, Hannes suggested a solution to the tel URI 
>>>problem we discussed during the WG meeting, akin to what's done in the 
>>>geopriv coordinate system parameter, namely to have a parameter that 
>>>identifies the scheme, as in
>>>
>>><one scheme="tel" id="+1-212-555-1234"/>
>>>
>>>or
>>>
>>><one scheme="sip" id="alice@example.com"/>
>>>
>>>if you really only want to match SIP identity sip:alice@example.com.
>>>
>>>The default with no scheme parameter is "matches any user@domain scheme".
>>>
>>>In order to complete finishing the section of the spec, I'd value 
>>>quick feedback on the idea.
>>>
>>>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
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 16:34:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E2xH6-0006Od-Ol; Wed, 10 Aug 2005 16:34:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E2xH4-0006Nu-J3
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 16:34:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01996
	for <simple@ietf.org>; Wed, 10 Aug 2005 16:34:04 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2xpF-00057h-3l
	for simple@ietf.org; Wed, 10 Aug 2005 17:09:25 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2005 16:33:40 -0400
X-IronPort-AV: i="3.96,97,1122868800"; 
	d="scan'208"; a="66045702:sNHT48111885110"
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 j7AKXATW016373; 
	Wed, 10 Aug 2005 16:33:37 -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, 10 Aug 2005 16:33:37 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 16:33:36 -0400
Message-ID: <42FA64A0.1020109@cisco.com>
Date: Wed, 10 Aug 2005 16:33:36 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Aug 2005 20:33:36.0899 (UTC)
	FILETIME=[C8EFBD30:01C59DEA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Remi,

Wish you had been around a year or so ago when most of the decisions 
were made. Comments inline.

	Paul

Remi Denis-Courmont wrote:
> 	Hello,
> 
> I'm new here. Below are a few non-editorial concerns I have encountered
> with draft-ietf-simple-message-sessions-11 and
> draft-ietf-simple-msrp-relays-05.
> 
> Sessions and connections
> -------------------------
> 
>   draft-ietf-simple-message-sessions-11 mandates that clients only use
> one connection for a given session. Besides, these are supposed to
> reject any request belonging to a session that is already attached to
> another TCP connection that the one the request came from. That is not
> only good for security's sake, but also helps TCP congestion detection
> work properly.
> 
>   It might be a good idea to explicit that relays do have to obey this
> requirement as well, otherwise last-hop MSRP connections may fail. Also

I'm not sure what you are suggesting here. Each endpoint has a single 
connection to its adjacent relay for any given session. It is only 
connections between relays that can come and go. And they *need* to be 
able to come and go since they have no visibility to or influence over 
session establishment.

> a policy in case of TCP connection failure ought to to be defined:
>  - stall all attached sessions (like in the case of client), or,
>  - keep trying to establish a new connection for sometime and, if
>  successful, retransmit all requests until, not including, the last one
>  that was acknolegded somehow, or,
>  - something else...

I don't remember what is in there now for this.

> Re-ordering
> ------------
> 
>   Given chunks are sent in order, there are two reasons why chunks might
> be seem disordered at the receiving endpoint:
>  - chunk loss if an intermediary relay-to-relay connection failed,
>  - use of multiple TCP connections for the same hop.
> 
>   Both problems are specific to the use of MSRP relays, i.e. ALG.
> Because there is no receive window in MSRP, end point should accept
> chunks way ahead of the current offset of orderly received data for a
> given message.
>   In practice, it can probably be assumed that MSRP-using software will
> expect ordered data, like TCP-using software expects the IP stack to
> perform re-ordering transparently. Without receive window, the receiving
> end point could easily be made memory exhausted, as someone could
> (purposedly or not) not send a given chunk, of a very long message and
> force the MSRP layer into queuing a huge amount of data in its input
> buffer. This problem is actually very likely to show up in case a chunk
> is lost, but the sender is not notified (e.g., if it doesn't want to).
> 
>   To avoid the problem, the receiver is bound to send a defensive 413
> error and stall the entire message.
> 
>   It is unclear to me whether relays have to use a single TCP connection
> for every requests belonging to a given session (while that is
> explicitly what clients have to do). I however assume they have to (see
> previous note).

I believe this is explicitly *not* required. It is generally a goal that 
relays need keep minimal state. Remembering all the sessions and their 
associated connection is a problem. Also, sessions could be up for a 
very long time (potentially days). While the connections at the ends are 
required, I don't think we would want to mandate that connections 
between relays be kept up in that case. So we have given relays 
permission to tear down connections between themselves when not active.

>   Then why not mandate that relays do NOT re-order chunks. That is,
> relays would have to forward all SEND requests in the same order has
> they received them (do not actually have to check Byte-Range for that).

The cases where reordering can occur are actually pretty obscure I 
think. (Somebody correct me if I am wrong.) The one I can think of is:

- Two connections between a pair of relays. Two messages from same 
connection get sent, one over each connection. The 1st message is very 
long, while the 2nd is very short. The last byte of the 2nd message may 
be received before the last byte of the first message. Then it gets 
forwarded on.

I suspect there are others, but maybe not. Could it be designed out of 
the protocol? I'm not sure. What I do know is that this protocol has 
been beat to death trying to solve everybody's favorite problem. We just 
want it to be done.

> Splitting requests into smaller chunk can still be allowed. By the way,
> that also helps the sender decide how to prioritize multiple messages in
> the same session. If I am not mistaken that is sufficient to ensure that
> reordering will never happen and need not be supported by MSRP clients.
> 
> 
> Buffer overwriting
> -------------------
> 
>   draft-ietf-simple-message-sessions-11 recommends that, in case of
> chunk retransmit, the end point overwrites already received data with
> newly received one. While it is only a SHOULD, there does not seem to be
> any reason for this. It is illegal to receive new data that would not
> match previously received chunks anyway. Actually, I'd rather consider
> this as the sign of a hack attempt. So why should clients do that?

I agree with you on this one. I wanted it to be an error for any 
overlapping data to differ from the original. (Without requiring that 
this error be detected.) But I was outvoted.

> Slow hop after two relays
> --------------------------
> 
>   If the first relay (I mean, that directly after the sender) detects a
> slow/congested link with the subsequent hop, it may stop dequeuing TCP
> data from the client. However, that could negatively impact other faster
> sessions between the client and other peers.
> 
>   If a relay that is not directly after the sender, the only way to
> handle a slow downstream connection is to store requests and responses
> in some buffer. Otherwise, it would be open to a trivial DoS whereby a
> fast malicious client behind a "major" entity (typically an ISP) relay
> sends a lot of data to be relayed to a purposedly slow receiver behind
> another major entity relay. The TCP connection between the second relay
> and the slow receiver would quickly fulfill its TCP window.
> 
>   MSRP is meant to allow forwarding of huge files. In the current draft,
> the example of a gigabyte-worth message is eventually provided. On the
> one hand, buffering such a big amount of data for a single message is
> obviously inappropriate. On the other hand, returning an error that the
> message is too big to be queued is not satisfying given the
> applicability of the MSRP drafts. IMHO, that needs to be addressed
> somehow.
> 
>   One solution would be to redesign MSRP relays so that they work more
> like HTTP CONNECT proxying, or SOCK servers, that is, blindly forwards
> data between two TCP connections, and leave it up to the TCP/IP stack to
> handle congestion end-to-end.
>   Other advantages of this solution include relying on TCP for
> retransmission and reordering, making REPORT acknowledgement
> potentialy much simpler and less costly, and allowing end-to-end TLS for
> security's sake.
>   The main limitation is the need for a reverse connection proxy, such
> as draft-rosenberg-midcom-turn-08.
> 
>   An alternative would consist of allowing relays to drop chunk if they
> want to, recommending that partial Failure-Report be always used for big
> messages, and allowing the sender to retransmit chunk (or is that
> allowed already?).
>   However, this is very much like reimplementing sort of TCP on top of
> TCP, which is probably highly suboptimal.
> 
>   Another alternative is to mandate the use of a limited window (say
> 64k) that would be the biggest amount of bytes a sender can safely send
> without receiving REPORTs acknowledgements. That implies mandating some
> kind of positive acknowledgement from the receiver (at the moment, it is
> only mandatory at the end of a full message).
>   Also, both alternatives could probably be mixed together. Again, that
> sounds like reimplementing TCP on top of TCP.

This was one of those places where we could not find any solution that 
met all needs. We ultimately decided that we would let the relay deal 
with this be lots of buffering as the lesser of evils. (Put a disk on 
the server.)

	Paul

> No 500 error code
> ------------------
> 
>   There is no error code like 500 in other protocols to tell the other
> side than processing its request failed for a reason that is independant
> from the protocol itself (too busy, not enough memory, etc).
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 10 21:14:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E31ec-0000hP-U5; Wed, 10 Aug 2005 21:14:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E31ea-0000hH-Gg
	for simple@megatron.ietf.org; Wed, 10 Aug 2005 21:14:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15762
	for <simple@ietf.org>; Wed, 10 Aug 2005 21:14:38 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E32Cn-0003NN-GH
	for simple@ietf.org; Wed, 10 Aug 2005 21:50:01 -0400
Received: from sj-core-3.cisco.com (171.68.223.137)
	by sj-iport-5.cisco.com with ESMTP; 10 Aug 2005 18:14:29 -0700
X-IronPort-AV: i="3.96,98,1122879600"; 
	d="scan'208"; a="204094189:sNHT34050556"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7B1DnZV017375;
	Wed, 10 Aug 2005 18:14:26 -0700 (PDT)
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, 10 Aug 2005 21:13:54 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 21:13:54 -0400
Message-ID: <42FAA651.1000302@cisco.com>
Date: Wed, 10 Aug 2005 21:13:53 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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 <hgs@cs.columbia.edu>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F932E4.4010004@cisco.com>
	<42F941C7.6000406@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Aug 2005 01:13:54.0118 (UTC)
	FILETIME=[F0C7B660:01C59E11]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Henning Schulzrinne wrote:
> Paul Kyzivat wrote:
> 
>> You have mentioned the desire to ignore the difference between sip and 
>> sips. This probably makes sense, at least most of the time. (But not 
>> always - you may only want to grant full access to your presence 
>> state, with sensitive info, over a sips connection.)
> 
>> Also, schemes are more than just distinct namespaces. There are 
>> significant differences from scheme to scheme about how equivalence of 
>> names is defined. Tel URIs must be compared differently for 
>> equivalence than sip (user=ip) URIs. Separator characters must be 
>> ignored, and parameters must be properly compared. (e.g. phone-context).
> 
> I don't think there's any disagreement that E.164-style and 
> user@host-style URIs are sufficiently different that treating them as 
> the same space is not likely to be productive or intuitive.
> 
>> Just as sip and sips URIs might be considered equivalent for purposes 
>> of identity equivalence, so may tel and sip/sips;user=phone. It seems 
>> many people prefer to use sip URIs for phone numbers, using whatever 
>> domain name is handy for them. This can cause a huge mess in 
>> determining equivalence. Technically one should not consider to sip 
>> URIs with different domains to be equivalent even if they both seem to 
>> represent the same phone number, and it gives me heartburn to suggest 
>> doing so, but pragmatically I think it must probably be supported. 
>> Specifically, I think all the following need to be considered equivalent:
>>
>>     tel:+1-555-987-6543
>>     tel:+15559876543
>>     sip:+1(555)987.6543@foo.com;user=phone
>>     sip:+15.55.98.76.543@bar.net;user=phone
> 
> This seems like an item for the 'ID management' document to consider.

I'm not convinced of that. Especially given the reception in paris, I 
think that doc, if it goes anywhere, will end up being a best practices 
document focused on how managers of domains and applications manage the 
names they assign.

This is something entirely different. It is about matching rules.

>> If we don't get this right, people will end up not being able to set 
>> policy for callers without understanding how the caller is identified 
>> from each different device he uses. If you end up needing a call log 
>> to figure out how your callers are identified before you can authorize 
>> them, then the system will be nearly unusable.
> 
> I fully agree. This discussion is very much tied to the 'ID management' 
> draft discussion. I'm on the "usability" hobby horse these days, but I 
> think in general, these equivalences should be as consistent as 
> possible. It is very confusing if two identifiers are treated the same 
> in one context and then suddenly differ in another - unless there's some 
> explicit "loose/strict" flag or other obvious indication.

They may both be related to usability, but I think they are otherwise 
different efforts.

>> We also talked last week about wildcarding. I think there will be 
>> demand/need for this. Things like:
>>
>>     tel:+1-900-nnn-nnnn
>>
>> Even this assumes that global form numbers are being used. Various 
>> forms of dial strings make more of a mess. But lets not discuss that 
>> for now.
> 
> How useful is this likely to be, at least for presence and access to geo 
> information?

I guess that particular example may not be a good one, since I doubt I 
would ever receive a request where the caller address was a 900 number.
But other wildcards might make sense:

	tel:+1-978-936-nnnn

would cover all cisco business phones at my site. With a few similar 
numbers I could grant access to most cisco business phones.

> Would we need to support the equivalent for domains, so that
> 
> domain="cisco.com"
> 
> matches
> 
> cisco.com
> engineering.cisco.com
> host17.engineering.cisco.com
> 
> [and other permutations]

I think we have to take those on a case by case basis. I don't think it 
generally makes sense to do that. There should be some explicit way to 
do it. E.g. domain="*.cisco.com" or domain="**.cisco.com".

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 11 09:30:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3D8f-0001Iz-4C; Thu, 11 Aug 2005 09:30:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3D8c-0001Ir-QG
	for simple@megatron.ietf.org; Thu, 11 Aug 2005 09:30:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01532
	for <simple@ietf.org>; Thu, 11 Aug 2005 09:30:24 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Dgv-0004t5-3A
	for simple@ietf.org; Thu, 11 Aug 2005 10:05:54 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7BDUCGi010163; Thu, 11 Aug 2005 16:30:12 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 11 Aug 2005 16:30:16 +0300
Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 11 Aug 2005 16:30:16 +0300
Received: from 172.21.35.188 ([172.21.35.188]) by esebe102.NOE.Nokia.com
	([172.21.138.217]) with Microsoft Exchange Server HTTP-DAV ; 
	Thu, 11 Aug 2005 13:30:14 +0000
Received: from hed040-040103.research.nokia.com by esebe102;
	11 Aug 2005 16:30:15 +0300
Subject: Re: [Simple] Questions regarding MSRP drafts
From: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
To: ext Paul Kyzivat <pkyzivat@cisco.com>
In-Reply-To: <42FA64A0.1020109@cisco.com>
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>
	<42FA64A0.1020109@cisco.com>
Content-Type: text/plain; charset=
Content-Transfer-Encoding: quoted-printable
Organization: Nokia-NRC/Helsinki
Message-Id: <1123767015.3994.16.camel@hed040-040103.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-14) 
Date: Thu, 11 Aug 2005 16:30:15 +0300
X-OriginalArrivalTime: 11 Aug 2005 13:30:16.0359 (UTC)
	FILETIME=[CF72AB70:01C59E78]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: quoted-printable
Cc: SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

	Hello,

Le mer 10/08/2005 =C3=A0 23:33, ext Paul Kyzivat a =C3=A9crit :
> The cases where reordering can occur are actually pretty obscure I=20
> think. (Somebody correct me if I am wrong.) The one I can think of is:
>=20
> - Two connections between a pair of relays. Two messages from same=20
> connection get sent, one over each connection. The 1st message is very=20
> long, while the 2nd is very short. The last byte of the 2nd message may=20
> be received before the last byte of the first message. Then it gets=20
> forwarded on.

That only happens if relays are to maintain multiple connections to the
same peer. Might be wrong, but I doubt ensuring they only have one
connection at a time (of course renewing should it fail) would pose any
problem nor much additionnal load.

On the other hand, supporting re-ordering, without any sane limit on the
re-ordering window size sounds very dangerous and prone to abuse to me.
At least, there ought to be an error code for client not able or not
willing to accept a chunk because of memory constraints.

--=20
Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Nokia-NRC/Helsinki

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 11 17:54:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3L0M-0005vc-O0; Thu, 11 Aug 2005 17:54:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3L0K-0005vW-LG
	for simple@megatron.ietf.org; Thu, 11 Aug 2005 17:54:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00114
	for <simple@ietf.org>; Thu, 11 Aug 2005 17:54:22 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E3LYh-0001ll-TF
	for simple@ietf.org; Thu, 11 Aug 2005 18:29:57 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 11 Aug 2005 14:54:12 -0700
X-IronPort-AV: i="3.96,101,1122879600"; 
	d="scan'208"; a="654435137:sNHT31036688"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7BLrDpM001707;
	Thu, 11 Aug 2005 14:54:09 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 11 Aug 2005 17:53:46 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 17:53:46 -0400
Message-ID: <42FBC8EA.4010105@cisco.com>
Date: Thu, 11 Aug 2005 17:53:46 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>	
	<42FA64A0.1020109@cisco.com>
	<1123767015.3994.16.camel@hed040-040103.research.nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 11 Aug 2005 21:53:46.0577 (UTC)
	FILETIME=[26241C10:01C59EBF]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA00114
Cc: SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Remi,

Lets see what others have to say. I think most people just want this=20
done. It has been restarted multiple times over a couple of years, and=20
we just can't afford for it not to be done. If we were to reopen it for=20
the kinds of changes you are suggesting we would effectively be=20
reengineering it from scratch - these kind of changes are fundamental.

	Paul

Remi Denis-Courmont wrote:
> 	Hello,
>=20
> Le mer 10/08/2005 =C3  23:33, ext Paul Kyzivat a =C3=A9crit :
>=20
>>The cases where reordering can occur are actually pretty obscure I=20
>>think. (Somebody correct me if I am wrong.) The one I can think of is:
>>
>>- Two connections between a pair of relays. Two messages from same=20
>>connection get sent, one over each connection. The 1st message is very=20
>>long, while the 2nd is very short. The last byte of the 2nd message may=
=20
>>be received before the last byte of the first message. Then it gets=20
>>forwarded on.
>=20
>=20
> That only happens if relays are to maintain multiple connections to the
> same peer. Might be wrong, but I doubt ensuring they only have one
> connection at a time (of course renewing should it fail) would pose any
> problem nor much additionnal load.
>=20
> On the other hand, supporting re-ordering, without any sane limit on th=
e
> re-ordering window size sounds very dangerous and prone to abuse to me.
> At least, there ought to be an error code for client not able or not
> willing to accept a chunk because of memory constraints.
>=20

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 11 18:13:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3LJ2-0002Ii-Q0; Thu, 11 Aug 2005 18:13:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LJ0-0002IE-CQ
	for simple@megatron.ietf.org; Thu, 11 Aug 2005 18:13:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01794
	for <simple@ietf.org>; Thu, 11 Aug 2005 18:13:35 -0400 (EDT)
Received: from mtagate1.de.ibm.com ([195.212.29.150])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3LrJ-0002JB-7G
	for simple@ietf.org; Thu, 11 Aug 2005 18:49:10 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com
	(d12nrmr1607.megacenter.de.ibm.com [9.149.167.49])
	by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7BMDGxt145186
	for <simple@ietf.org>; Thu, 11 Aug 2005 22:13:16 GMT
Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com
	[9.149.165.229])
	by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP
	id j7BMDGo2165850
	for <simple@ietf.org>; Fri, 12 Aug 2005 00:13:16 +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
	j7BMDGgd018596 for <simple@ietf.org>; Fri, 12 Aug 2005 00:13:16 +0200
Received: from [9.149.167.114] (d12mc102.megacenter.de.ibm.com [9.149.167.114])
	by d12av04.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id
	j7BMDF8M018593 for <simple@ietf.org>; Fri, 12 Aug 2005 00:13:16 +0200
In-Reply-To: <42FBC8EA.4010105@cisco.com>
To: SIMPLE <simple@ietf.org>
Subject: Re: [Simple] Questions regarding MSRP drafts
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V70_M6_06302005 Beta 4NP June 30, 2005
From: Avshalom Houri <AVSHALOM@il.ibm.com>
Message-ID: <OF3BAB0995.DEBECE8C-ONC225705A.007981DA-C225705A.007A1E42@il.ibm.com>
Date: Fri, 12 Aug 2005 01:13:16 +0300
X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Build V70_M6_06302005
	Beta 4 SP0805|June 30, 2005) at 12/08/2005 01:13:15,
	Serialize complete at 12/08/2005 01:13:15
X-Spam-Score: 0.5 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0597613558=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multipart message in MIME format.
--===============0597613558==
Content-Type: multipart/alternative;
	boundary="=_alternative 0079E08AC225705A_="

This is a multipart message in MIME format.
--=_alternative 0079E08AC225705A_=
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

I think that it should be done and finished with. If someone has ideas how =

to improve it,
they can suggest another alternative on a new draft and a new work item.

SIP implementations can not afford not finishing with MSRP now. Session IM =

is more
then needed for deployments.

Avshalom
IBM




Paul Kyzivat <pkyzivat@cisco.com>=20
Sent by: simple-bounces@ietf.org
12/08/2005 12:53 AM

To
Remi Denis-Courmont <remi.denis-courmont@nokia.com>
cc
SIMPLE <simple@ietf.org>
Subject
Re: [Simple] Questions regarding MSRP drafts






Remi,

Lets see what others have to say. I think most people just want this=20
done. It has been restarted multiple times over a couple of years, and=20
we just can't afford for it not to be done. If we were to reopen it for=20
the kinds of changes you are suggesting we would effectively be=20
reengineering it from scratch - these kind of changes are fundamental.

                 Paul

Remi Denis-Courmont wrote:
>                Hello,
>=20
> Le mer 10/08/2005 =C3  23:33, ext Paul Kyzivat a =C3=A9crit :
>=20
>>The cases where reordering can occur are actually pretty obscure I=20
>>think. (Somebody correct me if I am wrong.) The one I can think of is:
>>
>>- Two connections between a pair of relays. Two messages from same=20
>>connection get sent, one over each connection. The 1st message is very=20
>>long, while the 2nd is very short. The last byte of the 2nd message may=20
>>be received before the last byte of the first message. Then it gets=20
>>forwarded on.
>=20
>=20
> That only happens if relays are to maintain multiple connections to the
> same peer. Might be wrong, but I doubt ensuring they only have one
> connection at a time (of course renewing should it fail) would pose any
> problem nor much additionnal load.
>=20
> On the other hand, supporting re-ordering, without any sane limit on the
> re-ordering window size sounds very dangerous and prone to abuse to me.
> At least, there ought to be an error code for client not able or not
> willing to accept a chunk because of memory constraints.
>=20

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple


--=_alternative 0079E08AC225705A_=
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable


<br><font size=3D2 face=3D"sans-serif">I think that it should be done and f=
inished
with. If someone has ideas how to improve it,</font>
<br><font size=3D2 face=3D"sans-serif">they can suggest another alternative
on a new draft and a new work item.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">SIP implementations can not afford n=
ot
finishing with MSRP now. Session IM is more</font>
<br><font size=3D2 face=3D"sans-serif">then needed for deployments.</font>
<br>
<br><font size=3D2 face=3D"sans-serif">Avshalom</font>
<br><font size=3D2 face=3D"sans-serif">IBM</font>
<br>
<br>
<br>
<br>
<table width=3D100%>
<tr valign=3Dtop>
<td width=3D40%><font size=3D1 face=3D"sans-serif"><b>Paul Kyzivat &lt;pkyz=
ivat@cisco.com&gt;</b>
</font>
<br><font size=3D1 face=3D"sans-serif">Sent by: simple-bounces@ietf.org</fo=
nt>
<p><font size=3D1 face=3D"sans-serif">12/08/2005 12:53 AM</font>
<td width=3D59%>
<table width=3D100%>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">To</font></div>
<td><font size=3D1 face=3D"sans-serif">Remi Denis-Courmont &lt;remi.denis-c=
ourmont@nokia.com&gt;</font>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">cc</font></div>
<td><font size=3D1 face=3D"sans-serif">SIMPLE &lt;simple@ietf.org&gt;</font>
<tr valign=3Dtop>
<td>
<div align=3Dright><font size=3D1 face=3D"sans-serif">Subject</font></div>
<td><font size=3D1 face=3D"sans-serif">Re: [Simple] Questions regarding MSRP
drafts</font></table>
<br>
<table>
<tr valign=3Dtop>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3D2 face=3D"Courier New">Remi,<br>
<br>
Lets see what others have to say. I think most people just want this <br>
done. It has been restarted multiple times over a couple of years, and
<br>
we just can't afford for it not to be done. If we were to reopen it for
<br>
the kinds of changes you are suggesting we would effectively be <br>
reengineering it from scratch - these kind of changes are fundamental.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
Paul<br>
<br>
Remi Denis-Courmont wrote:<br>
&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Hello,<b=
r>
&gt; <br>
&gt; Le mer 10/08/2005 =C3 &nbsp;23:33, ext Paul Kyzivat a =C3=A9crit :<br>
&gt; <br>
&gt;&gt;The cases where reordering can occur are actually pretty obscure
I <br>
&gt;&gt;think. (Somebody correct me if I am wrong.) The one I can think
of is:<br>
&gt;&gt;<br>
&gt;&gt;- Two connections between a pair of relays. Two messages from same
<br>
&gt;&gt;connection get sent, one over each connection. The 1st message
is very <br>
&gt;&gt;long, while the 2nd is very short. The last byte of the 2nd message
may <br>
&gt;&gt;be received before the last byte of the first message. Then it
gets <br>
&gt;&gt;forwarded on.<br>
&gt; <br>
&gt; <br>
&gt; That only happens if relays are to maintain multiple connections to
the<br>
&gt; same peer. Might be wrong, but I doubt ensuring they only have one<br>
&gt; connection at a time (of course renewing should it fail) would pose
any<br>
&gt; problem nor much additionnal load.<br>
&gt; <br>
&gt; On the other hand, supporting re-ordering, without any sane limit
on the<br>
&gt; re-ordering window size sounds very dangerous and prone to abuse to
me.<br>
&gt; At least, there ought to be an error code for client not able or not<b=
r>
&gt; willing to accept a chunk because of memory constraints.<br>
&gt; <br>
<br>
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<br>
Simple mailing list<br>
Simple@ietf.org<br>
https://www1.ietf.org/mailman/listinfo/simple<br>
</font>
<br>
--=_alternative 0079E08AC225705A_=--


--===============0597613558==
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

--===============0597613558==--




From simple-bounces@ietf.org Fri Aug 12 03:07:29 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3TdZ-0001v4-Ff; Fri, 12 Aug 2005 03:07:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3TdX-0001u3-KE
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 03:07:27 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07292
	for <simple@ietf.org>; Fri, 12 Aug 2005 03:07:25 -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.43) id 1E3UBz-0007dy-Mz
	for simple@ietf.org; Fri, 12 Aug 2005 03:43:05 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2005 09:06:57 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F735@carrera.eu.tieto.com>
Thread-Index: AcWfDG1LBOTP41y8Tmuw7XsEr+/Kcg==
To: <simple@ietf.org>
X-OriginalArrivalTime: 12 Aug 2005 07:06:58.0599 (UTC)
	FILETIME=[6E20BB70:01C59F0C]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Content-Transfer-Encoding: quoted-printable
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,
=20
I am currently testing some SIP SUBSCRIBE functionality, and there is =
one thing i am not 100% sure of - mechanism of refreshing a =
subscription.
=20
Our software implements functionality described in =
draft-ietf-sipping-config-framework (Framework for Session Initiation =
Protocol User Agent Profile Delivery) but there is nothing about =
refreshes - it references RFC 3265.
=20
=20
RFC 3265:
=20
3.1.4.2. Refreshing of Subscriptions
At any time before a subscription expires, the subscriber may refresh
the timer on such a subscription by sending another SUBSCRIBE request
on the same dialog as the existing subscription, and with the same
"Event" header "id" parameter (if one was present in the initial
subscription). The handling for such a request is the same as for
the initial creation of a subscription except as described below.
=20
So lets say, i'll send these messages:
=20
SUBSCRIBE sip:user@example.com SIP/2.0            // initial subscribe =
which creates a subscription to document 'index' which belongs to 'user'
To: sip:user@example.com
From: sip:user@example.com;tag=3Da2b3c1
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
ment=3Dindex
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 1 SUBSCRIBE
...
=20
SIP/2.0 200 OK
To: sip:user1@example.com;tag=3D12345
...
=20
SUBSCRIBE sip:anotheruser@example.com SIP/2.0        // subscribe to =
another user - but it is sent on the same dialog, with the same Event =
header
To: sip:anotheruser@example.com;tag=3D12345
From: sip:user@example.com;tag=3Da2b3c1
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
ment=3Dindex
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 2 SUBSCRIBE
...
=20
=20
Will the second subscribe just refresh the initial one, even if it has =
different sip uri in To header ?
=20

Thank you for your time,

Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
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



From simple-bounces@ietf.org Fri Aug 12 03:23:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3Tt2-0005AE-4Y; Fri, 12 Aug 2005 03:23:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Tsz-0005A8-EY
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 03:23:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07843
	for <simple@ietf.org>; Fri, 12 Aug 2005 03:23:23 -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.43) id 1E3URR-00082Z-GS
	for simple@ietf.org; Fri, 12 Aug 2005 03:59:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 12 Aug 2005 09:22:50 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F736@carrera.eu.tieto.com>
Thread-Topic: Subscription refresment
Thread-Index: AcWfDqVfzYH7SONPS7aToBTdAhJWyw==
To: <simple@ietf.org>
X-OriginalArrivalTime: 12 Aug 2005 07:22:52.0199 (UTC)
	FILETIME=[A6848B70:01C59F0E]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Subscription refresment
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,

(sorry for the previous mail, I focused on content and forgot to fill =
the subject)

I am currently testing some SIP SUBSCRIBE functionality, and there is =
one thing i am not 100% sure of - mechanism of refreshing a =
subscription.

Our software implements functionality described in =
draft-ietf-sipping-config-framework (Framework for Session Initiation =
Protocol User Agent Profile Delivery) but there is nothing about =
refreshes - it references RFC 3265.


RFC 3265:

3.1.4.2. Refreshing of Subscriptions
At any time before a subscription expires, the subscriber may refresh
the timer on such a subscription by sending another SUBSCRIBE request
on the same dialog as the existing subscription, and with the same
"Event" header "id" parameter (if one was present in the initial
subscription). The handling for such a request is the same as for
the initial creation of a subscription except as described below.

So lets say, i'll send these messages:

SUBSCRIBE sip:user@example.com SIP/2.0            // initial subscribe =
which creates a subscription to document 'index' which belongs to 'user'
To: sip:user@example.com
From: sip:user@example.com;tag=3Da2b3c1
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
ment=3Dindex
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 1 SUBSCRIBE
...

SIP/2.0 200 OK
To: sip:user1@example.com;tag=3D12345
...

SUBSCRIBE sip:anotheruser@example.com SIP/2.0        // subscribe to =
another user - but it is sent on the same dialog, with the same Event =
header
To: sip:anotheruser@example.com;tag=3D12345
From: sip:user@example.com;tag=3Da2b3c1
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
ment=3Dindex
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 2 SUBSCRIBE
...


Will the second subscribe just refresh the initial one, even if it has =
different sip uri in To header ?


Thank you for your time,

Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
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



From simple-bounces@ietf.org Fri Aug 12 04:55:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3VKI-0007el-B2; Fri, 12 Aug 2005 04:55:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3VKF-0007eb-QO
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 04:55:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11486
	for <simple@ietf.org>; Fri, 12 Aug 2005 04:55:37 -0400 (EDT)
Received: from nproxy.gmail.com ([64.233.182.205])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Vsj-0002DX-Sl
	for simple@ietf.org; Fri, 12 Aug 2005 05:31:18 -0400
Received: by nproxy.gmail.com with SMTP id a4so121280nfc
	for <simple@ietf.org>; Fri, 12 Aug 2005 01:55:28 -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=coYg0wxSqZDNzbBqpGuB662I9cwUPBNoWuZC9yYyKZzYFhkGi6T4ylxjQHyAqlB+hkxcE0LSIOXlT4eKnSy9H3MMbDcFEUXPBwruZ7GesaJjOJ/xwGDHg7d8pi/IGdWBjjTGMsdN9Etda4f2lzNI++KmrYbzDQ0Njl8S2HDwZBo=
Received: by 10.48.239.18 with SMTP id m18mr86920nfh;
	Fri, 12 Aug 2005 01:55:28 -0700 (PDT)
Received: by 10.48.142.10 with HTTP; Fri, 12 Aug 2005 01:55:28 -0700 (PDT)
Message-ID: <27584a430508120155591fa34@mail.gmail.com>
Date: Fri, 12 Aug 2005 09:55:28 +0100
From: Siddharth Gupta <sidgupta311@gmail.com>
To: simple@ietf.org
Mime-Version: 1.0
X-Spam-Score: 1.0 (+)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
Subject: [Simple] =?windows-1252?q?XCAP_Server_=96_Client_Implementation_?=
	=?windows-1252?q?Required?=
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0737994815=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0737994815==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3286_25248733.1123836928372"

------=_Part_3286_25248733.1123836928372
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

 I am a MSc. student working on a Presence related project. As part of the=
=20
study I wish to include in it XML based contact list management.

 A typical setup of what I plan to have is depicted below.

  |---------|=20

| Presence| |--------|

| Client | | XCAP |

|- - - - -| -- XCAP -- | Server |

| XCAP | |--------|=20

| Client | |

|---------| |

|| |

|| |

Peer2Peer |

Presence |

|| |

 || |

|---------| |

| Presence| |

| Client | |

|- - - - -| -- XCAP ---------=20

| XCAP |=20

| Client |

|---------|=20

 As you would notice I am not using any presence server at this point in=20
time. I may plan to do so at a later stage. I am using Kphone as the=20
presence client and would like to add the XCAP Client functionality to it.

 So my requirements are:

- A XCAP Server Implementation

- A XCAP Client Implementation

- If possible a SIMPLE based Presence Server

 I would much appreciate information on where I can obtain these=20
implementations, or if anyone has them and is willing to share them.

 Many thanks,

Siddharth

------=_Part_3286_25248733.1123836928372
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">Hi,</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">I am a MSc. student working on a Presence related proj=
ect. As part of the study I wish to include in it XML based contact list ma=
nagement.
</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">A typical setup of what I plan to have is depicted bel=
ow.</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|---------|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span>=
</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Presence|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|------=
--|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Client<span style=3D"mso-spacerun: yes">&nbsp; </span>|=
<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</span>| XCAP<span style=3D"mso-spacerun: yes">&nbsp;&nbsp; </span>|</span>=
</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|- - - - -| -- XCAP --<span style=3D"mso-spacerun: yes">&=
nbsp; </span>| Server |</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| XCAP<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp=
; </span>|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</span>|--------| </span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Client<span style=3D"mso-spacerun: yes">&nbsp; </span>|=
<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|---------|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span s=
tyle=3D"mso-spacerun: yes">
&nbsp;&nbsp;&nbsp;&nbsp;</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>||<span style=3D"mso-spacerun: ye=
s">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>||<span style=3D"mso-spacerun: ye=
s">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; </span>Peer2Peer<span style=3D"mso-spacerun: yes">&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; </span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; </span>Presence <span style=3D"mso-spacerun: yes">&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>||<span style=3D"mso-spacerun: ye=
s">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"mso-spacerun: yes">&nbsp;&nbsp=
;</span>||<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;=20
</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|---------|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span s=
tyle=3D"mso-spacerun: yes">
&nbsp;&nbsp;&nbsp;&nbsp;</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Presence|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span s=
tyle=3D"mso-spacerun: yes">
&nbsp;&nbsp;&nbsp;&nbsp;</span>|</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Client<span style=3D"mso-spacerun: yes">&nbsp; </span>|=
<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</span><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;</span>|</=
span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|- - - - -| -- XCAP ---------<span style=3D"mso-spacerun:=
 yes">&nbsp; </span></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| XCAP<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp=
; </span>|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</span></span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>| Client<span style=3D"mso-spacerun: yes">&nbsp; </span>|=
</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'"><span style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </span>|---------|<span style=3D"mso-spacerun: yes">&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span>=
</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">As you would notice I am not using any presence server=
 at this point in time. I may plan to do so at a later stage. I am using Kp=
hone as the presence client and would like to add the XCAP Client functiona=
lity to it.
</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">So my requirements are:</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">- A XCAP Server Implementation</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">- A XCAP Client Implementation</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">- If possible a SIMPLE based Presence Server</span></p=
>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">I would much appreciate information on where I can obt=
ain these implementations, or if anyone has them and is willing to share th=
em.
</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">&nbsp;</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">Many thanks,</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0cm 0cm 0pt"><span style=3D"FONT-FA=
MILY: 'Courier New'">Siddharth</span></p>

------=_Part_3286_25248733.1123836928372--


--===============0737994815==
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

--===============0737994815==--




From simple-bounces@ietf.org Fri Aug 12 05:31:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3Vt8-0007U7-U1; Fri, 12 Aug 2005 05:31:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Vt4-0007Tx-TO
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 05:31:41 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12842
	for <simple@ietf.org>; Fri, 12 Aug 2005 05:31:36 -0400 (EDT)
Received: from v-mail.vsnl.com ([203.200.237.34] helo=vmail.vsnl.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3WRY-0003Ai-9S
	for simple@ietf.org; Fri, 12 Aug 2005 06:07:17 -0400
Received: from rathod ([172.16.29.33])
	by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May
	14
	2003)) with SMTP id <0IL300GL7RKFGB@vmail.vsnl.com> for simple@ietf.org;
	Fri, 12 Aug 2005 14:56:40 +0530 (IST)
Date: Fri, 12 Aug 2005 14:57:46 +0530
From: Rathod Subhashchandra <rathod@tataelxsi.co.in>
In-reply-to: <007201c59f19$0f3382c0$7302a8c0@Nataraju>
To: sip-implementors@cs.columbia.edu, simple@ietf.org
Message-id: <005401c59f20$19e958a0$4819320a@telxsi.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: High
X-Priority: 1 (Highest)
X-MSMail-priority: High
X-Spam-Score: 1.0 (+)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7BIT
Cc: 
Subject: [Simple] SIP Invite problem
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rathod@tataelxsi.co.in
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi All,

I have written a PoC client code using Vovida SIP stack for PoC registration
and invite. To test these functionalities, there is ericsson server.
PoC Registration is going through. But for Invite, server is returning
404(User not found).
Has anyone tried SIP invite in Vovida stack? If so, is Invite working?

Thanks !
Rathod.


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 08:22:19 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3YYF-0001JF-7s; Fri, 12 Aug 2005 08:22:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3YYC-0001JA-U5
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 08:22:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18781
	for <simple@ietf.org>; Fri, 12 Aug 2005 08:22:15 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Z6i-0007Od-Su
	for simple@ietf.org; Fri, 12 Aug 2005 08:57:57 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2005 08:22:08 -0400
X-IronPort-AV: i="3.96,103,1122868800"; 
	d="scan'208"; a="66273601:sNHT33764404"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CCLvQr006324; 
	Fri, 12 Aug 2005 08:22:05 -0400 (EDT)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 12 Aug 2005 08:22:04 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] tel URIs in common policy
Date: Fri, 12 Aug 2005 08:22:03 -0400
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E374BD34@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Simple] tel URIs in common policy
Thread-Index: AcWd5uQLrrND1QQpTjq/RdRYbGE4gABUVWCw
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Paul Kyzivat \(pkyzivat\)" <pkyzivat@cisco.com>,
	"Brian Rosen" <br@brianrosen.net>
X-OriginalArrivalTime: 12 Aug 2005 12:22:04.0619 (UTC)
	FILETIME=[72FE71B0:01C59F38]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44
Content-Transfer-Encoding: quoted-printable
Cc: simple@ietf.org, Aki Niemi <aki.niemi@nokia.com>,
	ext Henning Schulzrinne <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Paul,

Didn't one of the tel: drafts suggest that you could go from tel: to
sip: format AND Vice Versa?

If that is not published yet, then it might need updating to say that
you can go from tel: to sip: but only the domain can go in the reverse
direction.

Mike


> -----Original Message-----
> From: simple-bounces@ietf.org=20
> [mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat)
> Sent: Wednesday, August 10, 2005 4:02 PM
> To: Brian Rosen
> Cc: 'ext Henning Schulzrinne'; 'Aki Niemi'; simple@ietf.org
> Subject: Re: [Simple] tel URIs in common policy
>=20
> Brian,
>=20
> Brian Rosen wrote:
> > Paul
> >=20
> > Not sure yet what I think of the basic idea, but
> >    sip:+1-232-1234@foo.com;user=3Dphone
> > should be equivalent to
> >    tel:+1-232-1234
>=20
> Well, I am suggesting that, when the purpose is identifying a=20
> caller for purposes of authorization.
>=20
> According to 3261, only someone responsible for the foo.com=20
> domain can decide that these are equivalent. If you are not=20
> responsible for that domain then you are not permitted to=20
> conclude they are equivalent. So I am in some sense=20
> advocating violating 3261 in this case.
>=20
> Unless we plan to change 3261, or look the other way while=20
> people violate it, this is a fundamental problem with using=20
> sip;user=3Dphone address forms.
>=20
> > So I think you CAN convert it to "enum" form.
>=20
> According to sip routing rules, if you are not responsible=20
> for the foo.com domain, you *definitely* can't do this to=20
> route the sip address!=20
> You must simply route it based on the domain name.
>=20
> I see this as a key difference between the two forms. With=20
> the tel form, anybody can just go to the PSTN, or use enum to=20
> find possible ways of reaching it. With the sip form, you can=20
> only reach the address via sip.
>=20
> > You might have more problems with
> >    sip:1234@foo.com
> >=20
> > That may be equivalent to
> >    tel:1234;phone-context=3Dfoo.com
> > but you don't know that a priori.
>=20
> There is certainly nothing written down anywhere that would=20
> lead you to believe you could do that. If it can be done, it=20
> is only on a domain-specific basis, and so can only be done=20
> by someone responsible for the domain.
>=20
> 	Paul
>=20
> > Brian
> >=20
> > -----Original Message-----
> > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On=20
> > Behalf Of Paul Kyzivat
> > Sent: Wednesday, August 10, 2005 2:19 PM
> > To: Aki Niemi
> > Cc: simple@ietf.org; ext Henning Schulzrinne
> > Subject: Re: [Simple] tel URIs in common policy
> >=20
> > Aki,
> >=20
> >=20
> >=20
> > Aki Niemi wrote:
> >=20
> >>Hi,
> >>
> >>I kind of grew fond of the idea Cullen and I came up with=20
> in a private=20
> >>conversation, namely treating telephone numbers as domains=20
> similar to=20
> >>when issuing a DNS ENUM query.
> >>
> >>In essence, to match +1-232-555-1234, you'd have an identity=20
> >>conditions such as:
> >>
> >><many domain=3D"4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
> >=20
> >=20
> > Then what do you do with sip:+1-232-555-1234@foo.com;user=3Dphone ?
> >=20
> > I don't think you can convert it to:
> >=20
> >     4.3.2.1.5.5.5.2.3.2.1.foo.com
> >=20
> > and if you could then it it wouldn't match the e164.arpa form.
> >=20
> >=20
> >>This has an interesting additional property of being able to match=20
> >>based on country code, area code, etc. For example, to match all=20
> >>Finnish telephone numbers, you'd have:
> >>
> >><many domain=3D"8.5.3.e164.arpa" />
> >=20
> >=20
> > It only does if you declare that a domain matches anything=20
> it is the=20
> > tail of. You may sometimes want that, but I don't think you=20
> do in general.
> >=20
> > 	Paul
> >=20
> >=20
> >>Not being an expert on ENUM or E.164 in general, I suspect this is=20
> >>horribly broken, but it pleases the aesthethic eye.
> >>
> >>Cheers,
> >>Aki
> >>
> >>ext Henning Schulzrinne wrote:
> >>
> >>
> >>>In a side conversation, Hannes suggested a solution to the tel URI=20
> >>>problem we discussed during the WG meeting, akin to what's done in=20
> >>>the geopriv coordinate system parameter, namely to have a=20
> parameter=20
> >>>that identifies the scheme, as in
> >>>
> >>><one scheme=3D"tel" id=3D"+1-212-555-1234"/>
> >>>
> >>>or
> >>>
> >>><one scheme=3D"sip" id=3D"alice@example.com"/>
> >>>
> >>>if you really only want to match SIP identity=20
> sip:alice@example.com.
> >>>
> >>>The default with no scheme parameter is "matches any=20
> user@domain scheme".
> >>>
> >>>In order to complete finishing the section of the spec, I'd value=20
> >>>quick feedback on the idea.
> >>>
> >>>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
> >>
> >=20
> >=20
> > _______________________________________________
> > Simple mailing list
> > Simple@ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple
> >=20
>=20
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>=20

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 09:12:07 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3ZKR-0004KC-IE; Fri, 12 Aug 2005 09:12:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZKN-0004Iv-B5
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 09:12:05 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20956
	for <simple@ietf.org>; Fri, 12 Aug 2005 09:12:01 -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.43)
	id 1E3Zsr-0000KU-Ps
	for simple@ietf.org; Fri, 12 Aug 2005 09:47:44 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-3.cisco.com with ESMTP; 12 Aug 2005 06:11:51 -0700
X-IronPort-AV: i="3.96,103,1122879600"; 
	d="scan'208"; a="331656118:sNHT37982450"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CDBIp8025595;
	Fri, 12 Aug 2005 06:11:49 -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);
	Fri, 12 Aug 2005 09:11:34 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:11:34 -0400
Message-ID: <42FCA006.9040608@cisco.com>
Date: Fri, 12 Aug 2005 09:11:34 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] (no subject)
References: <3ACC9A25264A684F82C71840111F979847F735@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 13:11:34.0441 (UTC)
	FILETIME=[5D255190:01C59F3F]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Martin.Hynar@tietoenator.com wrote:
> Hello,
>  
> I am currently testing some SIP SUBSCRIBE functionality, and there is one thing i am not 100% sure of - mechanism of refreshing a subscription.
>  
> Our software implements functionality described in draft-ietf-sipping-config-framework (Framework for Session Initiation Protocol User Agent Profile Delivery) but there is nothing about refreshes - it references RFC 3265.
>  
>  
> RFC 3265:
>  
> 3.1.4.2. Refreshing of Subscriptions
> At any time before a subscription expires, the subscriber may refresh
> the timer on such a subscription by sending another SUBSCRIBE request
> on the same dialog as the existing subscription, and with the same
> "Event" header "id" parameter (if one was present in the initial
> subscription). The handling for such a request is the same as for
> the initial creation of a subscription except as described below.
>  
> So lets say, i'll send these messages:
>  
> SUBSCRIBE sip:user@example.com SIP/2.0            // initial subscribe which creates a subscription to document 'index' which belongs to 'user'
> To: sip:user@example.com
> From: sip:user@example.com;tag=a2b3c1
> Event:sip-profile;profile-type=application;app-id=resource-lists;document=index
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 1 SUBSCRIBE
> ...
>  
> SIP/2.0 200 OK
> To: sip:user1@example.com;tag=12345
   Expires: 3600
> ...

The expires value in the response is important. It specifies when the 
subscription will expire if not refreshed first.

> SUBSCRIBE sip:anotheruser@example.com SIP/2.0        // subscribe to another user - but it is sent on the same dialog, with the same Event header
> To: sip:anotheruser@example.com;tag=12345
> From: sip:user@example.com;tag=a2b3c1
> Event:sip-profile;profile-type=application;app-id=resource-lists;document=index
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 2 SUBSCRIBE
> ...

The above is not valid. All the requests in the dialog must have the 
same To and From. (Swapped if the request is sent in the reverse 
direction.) If you want to send a subscription for another user then you 
must create a new dialog.

To refresh the original subscription, before it expires, send another 
subscription in the same dialog, such as:

SUBSCRIBE sip:user@example.com SIP/2.0  // refresh
To: sip:user@example.com;tag=12345
From: sip:user@example.com;tag=a2b3c1
Event:sip-profile;profile-type=application;app-id=resource-lists;document=index
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 2 SUBSCRIBE

> Will the second subscribe just refresh the initial one, even if it has different sip uri in To header ?

No. It is just wrong.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 09:42:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3ZnV-0003Q6-Bv; Fri, 12 Aug 2005 09:42:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZnT-0003Pj-9a
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 09:42:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22474
	for <simple@ietf.org>; Fri, 12 Aug 2005 09:42:05 -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.43)
	id 1E3aLy-0001Ep-P0
	for simple@ietf.org; Fri, 12 Aug 2005 10:17:48 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 12 Aug 2005 06:41:55 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CDfSp4010649;
	Fri, 12 Aug 2005 06:41:54 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 12 Aug 2005 09:41:45 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:41:45 -0400
Message-ID: <42FCA718.3070006@cisco.com>
Date: Fri, 12 Aug 2005 09:41:44 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: "Michael Hammer (mhammer)" <mhammer@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <072C5B76F7CEAB488172C6F64B30B5E374BD34@xmb-rtp-20b.amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 13:41:45.0239 (UTC)
	FILETIME=[94772A70:01C59F43]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org, ext Henning Schulzrinne <hgs@cs.columbia.edu>,
	Aki Niemi <aki.niemi@nokia.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Michael Hammer (mhammer) wrote:
> Paul,
> 
> Didn't one of the tel: drafts suggest that you could go from tel: to
> sip: format AND Vice Versa?

I don't know of any that did the visa versa in the sense we are talking 
about here.

What I do recall is that the semantics of sip;user=phone were tightened 
up a bit. It used to be the case that when you convert from tel to sip 
you embed the tel content in the user part and add user=phone. But there 
was then no requirement that a sip uri with the user=phone parameter had 
to obey the tel syntax in its user part. So something like 
"sip:fred@foo.com;user=phone" was as far as the spec went.

I believe that was tightened up (though I don't recall in what draft 
that was done), so that if the user=phone parameter is present then it 
is at least syntactically equivalent to a tel. But AFAIK that still did 
not give the anyone except the owner of the domain the right to actually 
make the translation.

The creator of the URI may need for it to stay as is for a variety of 
good reasons:
- it might be a sips URI to guarantee all calls have secure signaling.
   (there is no tels URI.)
- there may be a requirement to use sip signaling so that sip features
   like MESSAGE, alternative media, etc. can be used.
- even if the actual target is in the PSTN, the recipient may want to
   control where the hop-off to the PSTN occurs.
- (I'm sure there are more)

So, if I hand you a sip URI (say 
sips:+1-555-123-4567@example.com;user=phone), I should have an 
expectation that you will use that to contact me via SIP, not some other 
way.

If I put that address in my From address when I call you, and your phone 
simply displays the phone number, then you will not be aware that I 
should only be contacted via SIP. You may attempt to contact me via the 
PSTN directly. Or if you have a sip phone, you may try to reach me using 
either tel:+1-555-123-4567 or sip:+1-555-123-4567@foo.org;user=phone, 
and those may eventually go to the PSTN. So you have violated my intent 
in using that address.

If I want to give you those options then I can explicitly give you the 
tel form of my address.

	Paul

> If that is not published yet, then it might need updating to say that
> you can go from tel: to sip: but only the domain can go in the reverse
> direction.

You can go from tel to sip for a domain where you are permitted to 
construct URIs. You can't just use some arbitrary domain name. And you 
can go the other way iff you are responsible for the domain too. So 
there is symmetry. And the condition may be a bit weaker than 
"responsible for the domain". You can probably safely do it if you are 
aware of the policies of the domain around address processing and that 
it processes these forms suitably. But you can't do it for a domain you 
know nothing about.

	Paul

> Mike
> 
> 
> 
>>-----Original Message-----
>>From: simple-bounces@ietf.org 
>>[mailto:simple-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat)
>>Sent: Wednesday, August 10, 2005 4:02 PM
>>To: Brian Rosen
>>Cc: 'ext Henning Schulzrinne'; 'Aki Niemi'; simple@ietf.org
>>Subject: Re: [Simple] tel URIs in common policy
>>
>>Brian,
>>
>>Brian Rosen wrote:
>>
>>>Paul
>>>
>>>Not sure yet what I think of the basic idea, but
>>>   sip:+1-232-1234@foo.com;user=phone
>>>should be equivalent to
>>>   tel:+1-232-1234
>>
>>Well, I am suggesting that, when the purpose is identifying a 
>>caller for purposes of authorization.
>>
>>According to 3261, only someone responsible for the foo.com 
>>domain can decide that these are equivalent. If you are not 
>>responsible for that domain then you are not permitted to 
>>conclude they are equivalent. So I am in some sense 
>>advocating violating 3261 in this case.
>>
>>Unless we plan to change 3261, or look the other way while 
>>people violate it, this is a fundamental problem with using 
>>sip;user=phone address forms.
>>
>>
>>>So I think you CAN convert it to "enum" form.
>>
>>According to sip routing rules, if you are not responsible 
>>for the foo.com domain, you *definitely* can't do this to 
>>route the sip address! 
>>You must simply route it based on the domain name.
>>
>>I see this as a key difference between the two forms. With 
>>the tel form, anybody can just go to the PSTN, or use enum to 
>>find possible ways of reaching it. With the sip form, you can 
>>only reach the address via sip.
>>
>>
>>>You might have more problems with
>>>   sip:1234@foo.com
>>>
>>>That may be equivalent to
>>>   tel:1234;phone-context=foo.com
>>>but you don't know that a priori.
>>
>>There is certainly nothing written down anywhere that would 
>>lead you to believe you could do that. If it can be done, it 
>>is only on a domain-specific basis, and so can only be done 
>>by someone responsible for the domain.
>>
>>	Paul
>>
>>
>>>Brian
>>>
>>>-----Original Message-----
>>>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On 
>>>Behalf Of Paul Kyzivat
>>>Sent: Wednesday, August 10, 2005 2:19 PM
>>>To: Aki Niemi
>>>Cc: simple@ietf.org; ext Henning Schulzrinne
>>>Subject: Re: [Simple] tel URIs in common policy
>>>
>>>Aki,
>>>
>>>
>>>
>>>Aki Niemi wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I kind of grew fond of the idea Cullen and I came up with 
>>>
>>in a private 
>>
>>>>conversation, namely treating telephone numbers as domains 
>>>
>>similar to 
>>
>>>>when issuing a DNS ENUM query.
>>>>
>>>>In essence, to match +1-232-555-1234, you'd have an identity 
>>>>conditions such as:
>>>>
>>>><many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
>>>
>>>
>>>Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?
>>>
>>>I don't think you can convert it to:
>>>
>>>    4.3.2.1.5.5.5.2.3.2.1.foo.com
>>>
>>>and if you could then it it wouldn't match the e164.arpa form.
>>>
>>>
>>>
>>>>This has an interesting additional property of being able to match 
>>>>based on country code, area code, etc. For example, to match all 
>>>>Finnish telephone numbers, you'd have:
>>>>
>>>><many domain="8.5.3.e164.arpa" />
>>>
>>>
>>>It only does if you declare that a domain matches anything 
>>
>>it is the 
>>
>>>tail of. You may sometimes want that, but I don't think you 
>>
>>do in general.
>>
>>>	Paul
>>>
>>>
>>>
>>>>Not being an expert on ENUM or E.164 in general, I suspect this is 
>>>>horribly broken, but it pleases the aesthethic eye.
>>>>
>>>>Cheers,
>>>>Aki
>>>>
>>>>ext Henning Schulzrinne wrote:
>>>>
>>>>
>>>>
>>>>>In a side conversation, Hannes suggested a solution to the tel URI 
>>>>>problem we discussed during the WG meeting, akin to what's done in 
>>>>>the geopriv coordinate system parameter, namely to have a 
>>>>
>>parameter 
>>
>>>>>that identifies the scheme, as in
>>>>>
>>>>><one scheme="tel" id="+1-212-555-1234"/>
>>>>>
>>>>>or
>>>>>
>>>>><one scheme="sip" id="alice@example.com"/>
>>>>>
>>>>>if you really only want to match SIP identity 
>>>>
>>sip:alice@example.com.
>>
>>>>>The default with no scheme parameter is "matches any 
>>>>
>>user@domain scheme".
>>
>>>>>In order to complete finishing the section of the spec, I'd value 
>>>>>quick feedback on the idea.
>>>>>
>>>>>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
>>>
>>
>>_______________________________________________
>>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 Aug 12 10:01:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3a6K-0008OZ-5R; Fri, 12 Aug 2005 10:01:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3a6I-0008OG-Ie
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 10:01:34 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23619
	for <simple@ietf.org>; Fri, 12 Aug 2005 10:01:32 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.195])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3aem-0001oh-JK
	for simple@ietf.org; Fri, 12 Aug 2005 10:37:15 -0400
Received: by zproxy.gmail.com with SMTP id 12so431546nzp
	for <simple@ietf.org>; Fri, 12 Aug 2005 07:01:22 -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=r+X6l6gRKnKHw3n/U8POttlqubaG0NqzTreLsQMzQCAfx7CObGrDZG2HfUtKnPaffDOKH5Hf9hYZlz1xm8RWyBlrd/HmtaT21gwKa2QQmEHHkXTuqehkxQcMekot8kdoPABttfitu4RkZCmzifDaXM0mVIkbcj2Oa/gGrUFazI4=
Received: by 10.36.60.17 with SMTP id i17mr2387704nza;
	Fri, 12 Aug 2005 07:01:22 -0700 (PDT)
Received: by 10.36.59.3 with HTTP; Fri, 12 Aug 2005 07:01:22 -0700 (PDT)
Message-ID: <29ac328c05081207012d9f2afb@mail.gmail.com>
Date: Fri, 12 Aug 2005 22:01:22 +0800
From: Stallman <zodist@gmail.com>
To: simple@ietf.org
Mime-Version: 1.0
X-Spam-Score: 0.5 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Subject: [Simple] MSRP connection problem
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0886045130=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0886045130==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3163_20316097.1123855282318"

------=_Part_3163_20316097.1123855282318
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

hello, everyone.
 I occur an hard problem with MSRP session.
 I act as a conference server, I INVITE alice join my conference,=20
but alice behind a firewall or alice in a private network,=20
how can connect to alice ?
=20
--=20
_______________________________
Reply mail in one business day.
Email: zodist@gmail.com

------=_Part_3163_20316097.1123855282318
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>hello, everyone.</div>
<div>&nbsp;</div>
<div>I occur an&nbsp;hard problem with MSRP session.</div>
<div>&nbsp;</div>
<div>I act as a conference server, I INVITE&nbsp;alice&nbsp;join my confere=
nce, </div>
<div>but alice behind a firewall&nbsp;or alice in a private network, </div>
<div>how can connect to alice ?</div>
<div>&nbsp;</div>
<div><br>-- <br>_______________________________<br>Reply mail in one busine=
ss day.<br>Email: <a href=3D"mailto:zodist@gmail.com">zodist@gmail.com</a> =
</div>

------=_Part_3163_20316097.1123855282318--


--===============0886045130==
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

--===============0886045130==--




From simple-bounces@ietf.org Fri Aug 12 11:22:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3bMC-0006i8-N2; Fri, 12 Aug 2005 11:22:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bM9-0006hn-Qk
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 11:22:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00807
	for <simple@ietf.org>; Fri, 12 Aug 2005 11:21:58 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3bug-0004br-Ga
	for simple@ietf.org; Fri, 12 Aug 2005 11:57:43 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2005 11:21:13 -0400
X-IronPort-AV: i="3.96,103,1122868800"; 
	d="scan'208"; a="66295851:sNHT1049706640"
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 j7CFKrTM012710; 
	Fri, 12 Aug 2005 11:21:10 -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);
	Fri, 12 Aug 2005 11:21:07 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 11:21:07 -0400
Message-ID: <42FCBE62.3010009@cisco.com>
Date: Fri, 12 Aug 2005 11:21:06 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Stallman <zodist@gmail.com>
Subject: Re: [Simple] MSRP connection problem
References: <29ac328c05081207012d9f2afb@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 15:21:07.0044 (UTC)
	FILETIME=[75FA6A40:01C59F51]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

If Alice is in such a situation, then her UA should be configured to use 
an MSRP relay that may be accessed thru the firewall.

	Paul

Stallman wrote:
> hello, everyone.
>  
> I occur an hard problem with MSRP session.
>  
> I act as a conference server, I INVITE alice join my conference,
> but alice behind a firewall or alice in a private network,
> how can connect to alice ?
>  
> 
> -- 
> _______________________________
> Reply mail in one business day.
> Email: zodist@gmail.com <mailto:zodist@gmail.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 Fri Aug 12 13:26:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3dIH-0001I2-BS; Fri, 12 Aug 2005 13:26:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dIE-0001Hl-WE
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 13:26:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06910
	for <simple@ietf.org>; Fri, 12 Aug 2005 13:26:03 -0400 (EDT)
Received: from mgw-ext04.nokia.com ([131.228.20.96])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dql-0008BY-De
	for simple@ietf.org; Fri, 12 Aug 2005 14:01:49 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7CHPiPe021253; Fri, 12 Aug 2005 20:25:44 +0300
Received: from esebh003.NOE.Nokia.com ([172.21.138.82]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 12 Aug 2005 20:25:54 +0300
Received: from [192.168.1.185] ([10.162.253.73]) by esebh003.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 12 Aug 2005 20:25:53 +0300
Message-ID: <42FCDBA0.5090001@nokia.com>
Date: Fri, 12 Aug 2005 20:25:52 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
	<42F9ED00.7000600@cs.columbia.edu>
In-Reply-To: <42F9ED00.7000600@cs.columbia.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 17:25:53.0665 (UTC)
	FILETIME=[E45A1F10:01C59F62]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi Henning,

ext Henning Schulzrinne wrote:
> Aki,
> 
> I have a few concerns about this:
> 
> - user interface: ENUM-style identifiers are not exactly the most 
> user-friendly domain names, given the reversal of digits; I suspect that 
> in many cases, applications will generate the rules, but probably not in 
> all cases.

If these rules end up edited by hand by a human being, then I would 
agree. But is that really realistic assumption?

> - confusion: There's lots of talk about carrier ENUM, using TLDs other 
> than e164.arpa. I suspect we'd see "my number is in e164.org, so let me 
> use that postfix instead".

You are probably right. However, I was proposing that this be merely a 
convention for representing phone numbers; these would actually never be 
used in an actual ENUM query.

> - user expectation: it seems that a user would expect the ENUM entry to 
> exist if one specifies the domain name; this is not likely to be the case;

I would disassociate the representation of telephone numbers from any 
address resolution, but I am starting to see it may not be that easy.

> - consistency: the presence of a "domain" parameter signals that this 
> has 'id' entries with user names in that domain. This clearly makes no 
> sense here.

Correct, this would mean telephone numbers would be matched only using 
the <many> construct, and never the <one>.

> I don't see which problem this would solve compared to the scheme 
> parameter proposal. You'd still have to flag the domain as being 
> "special", as "sip:alice@4.3.2.1.5.5.5.2.3.2.1.e164.arpa" doesn't make a 
> whole lot of sense.

I think the main benefit would be the ability to match based on country 
code for example -- this depending of course whether example.com is 
expected to match *.example.com. I think it should, and I always assumed 
that it does, but Paul didn't think so.

If that is not the case, then the e164.arpa- proposal does not add much.

Cheers,
Aki

> Henning
> 
> 
> Aki Niemi wrote:
> 
>> Hi,
>>
>> I kind of grew fond of the idea Cullen and I came up with in a private 
>> conversation, namely treating telephone numbers as domains similar to 
>> when issuing a DNS ENUM query.
>>
>> In essence, to match +1-232-555-1234, you'd have an identity 
>> conditions such as:
>>
>> <many domain="4.3.2.1.5.5.5.2.3.2.1.e164.arpa" />
>>
>> This has an interesting additional property of being able to match 
>> based on country code, area code, etc. For example, to match all 
>> Finnish telephone numbers, you'd have:
>>
>> <many domain="8.5.3.e164.arpa" />
>>
>> Not being an expert on ENUM or E.164 in general, I suspect this is 
>> horribly broken, but it pleases the aesthethic eye.
> 
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 13:34:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3dQi-00041Z-VB; Fri, 12 Aug 2005 13:34:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dQh-00041T-Hz
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 13:34:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07398
	for <simple@ietf.org>; Fri, 12 Aug 2005 13:34:49 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dzF-0008S6-Ch
	for simple@ietf.org; Fri, 12 Aug 2005 14:10:34 -0400
Received: from sj-core-2.cisco.com (171.71.177.254)
	by sj-iport-5.cisco.com with ESMTP; 12 Aug 2005 10:34:41 -0700
X-IronPort-AV: i="3.96,103,1122879600"; 
	d="scan'208"; a="204504958:sNHT32086596"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CHYQQW024928;
	Fri, 12 Aug 2005 10:34:39 -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);
	Fri, 12 Aug 2005 13:34:33 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 13:34:32 -0400
Message-ID: <42FCDDA8.6030409@cisco.com>
Date: Fri, 12 Aug 2005 13:34:32 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Stallman <zodist@gmail.com>
Subject: Re: [Simple] MSRP connection problem
References: <29ac328c05081207012d9f2afb@mail.gmail.com>	
	<42FCBE62.3010009@cisco.com>
	<29ac328c050812083220fc1ec6@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 17:34:32.0840 (UTC)
	FILETIME=[19CDF080:01C59F64]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I'm responding to simple too because maybe others want to discuss this.

If you were behind a residential NAT, you might need to use the services
of a relay out in the open internet - maybe its a free one, or maybe you
have to contract for service.

If you are in an enterprise, you probably have your own relay in the DMZ.

Either way, it works because you can connect to it, and it is in a place
where it can both make and receive connections. It sounds like you may
not have seen the MSRP relay draft.It is
draft-ietf-simple-msrp-relays-05.txt.

	Paul

Stallman wrote:
 > the real thing is there are many PC clients use NAT access to Internet.
 > they can not control the NAT policy,
 > does there need a relay and how to initial connection,
 > can you give me an example,? Thanks in advanced.
 >
 >
 > On 8/12/05, *Paul Kyzivat* <pkyzivat@cisco.com
 > <mailto:pkyzivat@cisco.com>> wrote:
 >
 >     If Alice is in such a situation, then her UA should be configured 
to use
 >     an MSRP relay that may be accessed thru the firewall.
 >
 >            Paul
 >
 >     Stallman wrote:
 >      > hello, everyone.
 >      >
 >      > I occur an hard problem with MSRP session.
 >      >
 >      > I act as a conference server, I INVITE alice join my conference,
 >      > but alice behind a firewall or alice in a private network,
 >      > how can connect to alice ?
 >      >
 >      >
 >      > --
 >      > _______________________________
 >      > Reply mail in one business day.
 >      > Email: zodist@gmail.com <mailto:zodist@gmail.com> <mailto:
 >     zodist@gmail.com <mailto:zodist@gmail.com>>
 >      >
 >      >
 >      >
 > 
------------------------------------------------------------------------
 >      >
 >      > _______________________________________________
 >      > Simple mailing list
 >      > Simple@ietf.org <mailto:Simple@ietf.org>
 >      > https://www1.ietf.org/mailman/listinfo/simple
 >
 >
 >
 >
 > --
 > _______________________________
 > Reply mail in one business day.
 > Email: zodist@gmail.com <mailto:zodist@gmail.com>


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 13:46:52 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3dcK-00076s-K5; Fri, 12 Aug 2005 13:46:52 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dcI-00076k-W8
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 13:46:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07795
	for <simple@ietf.org>; Fri, 12 Aug 2005 13:46:49 -0400 (EDT)
Received: from mgw-ext02.nokia.com ([131.228.20.94])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eAq-0000Gb-HD
	for simple@ietf.org; Fri, 12 Aug 2005 14:22:34 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7CHkYfw021730; Fri, 12 Aug 2005 20:46:40 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 12 Aug 2005 20:45:47 +0300
Received: from [192.168.1.185] ([10.162.253.73]) by esebh002.NOE.Nokia.com
	with Microsoft SMTPSVC(5.0.2195.6881); 
	Fri, 12 Aug 2005 20:45:47 +0300
Message-ID: <42FCE04A.80901@nokia.com>
Date: Fri, 12 Aug 2005 20:45:46 +0300
From: Aki Niemi <aki.niemi@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
	<42FA44FE.7020703@cisco.com>
In-Reply-To: <42FA44FE.7020703@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 17:45:47.0352 (UTC)
	FILETIME=[ABD84D80:01C59F65]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org, ext Henning Schulzrinne <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi Paul,

ext Paul Kyzivat wrote:
> Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?
> 
> I don't think you can convert it to:
> 
>    4.3.2.1.5.5.5.2.3.2.1.foo.com
> 
> and if you could then it it wouldn't match the e164.arpa form.

Well, 'sip:+1-232-555-1234@foo.com;user=phone' is indeed a tricky 
identity to put into a From header in the first place. I'm not sure it 
is a telephone number at all. Why wouldn't the From include a tel URL?

I suppose that matching a SIP URI converted from a tel URL will be a 
problem regardless of the way in which we choose to represent them in 
common policy.

>> This has an interesting additional property of being able to match 
>> based on country code, area code, etc. For example, to match all 
>> Finnish telephone numbers, you'd have:
>>
>> <many domain="8.5.3.e164.arpa" />
> 
> 
> It only does if you declare that a domain matches anything it is the 
> tail of. You may sometimes want that, but I don't think you do in general.

Can you describe cases where it should not? I had always assumed 
example.com matched any subdomain of example.com as well. All the way 
down to where domain="org" would match all domains under the .org TLD.

Cheers,
Aki

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 12 15:56:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E3feF-0002WG-64; Fri, 12 Aug 2005 15:56:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E3feD-0002Vo-Q8
	for simple@megatron.ietf.org; Fri, 12 Aug 2005 15:56:58 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15887
	for <simple@ietf.org>; Fri, 12 Aug 2005 15:56:55 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3gCn-000452-Fc
	for simple@ietf.org; Fri, 12 Aug 2005 16:32:41 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 12 Aug 2005 15:56:48 -0400
X-IronPort-AV: i="3.96,103,1122868800"; 
	d="scan'208"; a="66331403:sNHT30814160"
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 j7CJudTC013193; 
	Fri, 12 Aug 2005 15:56:45 -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);
	Fri, 12 Aug 2005 15:56:43 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 15:56:43 -0400
Message-ID: <42FCFEFB.6040502@cisco.com>
Date: Fri, 12 Aug 2005 15:56:43 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Aki Niemi <aki.niemi@nokia.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
	<42FA44FE.7020703@cisco.com> <42FCE04A.80901@nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 19:56:43.0419 (UTC)
	FILETIME=[F66CFEB0:01C59F77]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: 7bit
Cc: simple@ietf.org, ext Henning Schulzrinne <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Aki Niemi wrote:
> Hi Paul,
> 
> ext Paul Kyzivat wrote:
> 
>> Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?
>>
>> I don't think you can convert it to:
>>
>>    4.3.2.1.5.5.5.2.3.2.1.foo.com
>>
>> and if you could then it it wouldn't match the e164.arpa form.
> 
> 
> Well, 'sip:+1-232-555-1234@foo.com;user=phone' is indeed a tricky 
> identity to put into a From header in the first place. I'm not sure it 
> is a telephone number at all. Why wouldn't the From include a tel URL?

Personally, I generally think it should. However I have run into many 
people who don't seem to believe in tel URIs, and always use the sip 
form. I would like to convince them of the error in their ways, but no 
luck so far.

The other case is when I really, definitely, only want to be contacted 
via SIP.

> I suppose that matching a SIP URI converted from a tel URL will be a 
> problem regardless of the way in which we choose to represent them in 
> common policy.

I am relaxing my theoretical objections in favor of pragmatism, and 
suggesting that for purposes of determining what authorization policy to 
apply it will be ok to treat this as a phone number.

>>> This has an interesting additional property of being able to match 
>>> based on country code, area code, etc. For example, to match all 
>>> Finnish telephone numbers, you'd have:
>>>
>>> <many domain="8.5.3.e164.arpa" />
>>
>> It only does if you declare that a domain matches anything it is the 
>> tail of. You may sometimes want that, but I don't think you do in 
>> general.
> 
> Can you describe cases where it should not? I had always assumed 
> example.com matched any subdomain of example.com as well. All the way 
> down to where domain="org" would match all domains under the .org TLD.

Well, suppose there is a domain called cisco.com. NAPTR and SRV entries 
map this to phones.cisco.com - a sip server for corporate addresses at 
Cisco. There may be another domain - test.cisco.com with NAPTR and SRV 
entries mapping to test-phones.cisco.com. Those servers are under 
independent administration.

My decision about whether to authorize users from sip:cisco.com is 
independent of whether to authorize users from sip:test.cisco.com. It is 
especially the case that authorizing sip:paul@cisco.com and 
sip:paul@test.cisco.com needs to be independent.

Now I indeed MAY want to authorize all domains ending in cisco.com. But 
that needs to be a choice that I can make or not as I prefer.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 15 03:10:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E4Z6z-0002mq-4N; Mon, 15 Aug 2005 03:10:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E4Z6x-0002ml-VK
	for simple@megatron.ietf.org; Mon, 15 Aug 2005 03:10:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17658
	for <simple@ietf.org>; Mon, 15 Aug 2005 03:10:18 -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.43) id 1E4Zg3-0007eL-3Y
	for simple@ietf.org; Mon, 15 Aug 2005 03:46:35 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Aug 2005 09:09:49 +0200
Message-ID: <3ACC9A25264A684F82C71840111F979847F73D@carrera.eu.tieto.com>
Thread-Topic: Subscription refreshment (2)
Thread-Index: AcWhaFMqy7O8o3uWS9Kb+hZl/WLo/A==
To: <simple@ietf.org>
X-OriginalArrivalTime: 15 Aug 2005 07:09:51.0228 (UTC)
	FILETIME=[544313C0:01C5A168]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Subscription refreshment (2)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello again,

There is one more thing which is still not clear to me. According to RFC =
3261, dialog is described as follows:

(page 69, sec. 12 Dialogs)
...
A dialog is identified at each UA with a dialog ID, which consists of
a Call-ID value, a local tag and a remote tag. The dialog ID at each
UA involved in the dialog is not the same. Specifically, the local
tag at one UA is identical to the remote tag at the peer UA. The
tags are opaque tokens that facilitate the generation of unique
dialog IDs.
 ...

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
As I understand it, the URIs in From and To header are not part of the
dialog id. If I am not correct, could you please clarify it ?




Martin Hynar

Senior Developer

TietoEnator
Czech Software Centre

Direct +420 599 096 022
E-mail martin.hynar@tietoenator.com

Technologicka 372/2
CZ-708 00 Ostrava

www.tietoenator.com





--- previous message ---

Martin.Hynar@tietoenator.com wrote:
> Hello,
>=20
> I am currently testing some SIP SUBSCRIBE functionality, and there is
one thing i am not 100% sure of - mechanism of refreshing a
subscription.
>=20
> Our software implements functionality described in
draft-ietf-sipping-config-framework (Framework for Session Initiation
Protocol User Agent Profile Delivery) but there is nothing about
refreshes - it references RFC 3265.
>=20
>=20
> RFC 3265:
>=20
> 3.1.4.2. Refreshing of Subscriptions
> At any time before a subscription expires, the subscriber may refresh
> the timer on such a subscription by sending another SUBSCRIBE request
> on the same dialog as the existing subscription, and with the same
> "Event" header "id" parameter (if one was present in the initial
> subscription). The handling for such a request is the same as for the
> initial creation of a subscription except as described below.
>=20
> So lets say, i'll send these messages:
>=20
> SUBSCRIBE sip:user@example.com SIP/2.0            // initial subscribe
which creates a subscription to document 'index' which belongs to 'user'
> To: sip:user@example.com
> From: sip:user@example.com;tag=3Da2b3c1
> =
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
m
> ent=3Dindex
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 1 SUBSCRIBE
> ...
>=20
> SIP/2.0 200 OK
> To: sip:user1@example.com;tag=3D12345
   Expires: 3600
> ...

The expires value in the response is important. It specifies when the
subscription will expire if not refreshed first.

> SUBSCRIBE sip:anotheruser@example.com SIP/2.0        // subscribe to
another user - but it is sent on the same dialog, with the same Event
header
> To: sip:anotheruser@example.com;tag=3D12345
> From: sip:user@example.com;tag=3Da2b3c1
> =
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
m
> ent=3Dindex
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 2 SUBSCRIBE
> ...

The above is not valid. All the requests in the dialog must have the
same To and From. (Swapped if the request is sent in the reverse
direction.) If you want to send a subscription for another user then you
must create a new dialog.

To refresh the original subscription, before it expires, send another
subscription in the same dialog, such as:

SUBSCRIBE sip:user@example.com SIP/2.0  // refresh
To: sip:user@example.com;tag=3D12345
From: sip:user@example.com;tag=3Da2b3c1
Event:sip-profile;profile-type=3Dapplication;app-id=3Dresource-lists;docu=
men
t=3Dindex
Call-ID: 55a4f4f62e607b58176548396prasePD11
CSeq: 2 SUBSCRIBE

> Will the second subscribe just refresh the initial one, even if it has
different sip uri in To header ?

No. It is just wrong.

        Paul



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 15 06:13:37 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E4byL-0008KS-Ns; Mon, 15 Aug 2005 06:13:37 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E4byK-0008KJ-5L
	for simple@megatron.ietf.org; Mon, 15 Aug 2005 06:13:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24158
	for <simple@ietf.org>; Mon, 15 Aug 2005 06:13:32 -0400 (EDT)
Received: from david.siemens.com.cn ([194.138.202.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4cXB-0002qr-SS
	for simple@ietf.org; Mon, 15 Aug 2005 06:49:52 -0400
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52])
	by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id j7FA0CR03172
	for <simple@ietf.org>; Mon, 15 Aug 2005 18:00:12 +0800 (CST)
Received: from PEKW910A.cn001.siemens.net (localhost [127.0.0.1])
	by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id j7F9l0o17746
	for <simple@ietf.org>; Mon, 15 Aug 2005 17:47:00 +0800 (CST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Mon, 15 Aug 2005 17:53:53 +0800
Message-ID: <8E1B3F00C246044D90C9100CCDBB43E74FF8A3@PEKW910A.cn001.siemens.net>
Thread-Topic: [XCAP] something about XCAP URI when ADD/DELETE external list 
Thread-Index: AcWc5UH3h7f4LaL/TNm+uJ4DtuqZwgEkoTNA
From: "Hu Bo \(Cory\), SLC COM CD/MN R&D Core \(BJ\)" <hu.bo@siemens.com>
To: <simple@ietf.org>
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] [XCAP] something about XCAP URI when ADD/DELETE external
	list 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,all,

I am implementing XCAP client. Met a problem about external list URI =
defined in [xcap-list-usage-05].
In the ID(Page10), following example is introduced:

<external anchor=3D"http://www.example.org/xcap/resource-lists/users/a
   /foo/~~/resource-lists/list%5b@name=3D%22mkting%22%5d">
        <display-name>Marketing</display-name>
       </external>
So, my question is what if I want to put or modify or delete this =
element,
What kind of URI should be ?

ID list-usage give a statement about this:
"Any characters that are escape encoded are un-escaped,
   and only re-escaped if they cannot be represented within their
   component of the URI.  In other words, if the grammar for a part of
   the URI disallows a certain character, but that character needs to be
   present, it is escape coded."

So, I guess, for instance, the insert operation should contain the=20
request like this:
http://www.example.org/xcap/AUID/users/a/DOC/~~/list/external%5b@anchor=3D=

%22http%3a%2f%2fwww.example.org%2fxcap%2fresource-lists%2fusers%2fa%2ffoo=
%2f~~%2fresource-lists%2flist%5b@name=3D%27mkting%27%5d%22%5d

XML body is same=20
<external anchor=3D"http://www.example.org/xcap/resource-lists/users/a
   /foo/~~/resource-lists/list%5b@name=3D%22mkting%22%5d">
        <display-name>name</display-name>
       </external>

That is we re-escape all chars like / :  [ and ].=20
And another thing is there is "(%22) embedded in the URI, so I think it =
should be transformed to ' (%27).
But it seems doesn't work, server response with cannot insert.
I know there might be related with server behavior, but just for =
discussion,=20
Anyone has ideas whether it is correct or not? Is it specified with =
examples anywhere?
Thanks in advance!

Best Regards /Viele Gr=FC=DFe /Med venlig hilsen=20
Hu Bo

Communications Group=20
Siemens

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 15 09:10:45 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E4ejk-0005Fk-3Y; Mon, 15 Aug 2005 09:10:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ejg-0005Fd-KY
	for simple@megatron.ietf.org; Mon, 15 Aug 2005 09:10:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01977
	for <simple@ietf.org>; Mon, 15 Aug 2005 09:10:39 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fIm-0006kv-IC
	for simple@ietf.org; Mon, 15 Aug 2005 09:46:59 -0400
Received: from sj-core-4.cisco.com (171.68.223.138)
	by sj-iport-5.cisco.com with ESMTP; 15 Aug 2005 06:10:29 -0700
X-IronPort-AV: i="3.96,107,1122879600"; 
	d="scan'208"; a="204870945:sNHT32970300"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7FDAJ2m014350;
	Mon, 15 Aug 2005 06:10:26 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 15 Aug 2005 09:10:19 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 09:10:19 -0400
Message-ID: <4300943A.4040109@cisco.com>
Date: Mon, 15 Aug 2005 09:10:18 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Martin.Hynar@tietoenator.com
Subject: Re: [Simple] Subscription refreshment (2)
References: <3ACC9A25264A684F82C71840111F979847F73D@carrera.eu.tieto.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Aug 2005 13:10:19.0555 (UTC)
	FILETIME=[AFBFDF30:01C5A19A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Martin.Hynar@tietoenator.com wrote:
> Hello again,
> 
> There is one more thing which is still not clear to me. According to RFC 3261, dialog is described as follows:
> 
> (page 69, sec. 12 Dialogs)
> ...
> A dialog is identified at each UA with a dialog ID, which consists of
> a Call-ID value, a local tag and a remote tag. The dialog ID at each
> UA involved in the dialog is not the same. Specifically, the local
> tag at one UA is identical to the remote tag at the peer UA. The
> tags are opaque tokens that facilitate the generation of unique
> dialog IDs.
>  ...
> 
> ========================================================================
> =======================
> As I understand it, the URIs in From and To header are not part of the
> dialog id. If I am not correct, could you please clarify it ?

Martin,

What you say is true. The reason to keep the From and To unchanged is 
for consistency with RFC2543. Once you discard 2543 compatibility it is 
theoretically permissible to change the From and To addresses. This 
however would *not* change the resource subscribed to.

Initially, the resource of the source is specified by the Contact in the 
initial subscribe, and the desired resource of the target is specified 
by the R-URI. When the dialog is established, the target of the 
destination is specified by the Contact address returned in the response 
to the subscribe.

Subsequent subscribes for the same event type and event id in the same 
dialog are updating the state of the same subscription, and not 
establishing a new subscription. Technically it is only the subscription 
state that has an expiration time and that is being updated. The dialog 
itself is not directly updated at all - it merely remains until all the 
usages (e.g. subscriptions) associated with it go away.

You can in principle establish multiple subscriptions within the same 
dialog. However you cannot establish two subscriptions over the dialog 
in the same direction with the same event type and event id. (But note 
that establishing multiple usages of the same dialog is widely 
discouraged - viewed as a feature that should never have been permitted.)

There is great reluctance to change the To and/or From in a dialog. The 
kind of situation where it has been suggested are:
- when a call (because of forwarding) is delivered to a party other than
   the one described by To, some would like to change the To to reflect
   who was reached.

- When the target of the call is a gateway or B2BUA, it is possible to
   switch the party on the far side while retaining the dialog on the
   near side. Some would like to change the corresponding To/From in
   this case.

This is sometimes called the Connected Party ID problem, and there have 
been suggestions for how to address it, though none yet has concensus.

Your original example implied that you were trying to multiplex 
subscriptions to the same event type, but for different resources, 
through the same dialog. Even if this were permissible (and I think it 
is not), then one subscription would not refresh any of the other 
subscriptions. The dialog would remain until the last subscription 
expired, but without refreshing, all the subscriptions would eventually 
expire.

	Paul

> Martin Hynar
> 
> Senior Developer
> 
> TietoEnator
> Czech Software Centre
> 
> Direct +420 599 096 022
> E-mail martin.hynar@tietoenator.com
> 
> Technologicka 372/2
> CZ-708 00 Ostrava
> 
> www.tietoenator.com
> 
> 
> 
> 
> 
> --- previous message ---
> 
> Martin.Hynar@tietoenator.com wrote:
> 
>>Hello,
>>
>>I am currently testing some SIP SUBSCRIBE functionality, and there is
> 
> one thing i am not 100% sure of - mechanism of refreshing a
> subscription.
> 
>>Our software implements functionality described in
> 
> draft-ietf-sipping-config-framework (Framework for Session Initiation
> Protocol User Agent Profile Delivery) but there is nothing about
> refreshes - it references RFC 3265.
> 
>>
>>RFC 3265:
>>
>>3.1.4.2. Refreshing of Subscriptions
>>At any time before a subscription expires, the subscriber may refresh
>>the timer on such a subscription by sending another SUBSCRIBE request
>>on the same dialog as the existing subscription, and with the same
>>"Event" header "id" parameter (if one was present in the initial
>>subscription). The handling for such a request is the same as for the
>>initial creation of a subscription except as described below.
>>
>>So lets say, i'll send these messages:
>>
>>SUBSCRIBE sip:user@example.com SIP/2.0            // initial subscribe
> 
> which creates a subscription to document 'index' which belongs to 'user'
> 
>>To: sip:user@example.com
>>From: sip:user@example.com;tag=a2b3c1
>>Event:sip-profile;profile-type=application;app-id=resource-lists;docum
>>ent=index
>>Call-ID: 55a4f4f62e607b58176548396prasePD11
>>CSeq: 1 SUBSCRIBE
>>...
>>
>>SIP/2.0 200 OK
>>To: sip:user1@example.com;tag=12345
> 
>    Expires: 3600
> 
>>...
> 
> 
> The expires value in the response is important. It specifies when the
> subscription will expire if not refreshed first.
> 
> 
>>SUBSCRIBE sip:anotheruser@example.com SIP/2.0        // subscribe to
> 
> another user - but it is sent on the same dialog, with the same Event
> header
> 
>>To: sip:anotheruser@example.com;tag=12345
>>From: sip:user@example.com;tag=a2b3c1
>>Event:sip-profile;profile-type=application;app-id=resource-lists;docum
>>ent=index
>>Call-ID: 55a4f4f62e607b58176548396prasePD11
>>CSeq: 2 SUBSCRIBE
>>...
> 
> 
> The above is not valid. All the requests in the dialog must have the
> same To and From. (Swapped if the request is sent in the reverse
> direction.) If you want to send a subscription for another user then you
> must create a new dialog.
> 
> To refresh the original subscription, before it expires, send another
> subscription in the same dialog, such as:
> 
> SUBSCRIBE sip:user@example.com SIP/2.0  // refresh
> To: sip:user@example.com;tag=12345
> From: sip:user@example.com;tag=a2b3c1
> Event:sip-profile;profile-type=application;app-id=resource-lists;documen
> t=index
> Call-ID: 55a4f4f62e607b58176548396prasePD11
> CSeq: 2 SUBSCRIBE
> 
> 
>>Will the second subscribe just refresh the initial one, even if it has
> 
> different sip uri in To header ?
> 
> No. It is just wrong.
> 
>         Paul
> 
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 16 08:49:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E50sX-00081J-D2; Tue, 16 Aug 2005 08:49:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E50sS-0007ym-I1
	for simple@megatron.ietf.org; Tue, 16 Aug 2005 08:49:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07934
	for <simple@ietf.org>; Tue, 16 Aug 2005 08:49:10 -0400 (EDT)
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E51Rj-0008LH-7o
	for simple@ietf.org; Tue, 16 Aug 2005 09:25:44 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILB000MKFX1BN@szxga02-in.huawei.com> for
	simple@ietf.org; Tue, 16 Aug 2005 20:55:49 +0800 (CST)
Received: from szxml01-in ([172.24.1.3])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILB00D63FX1FN@szxga02-in.huawei.com> for
	simple@ietf.org; Tue, 16 Aug 2005 20:55:49 +0800 (CST)
Received: from w39649a ([10.76.176.178])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0ILB00HBGG2408@szxml01-in.huawei.com>; Tue,
	16 Aug 2005 20:58:52 +0800 (CST)
Date: Tue, 16 Aug 2005 20:49:28 +0800
From: wangxiao <wangsmile@huawei.com>
Subject: RE: [Simple] MSRP connection problem
In-reply-to: <42FCDDA8.6030409@cisco.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, "'Stallman'" <zodist@gmail.com>
Message-id: <000001c5a260$f0ab5e90$b2b04c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi, Paul
I think of your meams is that relay is a proxy used to transmit the message.
The user behind a NAT,he can connect relay which provides service for him.
Because of use TCP,so connect relay successful,both relay and user can send 
data cross NAT. But there has another problem,MSRP uses INVITE and its
response
to exchange SDP(offer/answer).The INVITE how to cross NAT?( whether or not
the user must use TCP to receive INVITE?)

Thanks

Thank for 

Sean Wang

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Saturday, August 13, 2005 1:35 AM
To: Stallman
Cc: simple@ietf.org
Subject: Re: [Simple] MSRP connection problem

I'm responding to simple too because maybe others want to discuss this.

If you were behind a residential NAT, you might need to use the services
of a relay out in the open internet - maybe its a free one, or maybe you
have to contract for service.

If you are in an enterprise, you probably have your own relay in the DMZ.

Either way, it works because you can connect to it, and it is in a place
where it can both make and receive connections. It sounds like you may
not have seen the MSRP relay draft.It is
draft-ietf-simple-msrp-relays-05.txt.

	Paul

Stallman wrote:
 > the real thing is there are many PC clients use NAT access to Internet.
 > they can not control the NAT policy,
 > does there need a relay and how to initial connection,
 > can you give me an example,? Thanks in advanced.
 >
 >
 > On 8/12/05, *Paul Kyzivat* <pkyzivat@cisco.com
 > <mailto:pkyzivat@cisco.com>> wrote:
 >
 >     If Alice is in such a situation, then her UA should be configured 
to use
 >     an MSRP relay that may be accessed thru the firewall.
 >
 >            Paul
 >
 >     Stallman wrote:
 >      > hello, everyone.
 >      >
 >      > I occur an hard problem with MSRP session.
 >      >
 >      > I act as a conference server, I INVITE alice join my conference,
 >      > but alice behind a firewall or alice in a private network,
 >      > how can connect to alice ?
 >      >
 >      >
 >      > --
 >      > _______________________________
 >      > Reply mail in one business day.
 >      > Email: zodist@gmail.com <mailto:zodist@gmail.com> <mailto:
 >     zodist@gmail.com <mailto:zodist@gmail.com>>
 >      >
 >      >
 >      >
 > 
------------------------------------------------------------------------
 >      >
 >      > _______________________________________________
 >      > Simple mailing list
 >      > Simple@ietf.org <mailto:Simple@ietf.org>
 >      > https://www1.ietf.org/mailman/listinfo/simple
 >
 >
 >
 >
 > --
 > _______________________________
 > Reply mail in one business day.
 > Email: zodist@gmail.com <mailto:zodist@gmail.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 Tue Aug 16 14:31:54 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E56E6-00034M-NC; Tue, 16 Aug 2005 14:31:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E56E5-00034E-D8; Tue, 16 Aug 2005 14:31:53 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27361;
	Tue, 16 Aug 2005 14:31:51 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E56nS-0000ei-Io; Tue, 16 Aug 2005 15:08:27 -0400
Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com
	[64.101.149.214]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j7GIYdgV030559
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 16 Aug 2005 13:34:41 -0500
In-Reply-To: <42F08BEA.4070900@cisco.com>
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>	<42ECDEBF.9080502@cisco.com>	<1122883119.8484.40.camel@hed034-145.research.nokia.com>	<42EDE096.2090406@cisco.com>
	<01LRBBOCHK6S000091@mauve.mrochek.com>
	<42EE97F1.5080601@cisco.com> <42EF1926.8020902@cs.columbia.edu>
	<42F08BEA.4070900@cisco.com>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <eb907b00fbc29d8927683f5c944236d5@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
Date: Tue, 16 Aug 2005 13:30:37 -0500
To: Jonathan Rosenberg <jdrosen@cisco.com>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Content-Transfer-Encoding: 7bit
Cc: Jari Urpalainen <jari.urpalainen@nokia.com>,
	Henning Schulzrinne <hgs@cs.columbia.edu>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


>   a. there are subtle differences in the schemas, not noticed during 
> the design, that result in a mismatch in compliance - that is, a 
> document is compliant to the XML schema but NOT the relax-ng 
> definition. It seems hard to PROVE that this cannot happen...
>
Actually, we can prove that it CAN happen. The whole point of the 
Relax-NG definition is that it is narrower than what cane be specified 
with an XML schema. Thus, there are documents that would validate 
according to the XML schema, but not validate according to the Relax-NG 
definition.

The point I believe Jari is making is that the documents that would not 
be valid according to Relax-NG would also not be consistent with the 
draft's usage guidelines, and thus would also appear invalid to the 
visual observer. Consequently, it would be useful to have a stronger 
validation tool than the XML schema available for implementors.

--
Dean


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 16 18:00:57 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E59UP-0006W3-E4; Tue, 16 Aug 2005 18:00:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E59UM-0006Vv-T8
	for simple@megatron.ietf.org; Tue, 16 Aug 2005 18:00:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14998
	for <simple@ietf.org>; Tue, 16 Aug 2005 18:00:51 -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.43) id 1E5A3k-00005s-JF
	for simple@ietf.org; Tue, 16 Aug 2005 18:37:31 -0400
Received: from [10.10.108.58] ([65.119.52.228]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j7GLwZUd092617
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Tue, 16 Aug 2005 16:58:36 -0500 (CDT) (envelope-from ben@nostrum.com)
In-Reply-To: <1123767015.3994.16.camel@hed040-040103.research.nokia.com>
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>
	<42FA64A0.1020109@cisco.com>
	<1123767015.3994.16.camel@hed040-040103.research.nokia.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <C3DBDE8D-E681-4ABD-A840-DC3A6D04C7FB@nostrum.com>
Content-Transfer-Encoding: quoted-printable
From: Ben Campbell <ben@nostrum.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
Date: Tue, 16 Aug 2005 16:58:28 -0500
To: Remi Denis-Courmont <remi.denis-courmont@nokia.com>
X-Mailer: Apple Mail (2.734)
Received-SPF: pass (nostrum.com: 65.119.52.228 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Content-Transfer-Encoding: quoted-printable
Cc: ext Paul Kyzivat <pkyzivat@cisco.com>, SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


On Aug 11, 2005, at 8:30 AM, Remi Denis-Courmont wrote:

>     Hello,
>
> Le mer 10/08/2005 =E0 23:33, ext Paul Kyzivat a =E9crit :
>
>> The cases where reordering can occur are actually pretty obscure I
>> think. (Somebody correct me if I am wrong.) The one I can think of =20=

>> is:
>>
>> - Two connections between a pair of relays. Two messages from same
>> connection get sent, one over each connection. The 1st message is =20
>> very
>> long, while the 2nd is very short. The last byte of the 2nd =20
>> message may
>> be received before the last byte of the first message. Then it gets
>> forwarded on.
>>
>
> That only happens if relays are to maintain multiple connections to =20=

> the
> same peer. Might be wrong, but I doubt ensuring they only have one
> connection at a time (of course renewing should it fail) would pose =20=

> any
> problem nor much additionnal load.
>

Multiple simultaneous connections to the same peer are not required. =20
One corner case that was discussed is that a relay sends a message to =20=

a downstream relay, terminates the connection for whatever reason, =20
then reconnects to send a new message--but this connection is in fact =20=

to a different downstream relay for load balancing reasons. The two =20
messages now follow different paths through the network, and cannot =20
be guaranteed to arrive in order.


> On the other hand, supporting re-ordering, without any sane limit =20
> on the
> re-ordering window size sounds very dangerous and prone to abuse to =20=

> me.
> At least, there ought to be an error code for client not able or not
> willing to accept a chunk because of memory constraints.

Reordering should be rare enough that I am not convinced we need to =20
solve this problem. But I will as usual yield to the work group =20
consensus on that matter. What do others think?

>
> --=20
> Remi Denis-Courmont <remi.denis-courmont@nokia.com>
> Nokia-NRC/Helsinki
>
> _______________________________________________
> 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 Aug 16 19:39:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5B1W-0003gs-8q; Tue, 16 Aug 2005 19:39:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5B1U-0003gk-Jg
	for simple@megatron.ietf.org; Tue, 16 Aug 2005 19:39:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21019
	for <simple@ietf.org>; Tue, 16 Aug 2005 19:39:09 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Bav-0002SF-H6
	for simple@ietf.org; Tue, 16 Aug 2005 20:15:49 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 16 Aug 2005 19:39:04 -0400
X-IronPort-AV: i="3.96,114,1122868800"; 
	d="scan'208"; a="66739227:sNHT32377598"
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 j7GNd1T6017528; 
	Tue, 16 Aug 2005 19:39:01 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 16 Aug 2005 19:39:01 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 19:39:00 -0400
Message-ID: <43027914.3060602@cisco.com>
Date: Tue, 16 Aug 2005 19:39:00 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: wangxiao <wangsmile@huawei.com>
Subject: Re: [Simple] MSRP connection problem
References: <000001c5a260$f0ab5e90$b2b04c0a@china.huawei.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Aug 2005 23:39:00.0924 (UTC)
	FILETIME=[ADD9BFC0:01C5A2BB]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



wangxiao wrote:
> Hi, Paul
> I think of your meams is that relay is a proxy used to transmit the message.

Its not a SIP Proxy, but you could consider it a proxy in the generic sense.

> The user behind a NAT,he can connect relay which provides service for him.
> Because of use TCP,so connect relay successful,both relay and user can send 
> data cross NAT. But there has another problem,MSRP uses INVITE and its
> response
> to exchange SDP(offer/answer).The INVITE how to cross NAT?( whether or not
> the user must use TCP to receive INVITE?)

There is extensive discussion of this subject on the SIP, SIPPING, and 
SIP-IMPLEMENTORS lists, as well as various drafts.

This subject is essentialy the same as for a voice call. The MSRP relay 
can be considered to be the SIMPLE equivalent of the TURN server that is 
used to relay RTP if NATs prevent something simpler.

	Paul

> Thanks
> 
> Thank for 
> 
> Sean Wang
> 
> -----Original Message-----
> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of
> Paul Kyzivat
> Sent: Saturday, August 13, 2005 1:35 AM
> To: Stallman
> Cc: simple@ietf.org
> Subject: Re: [Simple] MSRP connection problem
> 
> I'm responding to simple too because maybe others want to discuss this.
> 
> If you were behind a residential NAT, you might need to use the services
> of a relay out in the open internet - maybe its a free one, or maybe you
> have to contract for service.
> 
> If you are in an enterprise, you probably have your own relay in the DMZ.
> 
> Either way, it works because you can connect to it, and it is in a place
> where it can both make and receive connections. It sounds like you may
> not have seen the MSRP relay draft.It is
> draft-ietf-simple-msrp-relays-05.txt.
> 
> 	Paul
> 
> Stallman wrote:
>  > the real thing is there are many PC clients use NAT access to Internet.
>  > they can not control the NAT policy,
>  > does there need a relay and how to initial connection,
>  > can you give me an example,? Thanks in advanced.
>  >
>  >
>  > On 8/12/05, *Paul Kyzivat* <pkyzivat@cisco.com
>  > <mailto:pkyzivat@cisco.com>> wrote:
>  >
>  >     If Alice is in such a situation, then her UA should be configured 
> to use
>  >     an MSRP relay that may be accessed thru the firewall.
>  >
>  >            Paul
>  >
>  >     Stallman wrote:
>  >      > hello, everyone.
>  >      >
>  >      > I occur an hard problem with MSRP session.
>  >      >
>  >      > I act as a conference server, I INVITE alice join my conference,
>  >      > but alice behind a firewall or alice in a private network,
>  >      > how can connect to alice ?
>  >      >
>  >      >
>  >      > --
>  >      > _______________________________
>  >      > Reply mail in one business day.
>  >      > Email: zodist@gmail.com <mailto:zodist@gmail.com> <mailto:
>  >     zodist@gmail.com <mailto:zodist@gmail.com>>
>  >      >
>  >      >
>  >      >
>  > 
> ------------------------------------------------------------------------
>  >      >
>  >      > _______________________________________________
>  >      > Simple mailing list
>  >      > Simple@ietf.org <mailto:Simple@ietf.org>
>  >      > https://www1.ietf.org/mailman/listinfo/simple
>  >
>  >
>  >
>  >
>  > --
>  > _______________________________
>  > Reply mail in one business day.
>  > Email: zodist@gmail.com <mailto:zodist@gmail.com>
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 16 19:57:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5BJ8-0007vo-2q; Tue, 16 Aug 2005 19:57:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5BJ5-0007ve-SZ
	for simple@megatron.ietf.org; Tue, 16 Aug 2005 19:57:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25163
	for <simple@ietf.org>; Tue, 16 Aug 2005 19:57:22 -0400 (EDT)
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5BsU-0003Iv-TN
	for simple@ietf.org; Tue, 16 Aug 2005 20:34:01 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-4.cisco.com with ESMTP; 16 Aug 2005 16:57:12 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7GNv9oo005427;
	Tue, 16 Aug 2005 16:57:10 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 16 Aug 2005 19:57:09 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Aug 2005 19:57:08 -0400
Message-ID: <43027D54.7050602@cisco.com>
Date: Tue, 16 Aug 2005 19:57:08 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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 <ben@nostrum.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>
	<42FA64A0.1020109@cisco.com>
	<1123767015.3994.16.camel@hed040-040103.research.nokia.com>
	<C3DBDE8D-E681-4ABD-A840-DC3A6D04C7FB@nostrum.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 16 Aug 2005 23:57:08.0947 (UTC)
	FILETIME=[365CE230:01C5A2BE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Content-Transfer-Encoding: 7bit
Cc: SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Ben Campbell wrote:

>> On the other hand, supporting re-ordering, without any sane limit  on the
>> re-ordering window size sounds very dangerous and prone to abuse to  me.
>> At least, there ought to be an error code for client not able or not
>> willing to accept a chunk because of memory constraints.
> 
> 
> Reordering should be rare enough that I am not convinced we need to  
> solve this problem. But I will as usual yield to the work group  
> consensus on that matter. What do others think?

I think we don't address this now, in the interest of getting done.

Relays can be built with unreasonable amounts of storage to buffer messages.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 17 02:04:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5H2N-0004NK-Ts; Wed, 17 Aug 2005 02:04:31 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5H2K-0004N1-7H; Wed, 17 Aug 2005 02:04:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14774;
	Wed, 17 Aug 2005 02:04:26 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E5Hbn-0003PA-0m; Wed, 17 Aug 2005 02:41:08 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2005 01:29:57 -0400
X-IronPort-AV: i="3.96,115,1122868800"; 
	d="scan'208"; a="66763590:sNHT31277916"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7H5TtQl020605; 
	Wed, 17 Aug 2005 01:29:56 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 17 Aug 2005 01:29:55 -0400
Received: from [12.42.83.114] ([10.82.218.244]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 Aug 2005 01:29:54 -0400
Message-ID: <4302872A.2090709@cisco.com>
Date: Tue, 16 Aug 2005 20:39:06 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu>
	<42F9CF66.2070604@nokia.com>	<42FA44FE.7020703@cisco.com>
	<42FCE04A.80901@nokia.com> <42FCFEFB.6040502@cisco.com>
In-Reply-To: <42FCFEFB.6040502@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Aug 2005 05:29:54.0809 (UTC)
	FILETIME=[B2F1A690:01C5A2EC]
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Aki Niemi <aki.niemi@nokia.com>,
	simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

cc'ing geopriv since all of this is about a geopriv document.

I'll reply to some of the technical comments inline, but I want to step 
back a second here.

All of this discussion is making it clear that there is a MUCH bigger 
mess here that needs attention, around phone number usage, 
interpretation and equivalence across tel and SIP URI. This is a common 
source of interop problems in the wild and it makes sense to address it. 
However, the problem at hand is to complete the common policy document, 
and it seems to me a mistake to hold up common policy until that mess is 
sorted out. Furthermore, I would argue that the common policy spec is 
not the place where that mess should be sorted out.

My suggestion therefore is to keep the "id" attribute as an NAI form, 
and make sure common policy is extensible to allow other ways of 
representing identities in the future. We then declare phone numbers out 
of scope for this version of common policy, finish that spec, sort out 
the tel/sip uri mess, and when thats done, we can issue an extension to 
common policy that adds phone number support.

more inline.

Paul Kyzivat wrote:

> 
> 
> Aki Niemi wrote:
> 
>> Hi Paul,
>>
>> ext Paul Kyzivat wrote:
>>
>>> Then what do you do with sip:+1-232-555-1234@foo.com;user=phone ?
>>>
>>> I don't think you can convert it to:
>>>
>>>    4.3.2.1.5.5.5.2.3.2.1.foo.com
>>>
>>> and if you could then it it wouldn't match the e164.arpa form.
>>
>>
>>
>> Well, 'sip:+1-232-555-1234@foo.com;user=phone' is indeed a tricky 
>> identity to put into a From header in the first place. I'm not sure it 
>> is a telephone number at all. Why wouldn't the From include a tel URL?
> 
> 
> Personally, I generally think it should. However I have run into many 
> people who don't seem to believe in tel URIs, and always use the sip 
> form. I would like to convince them of the error in their ways, but no 
> luck so far.

I think the problem is that we've not made it clear what the semantic 
differences really are.

> 
> The other case is when I really, definitely, only want to be contacted 
> via SIP.
> 
>> I suppose that matching a SIP URI converted from a tel URL will be a 
>> problem regardless of the way in which we choose to represent them in 
>> common policy.
> 
> 
> I am relaxing my theoretical objections in favor of pragmatism, and 
> suggesting that for purposes of determining what authorization policy to 
> apply it will be ok to treat this as a phone number.

Stepping back for a sec, I think there are real differences between the 
tel URI and the sip version. The way to think about it is that the tel 
URI is a NAME, and you need to think of it as if it were a URN. A SIP 
URI is an address. Procedures like enum allow the resolution of a name 
to an address.

As such, it really makes no sense to compare a name and an address. Just 
because I work at 600 Lanidex Plaza in Parsippany, does that make 
"Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza, 
Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel 
URI and SIP URL are NEVER equivalent; you need to convert the name to an 
address for comparison.

Givne this, the meaning of sip:<phone-number>@domain;user=phone means 
that the domain is asserting ownership of the identity in the user part, 
in this case a global phone number. As such, its appropriate to use this 
form only when it is authoritatively known that the domain in question 
"owns" that phone number.

-Jonathan R.
-- 
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 Aug 17 02:28:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5HPA-0000du-Ol; Wed, 17 Aug 2005 02:28:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HP8-0000dm-UE
	for simple@megatron.ietf.org; Wed, 17 Aug 2005 02:28:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05240
	for <simple@ietf.org>; Wed, 17 Aug 2005 02:28:01 -0400 (EDT)
Received: from galaxy.systems.pipex.net ([62.241.162.31])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5HyR-0003sI-Et
	for simple@ietf.org; Wed, 17 Aug 2005 03:04:43 -0400
Received: from [61.5.100.57] (unknown [61.5.100.57])
	by galaxy.systems.pipex.net (Postfix) with ESMTP id 7F7A6E0001AD;
	Wed, 17 Aug 2005 07:27:24 +0100 (BST)
Message-ID: <43032DC3.8080700@bulukucing.org>
Date: Wed, 17 Aug 2005 13:29:55 +0100
From: Benny Prijono <lists@bulukucing.org>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>	<42FA64A0.1020109@cisco.com>	<1123767015.3994.16.camel@hed040-040103.research.nokia.com>	<C3DBDE8D-E681-4ABD-A840-DC3A6D04C7FB@nostrum.com>
	<43027D54.7050602@cisco.com>
In-Reply-To: <43027D54.7050602@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.8 (++)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Paul Kyzivat wrote:
>> Reordering should be rare enough that I am not convinced we need to  
>> solve this problem. But I will as usual yield to the work group  
>> consensus on that matter. What do others think?
> 
> I think we don't address this now, in the interest of getting done.
> 

I think we may *not* even need to address this at all.
Isn't it the draft-ietf-simple-message-sessions-11 pretty clear about 
this, i.e. client must be prepared to receive out-of-order messages?

IMO that means, implementors of MSRP clients/endpoints SHOULD handle 
out-of-order chunks if they think it's important. And implementors of 
MSRP relays *MAY* implement reordering if they think they're very clever. :)

> Relays can be built with unreasonable amounts of storage to buffer 
> messages.
> 

That's not necessary. See above.

-benny

>     Paul
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 17 02:58:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5Hs7-0006Yf-Su; Wed, 17 Aug 2005 02:57:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Hs5-0006U4-Hi
	for simple@megatron.ietf.org; Wed, 17 Aug 2005 02:57:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10322
	for <simple@ietf.org>; Wed, 17 Aug 2005 02:57:56 -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.43)
	id 1E5IRa-0004kY-2a
	for simple@ietf.org; Wed, 17 Aug 2005 03:34:38 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-2.cisco.com with ESMTP; 16 Aug 2005 22:29:59 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7H5Tqos022468;
	Tue, 16 Aug 2005 22:29:58 -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);
	Wed, 17 Aug 2005 01:29:57 -0400
Received: from [12.42.83.114] ([10.82.218.244]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 Aug 2005 01:29:57 -0400
Message-ID: <43028B85.5060100@cisco.com>
Date: Tue, 16 Aug 2005 20:57:41 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only	the XML fragment body.
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
In-Reply-To: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Aug 2005 05:29:57.0165 (UTC)
	FILETIME=[B45925D0:01C5A2EC]
X-Spam-Score: 0.7 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

inline.

Hyttfors, Per wrote:

> Hello,
>  
> As I see it there is a major problem with retrieving elements in an XML 
> document using XCAP. The problem has to do with that the XDM clients has 
> to know all the namespace prefix bindings in the server document prio 
> the fetch of an element.
>  
> The problem is that the current XCAP specification only mandates that a 
> XCAP fragment body is sent between server and client when performing 
> XCAP operations. Not being an fcs document with the fragment context 
> specification leads to problems now when the XCAP URL has been made 
> independent of the namespaces prefixes used in the document on the server.
>  
> The XML data returned in the 200 OK answer on a fetch of an element will 
> contain the exact content of that element in the XML document on the 
> server. If this element or any child elements use namespace prefixes 
> declared earlier in the document they will not be included in the 
> response to the client. Hence the only way to know all the prefixes is 
> to have done a fetch of the whole document.

The client doesn't need the whole document; it just needs the portion of 
the document above the element that has been fetched, in order to know 
the namespace bindings that are in scope for the element that is being 
fetched.

I'm assuming that you have in mind an application where the client 
doesn't normally store the whole document, for example a cell phone 
where I want to retrieve portions of my buddy list one buddy at a time.

As such, one solution is to fetch the whole document at startup, get the 
namespace bindings and etag, and dump the document. Then, subsequent 
GETs are conditional against the etag, and so the client can get the 
information it needs and use the cached namespace bindings.

This is clearly not optimal since it requires a full document get just 
to obtain the namespace bindings. However, it works with the current spec.

Some other thoughts are:

1. an xcap extension that allowed to specifically query for the 
namespace bindings in scope for a particular element

2. change xcap so that what is returned is an xml fragment that includes 
additional information on the namespace bindings in scope

3. have the xcap server return xml data using the namespace bindings in 
scope for the request URI. This requires the server to modify the xml 
data before sending it to the client


> 
> Just to clarify the problem I have made these examples (inspiration from 
> the XCAP specification..)
>  
> Bill has not fetched the whole server document, and it looks like this:
>  
>    <?xml version="1.0" encoding="UTF-8"?>
>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>     <service uri="sip:marketing@example.com">
>       <a:list name="marketing">
>         <a:entry uri="sip:joe@example.com"/>
>         <a:entry uri="sip:sudhir@example.com"/>
>       </a:list>
>       <packages>
>         <package>presence</package>
>       </packages>
>     </service>
>    </rls-services>
>  
> 
> Bill decides to get the service information for uri 
> sip:marketing@example.com
>  
>    GET
>    /rls-services/users/bill/index/~~/rls-services/
>    service%5b@uri=%22sip:marketing@example.com%5d 
> <mailto:service%5b@uri=%22sip:marketing@example.com%5d>
>     HTTP/1.1
>  
>    and the server responds:
>  
>    HTTP/1.1 200 OK
>    Etag: "ad88"
>    Content-Type:application/xcap-el+xml
>  
>     <service uri="sip:marketing@example.com">
>       <a:list name="marketing">
>         <a:entry uri="sip:joe@example.com"/>
>         <a:entry uri="sip:sudhir@example.com"/>
>       </a:list>
>       <packages>
>         <package>presence</package>
>       </packages>
>     </service>
>  
> Bill is now confused as he has no idea what namespace the tags that are 
> using the namespace prefix a: belongs to, so he has to fetch the whole 
> document to find out....
>  
>  
> Also as disscussed earlier: 
> http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html the 
> XDM client has to always send the xmlns declaration with the XML 
> elements that are sent in a PUT in order to be sure that it will be a 
> valid part of the complete XML document on the server..
>  
> This would be a situation where the client would have a problem if the 
> xmlns declaration is missing in the XML fragment body:
> 
> The server document looks like this:
>  
>    <?xml version="1.0" encoding="UTF-8"?>
>    <a:resource-lists xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>     <a:list name="close-friends">
>      <a:display-name>Close Friends</a:display-name>
>      <a:entry uri="sip:joe@example.com">
>       <a:display-name>Joe Smith</a:display-name>
>      </a:entry>
>     </a:list>
>    </a:resource-lists>
>  
> Bill creates an element in the resource-lists document (Section 7.4).  
> In particular, he creates a list with an entry:
> 
>    PUT
>    /services/resource-lists/users/bill/fr.xml
>    /~~/resource-lists/list%5b@name=%22friends%22%5d HTTP/1.1
>    Content-Type:application/xcap-el+xml
>    Host: xcap.example.com
>  
>    <list name="friends">
>      <entry uri="sip:bob@example.com">
>        <display-name>Bob Jones</display-name>
>      </entry>
>    </list>
>  
> Bill will cry as the validation of the document after the tentatively 
> insertion will fail as this will produce a invalid XML document..

Yeah, this is another good point. This is the PUT eqiuvalent of the GET 
problem you describe above. Here its easier though; if the client 
doesn't know the namespace bindings because it doesn't have the full 
document, it should include the bindings in the fragment itself.

-Jonathan R.
-- 
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 Aug 17 04:05:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5IvC-0004S5-In; Wed, 17 Aug 2005 04:05:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Iv9-0004Rs-Lr
	for simple@megatron.ietf.org; Wed, 17 Aug 2005 04:05:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13930
	for <simple@ietf.org>; Wed, 17 Aug 2005 04:05:09 -0400 (EDT)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5JUd-000726-LF
	for simple@ietf.org; Wed, 17 Aug 2005 04:41:53 -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
	j7H83xG15547; Wed, 17 Aug 2005 11:03:59 +0300 (EET DST)
X-Scanned: Wed, 17 Aug 2005 11:03:41 +0300 Nokia Message Protector V1.3.35
	2005042208 - RELEASE
Received: (from root@localhost)
	by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j7H83fdF022469;
	Wed, 17 Aug 2005 11:03:41 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks002.ntc.nokia.com 00Yuot5b; Wed, 17 Aug 2005 11:03:40 EEST
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j7H83eK23667; Wed, 17 Aug 2005 11:03:40 +0300 (EET DST)
Received: from xitami.research.nokia.com (xitami.research.nokia.com
	[172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP
	id F310193B6A; Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com
	[172.21.34.145])
	by xitami.research.nokia.com (Postfix) with ESMTP id C660771D;
	Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only	the XML fragment body.
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
In-Reply-To: <43028B85.5060100@cisco.com>
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
	<43028B85.5060100@cisco.com>
Content-Type: text/plain
Date: Wed, 17 Aug 2005 11:03:39 +0300
Message-Id: <1124265819.11970.26.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Tue, 2005-08-16 at 20:57 -0400, ext Jonathan Rosenberg wrote:
> inline.
> 
> Hyttfors, Per wrote:
> 
> > Hello,
> >  
> > As I see it there is a major problem with retrieving elements in an XML 
> > document using XCAP. The problem has to do with that the XDM clients has 
> > to know all the namespace prefix bindings in the server document prio 
> > the fetch of an element.
> >  
> > The problem is that the current XCAP specification only mandates that a 
> > XCAP fragment body is sent between server and client when performing 
> > XCAP operations. Not being an fcs document with the fragment context 
> > specification leads to problems now when the XCAP URL has been made 
> > independent of the namespaces prefixes used in the document on the server.
> >  
> > The XML data returned in the 200 OK answer on a fetch of an element will 
> > contain the exact content of that element in the XML document on the 
> > server. If this element or any child elements use namespace prefixes 
> > declared earlier in the document they will not be included in the 
> > response to the client. Hence the only way to know all the prefixes is 
> > to have done a fetch of the whole document.
> 
> The client doesn't need the whole document; it just needs the portion of 
> the document above the element that has been fetched, in order to know 
> the namespace bindings that are in scope for the element that is being 
> fetched.
> 
> I'm assuming that you have in mind an application where the client 
> doesn't normally store the whole document, for example a cell phone 
> where I want to retrieve portions of my buddy list one buddy at a time.
> 
> As such, one solution is to fetch the whole document at startup, get the 
> namespace bindings and etag, and dump the document. Then, subsequent 
> GETs are conditional against the etag, and so the client can get the 
> information it needs and use the cached namespace bindings.
> 
> This is clearly not optimal since it requires a full document get just 
> to obtain the namespace bindings. However, it works with the current spec.
> 
> Some other thoughts are:
> 
> 1. an xcap extension that allowed to specifically query for the 
> namespace bindings in scope for a particular element
> 
> 2. change xcap so that what is returned is an xml fragment that includes 
> additional information on the namespace bindings in scope
> 
> 3. have the xcap server return xml data using the namespace bindings in 
> scope for the request URI. This requires the server to modify the xml 
> data before sending it to the client
> 
I suppose this question has come from OMA people. An XPath way of doing
this could be GET ....~~/root/namespace::*, i.e. namespace axis could be
used to request all the in-scope namespaces of some element. An XCAP
extension should then describe this BNF extension as well as the payload
format.

br,
Jari


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 17 04:58:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5Jkk-0006iK-Au; Wed, 17 Aug 2005 04:58:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Jki-0006iF-SI
	for simple@megatron.ietf.org; Wed, 17 Aug 2005 04:58:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16040
	for <simple@ietf.org>; Wed, 17 Aug 2005 04:58:26 -0400 (EDT)
Received: from mailgw4.ericsson.se ([193.180.251.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5KKD-0008Uk-DU
	for simple@ietf.org; Wed, 17 Aug 2005 05:35:10 -0400
Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120])
	by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id
	23CA04F0002
	for <simple@ietf.org>; Wed, 17 Aug 2005 10:58:24 +0200 (CEST)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by
	esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 Aug 2005 10:58:23 +0200
Received: from localhost ([147.214.118.168]) by esealmw127.eemea.ericsson.se
	with Microsoft SMTPSVC(6.0.3790.211); 
	Wed, 17 Aug 2005 10:58:23 +0200
Received: (nullmailer pid 8024 invoked by uid 1000);
	Wed, 17 Aug 2005 08:58:22 -0000
From: Ignacio Mas Ivars <ignacio.mas.ivars@ericsson.com>
To: simple@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Organization: Ericsson Research
Date: Wed, 17 Aug 2005 10:58:21 +0200
Message-Id: <1124269102.7579.7.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.3.7 
X-OriginalArrivalTime: 17 Aug 2005 08:58:23.0009 (UTC)
	FILETIME=[D2698110:01C5A309]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] MSRP v10 "msrp/tcp" <> MSRP v11 "TCP/MSRP"
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


Hi!

There has been a change between version 10 and version 11 of the MSRP
draft regarding how the protocol field of the m line in the SDP
description is written. Version 10 says:

 An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "msrp/tcp".  The media field value MUST be
   "message".  The format list field MUST be set to "*".


while version 11 changes the field to:

 An offered or accepted media-line for MSRP over TCP MUST include a
   protocol field value of "TCP/MSRP", or "TCP/TLS/MSRP" for TLS.  The
   media field value MUST be "message".  The format list field MUST be
   set to "*".

Is there any particular reason for the change in order? I don't have any
strong opinion about the change, but it requieres modifying existing
prototype implementations and I just wonder if the reason was more
cosmetic than anything else.

Thanks!
/Ignacio

--=20
Ignacio M=E1s Ivars
Service enablers and protocols, Ericsson Research (EAB/TBG/B)
Ericsson AB                     Phone: +46 8 4045580
Torshamsgatan 23                Fax:   +46 8 7575720
SE-164 80 Stockholm, Sweden     mailto: ignacio.mas.ivars@ericsson.com

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 17 07:02:13 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5LgT-0005Rr-Qu; Wed, 17 Aug 2005 07:02:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5LgQ-0005Rb-FH; Wed, 17 Aug 2005 07:02:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21309;
	Wed, 17 Aug 2005 07:02:07 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E5MFw-0003LU-5d; Wed, 17 Aug 2005 07:38:53 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7HB1n2v027350; Wed, 17 Aug 2005 14:01:49 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 17 Aug 2005 14:00:51 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 17 Aug 2005 14:00:50 +0300
Received: from 172.21.34.145 ([172.21.34.145]) by esebe105.NOE.Nokia.com
	([172.21.143.53]) with Microsoft Exchange Server HTTP-DAV ; 
	Wed, 17 Aug 2005 11:00:53 +0000
Received: from hed034-145.research.nokia.com by esebe105.noe.nokia.com;
	17 Aug 2005 14:00:50 +0300
Subject: Re: [xml-dir] Re: [Simple] Presence Relax NG schemas
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Dean Willis <dean.willis@softarmor.com>
In-Reply-To: <eb907b00fbc29d8927683f5c944236d5@softarmor.com>
References: <1122813934.31132.7.camel@hed034-145.research.nokia.com>
	<42ECDEBF.9080502@cisco.com>
	<1122883119.8484.40.camel@hed034-145.research.nokia.com>
	<42EDE096.2090406@cisco.com> <01LRBBOCHK6S000091@mauve.mrochek.com>
	<42EE97F1.5080601@cisco.com> <42EF1926.8020902@cs.columbia.edu>
	<42F08BEA.4070900@cisco.com>
	<eb907b00fbc29d8927683f5c944236d5@softarmor.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Wed, 17 Aug 2005 14:00:50 +0300
Message-Id: <1124276450.15120.52.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
X-OriginalArrivalTime: 17 Aug 2005 11:00:50.0842 (UTC)
	FILETIME=[EE0FD7A0:01C5A31A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>,
	Ned Freed <ned.freed@mrochek.com>, Simple WG <simple@ietf.org>,
	xml-dir@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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

On Tue, 2005-08-16 at 13:30 -0500, ext Dean Willis wrote:
> >   a. there are subtle differences in the schemas, not noticed during 
> > the design, that result in a mismatch in compliance - that is, a 
> > document is compliant to the XML schema but NOT the relax-ng 
> > definition. It seems hard to PROVE that this cannot happen...
> >
> Actually, we can prove that it CAN happen. The whole point of the 
> Relax-NG definition is that it is narrower than what cane be specified 
> with an XML schema. Thus, there are documents that would validate 
> according to the XML schema, but not validate according to the Relax-NG 
> definition.
> 
> The point I believe Jari is making is that the documents that would not 
> be valid according to Relax-NG would also not be consistent with the 
> draft's usage guidelines, and thus would also appear invalid to the 
> visual observer. Consequently, it would be useful to have a stronger 
> validation tool than the XML schema available for implementors.
> 
> --
> Dean
> 
Dean, this was exactly my intention. In conclusion, if I have understood
correctly, there's a rough consensus that this work can continue (as
informative target, of course) ? 

In general, I'll agree with Jonathan's concerns. In theory, there are
some features in W3C Schemas that cannot be represented with RNG, but
they are not used in presence schemas. So, I'll still see that these are
more useful for implementers (and yes reviewers are welcome). Although
I'll agree totally with Tim (and e.g. James Clark's comments etc) about
RNG versus W3C Schemas I wouldn't have bothered to start this work if
W3C schemas would have had a reasonable versioning support (although
there are many other annoyances as well). Furthermore, one of my
favorite libraries (libxml2) supports RNG and the validation performance
is pretty good with it (much faster than a comparable tool for W3C
schemas). Btw. there's an excellent book about RNG
http://books.xmlschemata.org/relaxng/

Another issue is whether WGs should really rethink which validation tool
to use. Personally I hardly would miss W3C Schemas (structures not
datatypes, which are imo ok and which can be used with RNG, too)

br,
Jari

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 10:30:17 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5lPN-0000wD-MG; Thu, 18 Aug 2005 10:30:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E4wp2-00048t-CZ
	for simple@megatron.ietf.org; Tue, 16 Aug 2005 04:29:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27504
	for <simple@ietf.org>; Tue, 16 Aug 2005 04:29:22 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4xOF-0002Bi-1b
	for simple@ietf.org; Tue, 16 Aug 2005 05:05:53 -0400
Received: from rat01047.dc-ratingen.de (rat01047_e0 [195.233.128.119])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7G8SwiS011373
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <simple@ietf.org>; Tue, 16 Aug 2005 10:28:58 +0200 (MEST)
Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115])
	by rat01047.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7G8SwD4003512
	for <simple@ietf.org>; Tue, 16 Aug 2005 10:28:58 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	gpsmxr04.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 16 Aug 2005 10:29:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Aug 2005 09:29:01 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02828BBF@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: Question on draft-ietf-simple-event-list-07.txt
Thread-Index: AcWiPI4BhM8u8SOXTcG4lJT0FTB7jQ==
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 16 Aug 2005 08:29:00.0696 (UTC)
	FILETIME=[8D942180:01C5A23C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 18 Aug 2005 10:30:15 -0400
Subject: [Simple] Question on draft-ietf-simple-event-list-07.txt
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,

In section 4.5 of draft-ietf-simple-event-list-07 it is stated that:=20

"The "state" attribute of each instance of a resource in the meta-
information is set according to the state of the virtual
subscription.  The meanings of the "state" attribute are described in
RFC 3265 [2]"

Does this means that there is 1-to-1 mapping between the
"Subscription-state" header of the NOTIFY request of the back-end
subscription and the "state" attribute of the RLMI? In that case how
will be handled back-end subscriptions that do never get a NOTIFY? I am
particularly looking at two cases:

1. The PS of the back-end subscription does never respond (eg due to
failure)
2. There is a local policy in the RLS that prohibits the RLS to perform
more than a certain number of back-end subscriptions per subscriber.

What are the appropriate values that the "state" attribute of the RLMI
should take in that case? Is there another value necessary for the
enumeration of the "state" element something like "notperformed" for
example?


Best regards,
Haris

Haris Zisimopoulos
Group Research & Development - UK
Vodafone Group Services Ltd

E-mail: haris.zisimopoulos@vodafone.com



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 10:30:18 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5lPO-0000xD-Ea; Thu, 18 Aug 2005 10:30:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5R8y-000389-OH
	for simple@megatron.ietf.org; Wed, 17 Aug 2005 12:52:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11334
	for <simple@ietf.org>; Wed, 17 Aug 2005 12:51:57 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5RiS-0005CK-KQ
	for simple@ietf.org; Wed, 17 Aug 2005 13:28:47 -0400
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7HGpe2U009568
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <simple@ietf.org>; Wed, 17 Aug 2005 18:51:40 +0200 (MEST)
Received: from GPSMXR03.gps.internal.vodafone.com ([195.232.231.125])
	by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7HGpdQd005352
	for <simple@ietf.org>; Wed, 17 Aug 2005 18:51:39 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	GPSMXR03.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 18:51:41 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 17 Aug 2005 17:51:42 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02985329@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: Question on simple-event-list-07
Thread-Index: AcWiPI4BhM8u8SOXTcG4lJT0FTB7jQA6LvoQ
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: <simple@ietf.org>
X-OriginalArrivalTime: 17 Aug 2005 16:51:41.0836 (UTC)
	FILETIME=[F16E9CC0:01C5A34B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 18 Aug 2005 10:30:15 -0400
Subject: [Simple] Question on simple-event-list-07
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,

In section 4.5 of draft-ietf-simple-event-list-07 it is stated that:=20

"The "state" attribute of each instance of a resource in the meta-
information is set according to the state of the virtual subscription.
The meanings of the "state" attribute are described in RFC 3265 [2]"

Does this means that there is 1-to-1 mapping between the
"Subscription-state" header of the NOTIFY request of the back-end
subscription and the "state" attribute of the RLMI? In that case how
will be handled back-end subscriptions that do never get a NOTIFY? I am
particularly looking at two cases:

1. The PS of the back-end subscription does never respond (eg due to
failure) 2. There is a local policy in the RLS that prohibits the RLS to
perform more than a certain number of back-end subscriptions per
subscriber.

What are the appropriate values that the "state" attribute of the RLMI
should take in that case? Is there another value necessary for the
enumeration of the "state" element something like "notperformed" for
example?


Best regards,
Haris

Haris Zisimopoulos
Group Research & Development - UK
Vodafone Group Services Ltd

E-mail: haris.zisimopoulos@vodafone.com



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 13:14:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5nxz-00060Q-9q; Thu, 18 Aug 2005 13:14:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nxx-0005zx-KN
	for simple@megatron.ietf.org; Thu, 18 Aug 2005 13:14:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18268
	for <simple@ietf.org>; Thu, 18 Aug 2005 13:14:06 -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.43) id 1E5oXi-0007iX-Ox
	for simple@ietf.org; Thu, 18 Aug 2005 13:51:08 -0400
Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2])
	(authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j7IHDv7H078217
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 18 Aug 2005 12:13:58 -0500 (CDT)
	(envelope-from adam@nostrum.com)
Message-ID: <4304C1C5.9060909@nostrum.com>
Date: Thu, 18 Aug 2005 12:13:41 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
Subject: Re: [Simple] Question on simple-event-list-07
References: <6C742B4BEC7D1D4FB045E74BB625987B02985329@gpsmx11.gps.internal.vodafone.com>
In-Reply-To: <6C742B4BEC7D1D4FB045E74BB625987B02985329@gpsmx11.gps.internal.vodafone.com>
X-Enigmail-Version: 0.89.5.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 10.10.10.2 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Zisimopoulos, Haris, VF-Group wrote:

>In section 4.5 of draft-ietf-simple-event-list-07 it is stated that: 
>
>"The "state" attribute of each instance of a resource in the meta-
>information is set according to the state of the virtual subscription.
>The meanings of the "state" attribute are described in RFC 3265 [2]"
>
>Does this means that there is 1-to-1 mapping between the
>"Subscription-state" header of the NOTIFY request of the back-end
>subscription and the "state" attribute of the RLMI?
>

They are semantically equivalent. This isn't quite the same thing as 
having a one-to-one mapping, since back-end subscriptions can take the 
form of any arbitrary protocol (not just SIP). In any case, the actual 
linkage between any back end subscriptions -- even if they are SIP -- 
and the resource list subscription is a matter of implementation, not 
standardization. It is certainly *sensible* that you would simply pass 
these states through, but there may be other reasonable things to do as 
well.

>In that case how will be handled back-end subscriptions that do never get a NOTIFY?
>

The  most reasonable thing to do would be to return an RLMI document in 
which the "<resource>" element corresponding to that failed subscription 
contains no "<instance>" elements. See, for example, the entries for 
"sip:ed@dallas.example.com" and "sip:adam-friends@stockholm.example.com" 
in step 3 of the example in section 6.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 17:41:30 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5s8g-00024W-T2; Thu, 18 Aug 2005 17:41:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5s8f-00023v-0f; Thu, 18 Aug 2005 17:41:29 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04834;
	Thu, 18 Aug 2005 17:41:26 -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.43)
	id 1E5siT-0007gU-2F; Thu, 18 Aug 2005 18:18:30 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 18 Aug 2005 14:41:18 -0700
X-IronPort-AV: i="3.96,123,1122879600"; 
	d="scan'208"; a="333588316:sNHT32763292"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7ILfC0L024764;
	Thu, 18 Aug 2005 14:41:15 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 18 Aug 2005 17:41:12 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 17:41:11 -0400
Message-ID: <43050077.3050702@cisco.com>
Date: Thu, 18 Aug 2005 17:41:11 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu>
	<42F9CF66.2070604@nokia.com>	<42FA44FE.7020703@cisco.com>
	<42FCE04A.80901@nokia.com> <42FCFEFB.6040502@cisco.com>
	<4302872A.2090709@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Aug 2005 21:41:12.0030 (UTC)
	FILETIME=[8D499FE0:01C5A43D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Aki Niemi <aki.niemi@nokia.com>,
	simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Jonathan Rosenberg wrote:

>> I am relaxing my theoretical objections in favor of pragmatism, and 
>> suggesting that for purposes of determining what authorization policy 
>> to apply it will be ok to treat this as a phone number.
> 
> Stepping back for a sec, I think there are real differences between the 
> tel URI and the sip version. The way to think about it is that the tel 
> URI is a NAME, and you need to think of it as if it were a URN. A SIP 
> URI is an address. Procedures like enum allow the resolution of a name 
> to an address.
> 
> As such, it really makes no sense to compare a name and an address. Just 
> because I work at 600 Lanidex Plaza in Parsippany, does that make 
> "Jonathan Rosenberg" (a name) equivalent to "600 Lanidex Plaza, 
> Parsippany, NJ 07054"? Definitely not. So, I would argue that the tel 
> URI and SIP URL are NEVER equivalent; you need to convert the name to an 
> address for comparison.
> 
> Givne this, the meaning of sip:<phone-number>@domain;user=phone means 
> that the domain is asserting ownership of the identity in the user part, 
> in this case a global phone number. As such, its appropriate to use this 
> form only when it is authoritatively known that the domain in question 
> "owns" that phone number.

As far as general comparisons are concerned, I agree with you.
But I don't think matching caller "identity" for purposes of 
authorization need be viewed as a general URI comparison problem.

I don't have a lot of control over the way people identify themselves 
when they call me. Somehow I must recognize their identifications of 
themselves in a way that is sufficient for my needs. If I need to do 
funky huristic comparisons to achieve that, so be it.

It is for this reason that I think we can do special things here. We 
know the identification of the caller will be some form of URI. The ones 
if interest here are sip, sips, tel. The values we put into the policy 
don't need to be URIs - practically speaking they are patterns to be 
matched against caller identification. URIs, using URI comparision are 
one form of pattern match. But we can define something looser - either 
the matching algorithm can be different/looser, and/or the pattern 
itself can be different/looser.

What I am proposing is both: patterns that are a superset of valid URIs, 
and a matching algorithm that is similar to but looser than just pattern 
matching. In particular:

- a pattern containing a tel uri would be matched against sip and sips 
uris with user=phone by simply comparing the user parts using tel 
matching rules.

- perhaps allowing a wildcard character in a "tel" pattern - e.g. an "n" 
instead of a digit. Match by ignoring corresponding character in target.

Of course it wouldn't be necessary to use something that looked like tel 
format to represent this. We could make up some other format that was 
clearly specific to the use at hand. Semantically it wouldn't make any 
difference.

Similarly, I think there is an need for a way to say: match either a sip 
or sips uri. That of course is just syntactic sugar, but I doubt people 
will be happy having to include every target twice, so it is probably 
important.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 18:23:53 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5snh-0006KU-MW; Thu, 18 Aug 2005 18:23:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sne-0006KJ-Lx
	for simple@megatron.ietf.org; Thu, 18 Aug 2005 18:23:51 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08155
	for <simple@ietf.org>; Thu, 18 Aug 2005 18:23:47 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tNU-0000W7-8J
	for simple@ietf.org; Thu, 18 Aug 2005 19:00:52 -0400
Received: from rtp-core-1.cisco.com (64.102.124.12)
	by rtp-iport-2.cisco.com with ESMTP; 18 Aug 2005 18:23:42 -0400
X-IronPort-AV: i="3.96,123,1122868800"; 
	d="scan'208"; a="67042373:sNHT30643768"
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 j7IMNcT6024025; 
	Thu, 18 Aug 2005 18:23:39 -0400 (EDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 18 Aug 2005 18:23:43 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 18:23:38 -0400
Message-ID: <43050A69.3030204@cisco.com>
Date: Thu, 18 Aug 2005 18:23:37 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Benny Prijono <lists@bulukucing.org>
Subject: Re: [Simple] Questions regarding MSRP drafts
References: <1123673996.3872.14.camel@hed040-040103.research.nokia.com>	<42FA64A0.1020109@cisco.com>	<1123767015.3994.16.camel@hed040-040103.research.nokia.com>	<C3DBDE8D-E681-4ABD-A840-DC3A6D04C7FB@nostrum.com>
	<43027D54.7050602@cisco.com> <43032DC3.8080700@bulukucing.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Aug 2005 22:23:38.0249 (UTC)
	FILETIME=[7AF3CF90:01C5A443]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: SIMPLE <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Sounds good to me. Then the recipient only needs to be able to buffer 
the largest message it wishes to receive.

Relays still need to be able to buffer a lot to cover the case where the 
source link is fast but the target link is slow.

	Paul

Benny Prijono wrote:
> Paul Kyzivat wrote:
> 
>>> Reordering should be rare enough that I am not convinced we need to  
>>> solve this problem. But I will as usual yield to the work group  
>>> consensus on that matter. What do others think?
>>
>>
>> I think we don't address this now, in the interest of getting done.
>>
> 
> I think we may *not* even need to address this at all.
> Isn't it the draft-ietf-simple-message-sessions-11 pretty clear about 
> this, i.e. client must be prepared to receive out-of-order messages?
> 
> IMO that means, implementors of MSRP clients/endpoints SHOULD handle 
> out-of-order chunks if they think it's important. And implementors of 
> MSRP relays *MAY* implement reordering if they think they're very 
> clever. :)
> 
>> Relays can be built with unreasonable amounts of storage to buffer 
>> messages.
>>
> 
> That's not necessary. See above.
> 
> -benny
> 
>>     Paul
>>
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 19:36:20 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5tvn-00005p-U8; Thu, 18 Aug 2005 19:36:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tvl-000058-P1
	for simple@megatron.ietf.org; Thu, 18 Aug 2005 19:36:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16662
	for <simple@ietf.org>; Thu, 18 Aug 2005 19:36:14 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5uVb-0004Gv-Ox
	for simple@ietf.org; Thu, 18 Aug 2005 20:13:20 -0400
Received: from [64.101.149.214] (dhcp-64-101-149-214.cisco.com
	[64.101.149.214]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j7INeQJ0007728
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 18 Aug 2005 18:40:27 -0500
In-Reply-To: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <3d2faf02c780d760f4f6947ff81ba868@softarmor.com>
Content-Transfer-Encoding: quoted-printable
From: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
Date: Thu, 18 Aug 2005 18:36:24 -0500
To: Simple WG <simple@ietf.org>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b
Content-Transfer-Encoding: quoted-printable
Cc: Kelvin Porter <kelvin_r_porter@yahoo.com>, "Hyttfors,
	Per" <Per.Hyttfors@sonyericsson.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


I'm thinking that this message documents a relatively significant=20
problem either with XCAP or with a usage of XCAP as proposed by OMA=20
PoC.

XCAP is currently in the RFC Editor's Queue, and consequently somewhat=20=

hard to change, but some changes could perhaps be made by an IESG "note=20=

to the RFC editor" if needed (and approved by the IESG).

I'd like to see some discussion of the severity of this problem and=20
what should be done about it -- preferability Very Soon, as OMA is=20
meeting next week.

Possibilities I see:

1) Fix the XCAP spec before publication.

2) Obsolete the current XCAP spec and produce a new one.

3) Define an extension to XCAP to fix the problem.

4) Decide it's not really an XCAP problem, because OMA PoC is using the=20=

protocol in a manner inconsistent with its design requirements, and=20
help OMA PoC come up with a workaround.

5) Something entirely different.

Thanks!

--
Dean WIllis
as IETF liaison to OMA

On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:

> Hello,
> =A0
> As I see it there is a major problem with retrieving elements in an=20
> XML document using XCAP. The problem has to do with that the XDM=20
> clients has to know all the namespace prefix bindings in the server=20
> document prio the fetch of an element.
> =A0
> The problem is that the current XCAP specification only mandates that=20=

> a XCAP fragment body is sent between server and client when performing=20=

> XCAP operations. Not being an fcs document with the fragment context=20=

> specification leads to problems now when the XCAP URL has been made=20
> independent of the namespaces prefixes used in the document on the=20
> server.
> =A0
> The XML data returned in the 200 OK answer on a fetch of an element=20
> will contain the exact content of that element in the XML document on=20=

> the server. If this element or any child elements use namespace=20
> prefixes declared earlier in the document they will not be included in=20=

> the response to the client. Hence the only way to know all the=20
> prefixes is to have done a fetch of the whole document.
>
> Just to clarify the problem I have made these examples (inspiration=20
> from the XCAP specification..)
> =A0
> Bill has not fetched the whole server document, and it=A0looks like =
this:
> =A0
> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> =A0=A0 <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
> =A0=A0=A0=A0=A0 xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
> =A0=A0=A0=A0=A0 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">=

> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
> =A0=A0=A0=A0=A0 </a:list>
> =A0=A0=A0=A0=A0 <packages>
> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
> =A0=A0=A0=A0=A0 </packages>
> =A0=A0=A0 </service>
> =A0=A0 </rls-services>
> =A0
>
> Bill decides to get the service information for uri=20
> sip:marketing@example.com
> =A0
> =A0=A0 GET
> =A0=A0 /rls-services/users/bill/index/~~/rls-services/
> =A0=A0 service%5b@uri=3D%22sip:marketing@example.com%5d
> =A0=A0=A0 HTTP/1.1
> =A0
> =A0=A0 and the server responds:
> =A0
> =A0=A0 HTTP/1.1 200 OK
> =A0=A0 Etag: "ad88"
> =A0=A0 Content-Type:application/xcap-el+xml
> =A0
> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
> =A0=A0=A0=A0=A0 </a:list>
> =A0=A0=A0=A0=A0 <packages>
> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
> =A0=A0=A0=A0=A0 </packages>
> =A0=A0=A0 </service>
> =A0
> Bill is now confused as he has no idea what namespace the tags that=20
> are using the namespace prefix a: belongs to, so he has to fetch the=20=

> whole document to find out....
> =A0
> =A0
> Also as disscussed earlier:=20
> http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html=A0the=
=20
> XDM client has to always send the xmlns declaration with the XML=20
> elements that are sent in a PUT in order to be sure that it will be a=20=

> valid part of the complete XML document on the server..
> =A0
> This would be a situation where the client would have a problem if the=20=

> xmlns declaration is missing in the XML fragment body:
>
> The server document looks like this:
> =A0
> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> =A0=A0 <a:resource-lists =
xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
> =A0=A0=A0 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
> =A0=A0=A0 <a:list name=3D"close-friends">
> =A0=A0=A0=A0 <a:display-name>Close Friends</a:display-name>
> =A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com">
> =A0=A0=A0=A0=A0 <a:display-name>Joe Smith</a:display-name>
> =A0=A0=A0=A0 </a:entry>
> =A0=A0=A0 </a:list>
> =A0=A0 </a:resource-lists>
> =A0
> Bill creates an element in the resource-lists document (Section 7.4).=A0=
=20
> In particular, he creates a list with an entry:
>
> =A0=A0 PUT
> =A0=A0 /services/resource-lists/users/bill/fr.xml
> =A0=A0 /~~/resource-lists/list%5b@name=3D%22friends%22%5d HTTP/1.1
> =A0=A0 Content-Type:application/xcap-el+xml
> =A0=A0 Host: xcap.example.com
>
> =A0
> =A0=A0 <list name=3D"friends">
> =A0=A0=A0=A0 <entry uri=3D"sip:bob@example.com">
> =A0=A0=A0=A0=A0=A0 <display-name>Bob Jones</display-name>
> =A0=A0=A0=A0 </entry>
> =A0=A0 </list>
> =A0
> Bill will cry as the validation of the document after the tentatively=20=

> insertion will fail as this will produce a invalid XML document..
> =A0
> =A0
>
> /Per
> =A0
> Per Hyttfors
> ___________________________________________________________
> Development Engineer - Messaging Application Development
> Sony Ericsson Mobile Communications AB
> SE-221 88 Lund, Sweden
> +46 46 2126534
> per.hyttfors@sonyericsson.com (MSN/E-mail)
> ___________________________________________________________
>
> The information in this email, and attachment(s) thereto, is strictly=20=

> confidential and may be legally privileged. It is intended solely for=20=

> the named recipient(s), and access to this e-mail, or any=20
> attachment(s) thereto, by anyone else is unauthorized. Violations=20
> hereof may result in legal actions. Any attachment(s) to this e-mail=20=

> has been checked for viruses, but please rely on your own=20
> virus-checker and procedures. If you contact us by e-mail, we will=20
> store your name and address to facilitate communications in the matter=20=

> concerned. If you do not consent to us storing your name and address=20=

> for above stated purpose, please notify the sender promptly. Also, if=20=

> you are not the intended recipient please inform the sender by=20
> replying to this transmission, and delete the e-mail, its=20
> attachment(s), and any copies of it without, disclosing it.
> =A0_______________________________________________
> 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 18 20:05:50 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5uOM-0007vU-HZ; Thu, 18 Aug 2005 20:05:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5uOK-0007ux-Sk; Thu, 18 Aug 2005 20:05:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18034;
	Thu, 18 Aug 2005 20:05:47 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E5uyA-00057t-CP; Thu, 18 Aug 2005 20:42:51 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-1.cisco.com with ESMTP; 18 Aug 2005 17:05:39 -0700
X-IronPort-AV: i="3.96,123,1122879600"; 
	d="scan'208"; a="655543514:sNHT30980952"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7J05X0J020746;
	Thu, 18 Aug 2005 17:05:34 -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);
	Thu, 18 Aug 2005 20:05:35 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-202.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 20:05:54 -0400
Message-ID: <4305224E.1080500@cisco.com>
Date: Thu, 18 Aug 2005 20:05:34 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] tel URIs in common policy
References: <42F61879.1000207@cs.columbia.edu>
	<42F9CF66.2070604@nokia.com>	<42FA44FE.7020703@cisco.com>
	<42FCE04A.80901@nokia.com> <42FCFEFB.6040502@cisco.com>
	<4302872A.2090709@cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Aug 2005 00:05:54.0627 (UTC)
	FILETIME=[C484C930:01C5A451]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Content-Transfer-Encoding: 7bit
Cc: "'geopriv@ietf.org'" <geopriv@ietf.org>, Aki Niemi <aki.niemi@nokia.com>,
	simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Jonathan Rosenberg wrote:

>>> Well, 'sip:+1-232-555-1234@foo.com;user=phone' is indeed a tricky 
>>> identity to put into a From header in the first place. I'm not sure 
>>> it is a telephone number at all. Why wouldn't the From include a tel 
>>> URL?
>>
>> Personally, I generally think it should. However I have run into many 
>> people who don't seem to believe in tel URIs, and always use the sip 
>> form. I would like to convince them of the error in their ways, but no 
>> luck so far.
> 
> I think the problem is that we've not made it clear what the semantic 
> differences really are.

I'd like to think that is the case. But it is so pervasive I suspect 
there are multiple world views, or religions, here.

> Givne this, the meaning of sip:<phone-number>@domain;user=phone means 
> that the domain is asserting ownership of the identity in the user part, 
> in this case a global phone number. As such, its appropriate to use this 
> form only when it is authoritatively known that the domain in question 
> "owns" that phone number.

*I* could potentially agree with that, but it seems most people don't.

In general, I think all the above means is that the domain in question 
is accepting responsibility for getting the request wherever it goes. It 
might not own the phone number, in which case it may use peering or a 
pstn gateway to get to the right place.

It seems very popular for a UA to construct such a URI, with the domain 
of its service provider, to ask the service provider to get this to the 
right place.

I think that is entirely wrong, but it seems we have 80% of the world to 
convince of that.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 18 20:19:11 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5ubH-0003gO-Nx; Thu, 18 Aug 2005 20:19:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ubE-0003dT-SJ
	for simple@megatron.ietf.org; Thu, 18 Aug 2005 20:19:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18542
	for <simple@ietf.org>; Thu, 18 Aug 2005 20:19:07 -0400 (EDT)
Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5vB4-0005Tq-VV
	for simple@ietf.org; Thu, 18 Aug 2005 20:56:11 -0400
Received: from [162.83.73.96] (HELO JMHLap3.stevecrocker.com)
	by EXECDSL.COM (CommuniGate Pro SMTP 3.3)
	with ESMTP id 11927738 for simple@ietf.org;
	Thu, 18 Aug 2005 20:18:51 -0400
Message-Id: <6.2.1.2.0.20050818201134.02ce7c90@localhost>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 18 Aug 2005 20:18:13 -0400
To: Simple WG <simple@ietf.org>
From: "Joel M. Halpern" <joel@stevecrocker.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by
	using only the XML fragment body.
In-Reply-To: <3d2faf02c780d760f4f6947ff81ba868@softarmor.com>
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
	<3d2faf02c780d760f4f6947ff81ba868@softarmor.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 2.1 (++)
X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I am apparently missing something in how this all will get used.
I understand how to use XCAP without additional namespaces.
I know how to use XCAP when the usage defines a set of namespaces and 
namespace prefixes that will be used in the document.
I understand that things will be somewhat difficult when new extensions are 
added to the document definitions, but I think those work fine.

I do not imagine that users will ever define either namespaces or namespace 
prefixes.  They don't know or understand such things.  Hence it is the 
software that is providing the service that is create the namespace 
references and assigning them prefixes.   I understand that XML allows one 
to use any old prefix, reuse prefixes, and all sorts of other things.  If 
the document does that, the XCAP client will need to know those things.

Or, in other words, in very messy situations a client will need to fetch 
and analyze all sorts of information.

But why would the software have that occur with a buddy list?  Are we 
really assuming that there are multiple extensions and that different 
clients will pick different quasi-random names for these extensions?  And 
then we will actually expect another client to be able to figure out what 
is really going on?  When even human beings have trouble sorting that sort 
of context out?

I presume I am missing some good reason for this mess.  I would appreciate 
an explanation.  In the absence of clear and urgent need, I would tend to 
conclude that this can be dealt with by an extension at a later date.

Or, to put it in different terms:
lets get the simple case out, and then figure out if the corner case 
actually matters.
Particularly since it is clear that we can add extensions that will cope.

Yours,
Joel M. Halpern

At 07:36 PM 8/18/2005, Dean Willis wrote:

>I'm thinking that this message documents a relatively significant problem 
>either with XCAP or with a usage of XCAP as proposed by OMA PoC.
>
>XCAP is currently in the RFC Editor's Queue, and consequently somewhat 
>hard to change, but some changes could perhaps be made by an IESG "note to 
>the RFC editor" if needed (and approved by the IESG).
>
>I'd like to see some discussion of the severity of this problem and what 
>should be done about it -- preferability Very Soon, as OMA is meeting next 
>week.
>
>Possibilities I see:
>
>1) Fix the XCAP spec before publication.
>
>2) Obsolete the current XCAP spec and produce a new one.
>
>3) Define an extension to XCAP to fix the problem.
>
>4) Decide it's not really an XCAP problem, because OMA PoC is using the 
>protocol in a manner inconsistent with its design requirements, and help 
>OMA PoC come up with a workaround.
>
>5) Something entirely different.
>
>Thanks!
>
>--
>Dean WIllis
>as IETF liaison to OMA
>
>On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:
>
>>Hello,
>>
>>As I see it there is a major problem with retrieving elements in an XML 
>>document using XCAP. The problem has to do with that the XDM clients has 
>>to know all the namespace prefix bindings in the server document prio the 
>>fetch of an element.
>>
>>The problem is that the current XCAP specification only mandates that a 
>>XCAP fragment body is sent between server and client when performing XCAP 
>>operations. Not being an fcs document with the fragment context 
>>specification leads to problems now when the XCAP URL has been made 
>>independent of the namespaces prefixes used in the document on the server.
>>
>>The XML data returned in the 200 OK answer on a fetch of an element will 
>>contain the exact content of that element in the XML document on the 
>>server. If this element or any child elements use namespace prefixes 
>>declared earlier in the document they will not be included in the 
>>response to the client. Hence the only way to know all the prefixes is to 
>>have done a fetch of the whole document.
>>
>>Just to clarify the problem I have made these examples (inspiration from 
>>the XCAP specification..)
>>
>>Bill has not fetched the whole server document, and it looks like this:
>>
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
>>       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <service uri="sip:marketing@example.com">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:joe@example.com"/>
>>         <a:entry uri="sip:sudhir@example.com"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>    </rls-services>
>>
>>
>>Bill decides to get the service information for uri sip:marketing@example.com
>>
>>    GET
>>    /rls-services/users/bill/index/~~/rls-services/
>>    service%5b@uri=%22sip:marketing@example.com%5d
>>     HTTP/1.1
>>
>>    and the server responds:
>>
>>    HTTP/1.1 200 OK
>>    Etag: "ad88"
>>    Content-Type:application/xcap-el+xml
>>
>>     <service uri="sip:marketing@example.com">
>>       <a:list name="marketing">
>>         <a:entry uri="sip:joe@example.com"/>
>>         <a:entry uri="sip:sudhir@example.com"/>
>>       </a:list>
>>       <packages>
>>         <package>presence</package>
>>       </packages>
>>     </service>
>>
>>Bill is now confused as he has no idea what namespace the tags that are 
>>using the namespace prefix a: belongs to, so he has to fetch the whole 
>>document to find out....
>>
>>
>>Also as disscussed earlier: 
>>http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html the 
>>XDM client has to always send the xmlns declaration with the XML elements 
>>that are sent in a PUT in order to be sure that it will be a valid part 
>>of the complete XML document on the server..
>>
>>This would be a situation where the client would have a problem if the 
>>xmlns declaration is missing in the XML fragment body:
>>
>>The server document looks like this:
>>
>>    <?xml version="1.0" encoding="UTF-8"?>
>>    <a:resource-lists xmlns:a="urn:ietf:params:xml:ns:resource-lists"
>>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
>>     <a:list name="close-friends">
>>      <a:display-name>Close Friends</a:display-name>
>>      <a:entry uri="sip:joe@example.com">
>>       <a:display-name>Joe Smith</a:display-name>
>>      </a:entry>
>>     </a:list>
>>    </a:resource-lists>
>>
>>Bill creates an element in the resource-lists document (Section 7.4).  In 
>>particular, he creates a list with an entry:
>>
>>    PUT
>>    /services/resource-lists/users/bill/fr.xml
>>    /~~/resource-lists/list%5b@name=%22friends%22%5d HTTP/1.1
>>    Content-Type:application/xcap-el+xml
>>    Host: xcap.example.com
>>
>>
>>    <list name="friends">
>>      <entry uri="sip:bob@example.com">
>>        <display-name>Bob Jones</display-name>
>>      </entry>
>>    </list>
>>
>>Bill will cry as the validation of the document after the tentatively 
>>insertion will fail as this will produce a invalid XML document..
>>
>>
>>
>>/Per
>>
>>Per Hyttfors
>>___________________________________________________________
>>Development Engineer - Messaging Application Development
>>Sony Ericsson Mobile Communications AB
>>SE-221 88 Lund, Sweden
>>+46 46 2126534
>>per.hyttfors@sonyericsson.com (MSN/E-mail)
>>___________________________________________________________
>>
>>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 Aug 18 23:24:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E5xUD-0002fL-4V; Thu, 18 Aug 2005 23:24:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E5xUB-0002f8-JY
	for simple@megatron.ietf.org; Thu, 18 Aug 2005 23:24:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25566
	for <simple@ietf.org>; Thu, 18 Aug 2005 23:24:01 -0400 (EDT)
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5y3p-0001h9-4o
	for simple@ietf.org; Fri, 19 Aug 2005 00:01:08 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILG00LRM9OH7X@szxga01-in.huawei.com> for
	simple@ietf.org; Fri, 19 Aug 2005 11:29:05 +0800 (CST)
Received: from szxml02-in ([172.24.1.6])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILG00HOE9OHWC@szxga01-in.huawei.com> for
	simple@ietf.org; Fri, 19 Aug 2005 11:29:05 +0800 (CST)
Received: from w39649a ([10.76.176.178])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0ILG00JVT9QQJB@szxml02-in.huawei.com> for
	simple@ietf.org; Fri, 19 Aug 2005 11:30:26 +0800 (CST)
Date: Fri, 19 Aug 2005 11:24:08 +0800
From: Smile Wang <wangsmile@huawei.com>
Subject: [Simple] Questions regarding MSRP Relay drafts
To: "'SIMPLE'" <simple@ietf.org>
Message-id: <000001c5a46d$75fe2e70$b2b04c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.4 (/)
X-Scan-Signature: bfef20db74c24e87b6dbcd42ea7ba67c
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1439209865=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1439209865==
Content-type: multipart/related;
	boundary="Boundary_(ID_pTwptlNonRIHAi3+XDVsoQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_pTwptlNonRIHAi3+XDVsoQ)
Content-type: multipart/alternative;
	boundary="Boundary_(ID_gRPq4zoZCQ0ZvdBLLHNIZg)"


--Boundary_(ID_gRPq4zoZCQ0ZvdBLLHNIZg)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

Hi,all

I have a doubt about the draft-ietf-simple-msrp-relays-05.txt.

In section 3 the second example about a message being re-chunked

through two relays.

Alice           a.example.org(relay1)  b.example.net(relay2)         Bob

     |                     |                    |                     |

     |--- SEND 1-3 ------->|                    |                     |

     |<-- 200 OK ----------|                    |  (slow link)        |

     |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |

     |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|

     |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|

     |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|

     |                     |                    |<-- 200 OK ----------|

     |                     |                    |<-- REPORT 1-3 ------|

     |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|

     |<-- REPORT 1-3 ------|                    |                 ...>|

     |                     |                    |<-- REPORT 4-7 ----->|

     |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|

     |<-- REPORT 4-7 ------|                    |                  ..>|

     |                     |                    |<-- 200 OK ----------|

     |                     |<-- REPORT done-----|<-- REPORT done -----|

     |<-- REPORT done -----|                    |                     |

     |                     |                    |                     |

 

Why relay1 receive the part of message(1-3,4-7,8-10) not direct send to
relay2,but

re-chunked 1-5,6-10? I consider that MSRP is app layer protocol which don't
take 

into account the things that transfer layer to do.And MSRP use TCP or TSL
which

send the stream data,unlike UDP which data length exceed MTU must be split.

 

 

Smile  

 


--Boundary_(ID_gRPq4zoZCQ0ZvdBLLHNIZg)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name="Microsoft Theme 2.00" content="&#24120;&#26149;&#34276;.htm 011">

<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	background:#FFFFFD;
	font-size:12.0pt;
	font-family:SimSun;
	color:#427D64;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{color:#427D64;}
 /* Page Definitions */
 @page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

<style>
p.MsoNormal
	{margin-left:48.0pt;}
</style>
</head>

<body bgcolor="#FFFFFD" background="cid:image001.gif@01C5A4B0.83CBAD50"
lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation;
margin-left:48.0pt'>

<div class=Section1>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>Hi,all</span></font></p>

<p class=MsoNormal style='background:transparent;text-autospace:none'><font
size=3 color="#427d64" face=&#23435;&#20307;><span lang=EN-US style='font-size:
12.0pt'>I have a doubt about the draft-ietf-simple-msrp-relays-05.txt.</span></font></p>

<p class=MsoNormal style='background:transparent;text-autospace:none'><font
size=3 color="#427d64" face=&#23435;&#20307;><span lang=EN-US style='font-size:
12.0pt'>In section 3 the second example about a message being re-chunked</span></font></p>

<p class=MsoNormal style='background:transparent;text-autospace:none'><font
size=3 color="#427d64" face=&#23435;&#20307;><span lang=EN-US style='font-size:
12.0pt'>through two relays.</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
  face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>Alice</span></font><span
lang=EN-US>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.example.org(relay1)&nbsp;
b.example.net(relay2)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bob</span></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|--- SEND 1-3 -------&gt;|&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- 200 OK
----------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; (slow link)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|--- SEND 4-7 -------&gt;|--- SEND 1-5
------&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- 200 OK ----------|&lt;-- 200 OK ---------|--- SEND 1-3 -------&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|--- SEND 8-10 ------&gt;|--- SEND 6-10
-----&gt;|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
....&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- 200 OK ----------|&lt;-- 200 OK ---------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- 200 OK ----------|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT 1-3 ------|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT 1-3 -----|--- SEND 4-7 -------&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT 1-3
------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
...&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&lt;--
REPORT 4-7 -----&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT 4-7 -----|--- SEND 8-10 ------&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT 4-7
------|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
..&gt;|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- 200 OK ----------|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;|&lt;--
REPORT done-----|&lt;-- REPORT done -----|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&lt;-- REPORT done
-----|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>

<p class=MsoNormal style='margin-left:48.0pt'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</span></font></p>


<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>Why relay1 receive the part of message(1-3,4-7,8-10)
not direct send to relay2,but</span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>re-chunked 1-5,6-10? I consider that MSRP
is app layer protocol which don&#8217;t take </span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>into account the things that transfer layer
to do.And MSRP use TCP or TSL which</span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>send the stream data,unlike UDP which data
length exceed MTU must be split.</span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=3 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></p>

<div>

<p class=MsoNormal><font size=2 color="#427d64" face=&#23435;&#20307;><span
lang=EN-US style='font-size:10.0pt'>Smile</span></font><span lang=EN-US>&nbsp; </span></p>

</div>

<p class=MsoNormal style='background:transparent'><font size=3 color="#427d64"
face=&#23435;&#20307;><span lang=EN-US style='font-size:12.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_gRPq4zoZCQ0ZvdBLLHNIZg)--

--Boundary_(ID_pTwptlNonRIHAi3+XDVsoQ)
Content-id: <image001.gif@01C5A4B0.83CBAD50>
Content-type: image/gif; name=image001.gif
Content-transfer-encoding: base64
Content-disposition: attachment; filename=image001.gif
Content-Transfer-Encoding: base64

R0lGODlh/wNdAPf/AP///4SEhIyMjJSUlJycnKWlpa2trbW1tb29vcbGxs7OztbW1t7e3ufn5+/v
7/f3987GxtbOzt7W1r21ta2lpbWtrca9vZyUlKWcnMa9td7WztbOxr21rc7Gvefezt7Wxt7Wve/v
5/f37///987OxtbWzt7e1ufn3r29ta2tpbW1rcbGvZSUjJyclKWlnIyMhN7ezufn1u/v3tbWxr29
rcbGtc7OvbW1pf//562tnPf33qWllO/v1t7exufnztbWvc7Otb29pcbGrf//3vf31u/vzufnxt7e
vdbWtc7Orf//1u/vxufnvff/zvf/1u/3zufvxt7nvff/3u/31ufvztbevc7WtcbOrd7nxr3Gpff/
5+/33ufv1tbexs7WvcbOtbW9pa21nO//zt7vvdbntd7nzr3Gre//1uf3ztbnvd7vxufv3sbOvaWt
nPf/79bezs7WxrW9ra21pe//3uf31s7evcbWtd7vztbnxr3Ord7n1r3Gtef33sbWvd7v1s7extbn
zr3OtbXGrefv5+/378bOxs7Wztbe1t7n3rW9taWtpa21rb3GvYyUjJSclJylnISMhM7ezsbWxrXG
tb3OvcbOzq21tZScnMbGzq2lrcDAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAJoALAAAAAD/A10A
QAj/AGmYMUND4BcgVuxc2cMwkJk9NFAgQFCghQ0fT6BQUYMFS5cub94kIEASwYIGmlKqXMmypcuX
MGPKnEmzps2bOHPq3Mmzp8+fQIMKHUq0qNGjSJMqXcq0qdOnUKNKVUowzp44cWhgRaGoxQABYAMI
6NEDCZQoUWCs4cKjTBc4IBe5oNGlRxm4f+rAgRNpBpxDChY4eDC1sOHDiBMrXsy4sePHkCNLnky5
MlA5KGhARKGCBgEBYr1EwVKlx48jU7z48NLFRxcsM/T4wFIGBgy/Nmb8gFGmDAkXAw4oQGm5uPHj
yJMrX868ufPn0KPbHGgGjBw5i1Sk2H5ATxnTXqr8/wBZhocWPTO8eJnh9sePHh/hrN/b5UsCBIOl
69/Pv7///wAGKOCAAgbwQgCY7FEDG/IF0kcNM9jWQxUiLLhCCSSQsAJooAUQACQE6AEDFx/N0IV7
cCSQAAP5EejiizDGKOOMNNZo42Qx+OADDjx44AEMJpjAAAMw6HECCV/UEMYNYIBhxhVmCAFRIioo
UgABGKigggEUuFDAlwYskkAhCUTAAAkLEHbjmmy26eabcMYpZ2VTOEHFFDwUceIRpVUBRRV1ePFH
aV3M8EUcTtbwBSM1oOAoCgeg8IUQVwiR5ENm1KCgAg+oOeenoIYq6qikllqjiD3wBoNdM7AxA3sx
xP9QYkh7laAAko5qWsMKbKywhyAoMIICAV8NQNIBCAw3WKemNuvss9BGK+20RcH2BRWj+TVDHyEV
kkIOZnzhhbgM9WpGIo8yMmVWKiRCwCVgJsuAp9TWa++9+OarL5twwIAFWVV0UQcbLuzgQg5MslFC
CSbEICIMJXhhw2444DDHEE44MQUVHPtwh3d6rKGHCQ0Qt+/JKKes8sosJ1aAlSkkUogJM5BAQxhx
uEBsIwas4N6/VJTRURVOSEEFGlPcAcgfMOAByBtdlAGIW288fYiQiNDb8tZcd+311y0TkAICAJgQ
RpJJ1lBDhnr8UIIBBHg1QAF74GFEFUVA0UUVVeD/UaghZBYwwOAEfFkCHCWUAXVIJWgN9uOQRy75
5DYKYoYdA+Ux0B5CeGHHVXFomYgLixzASJB2lcFFRz/4JUEij8hhRm4wFDqDCS1SrvvuvPfue3NV
gVGQlma40KEAA0x4xA91qJEGFGf9O4Wsb/haA1w9eARXJCG9lWEhCiBgrAEJnOT47+inr/767O8k
Rw4uPJKCClelQGwLH6m3txFWeEEFD1ywjV9i4C+AvccvcIGDJBjxCAM04Hzti6AEJ0hB9mVKCANh
AxCS8AWGfMEG3+kCHjxSBSqQpVAksAFcbMAF77AmVR+BQUhIcB8HVPCGOMyhDsHGIQscAF4pMAAC
/xhhKCDIEAby8QsCUsCCFrDAESwYXCPAQkUBEGAFNHuDbeBQCAsIBoI7DKMYx0hGOXXkCdgCGhX4
9hG+1S5IXajUF7IwEAyaISsoWAENhAAEzqnNUSswX6cckLsyGvKQiExkgMRDhSIUwQh1mQEexgOf
LnxgBn+Awx9YUwJDfMEOXxjIFfpghzyAUlFf2OShQreI+c0vEchKVgMKqcha2vKWuGRMXbLHt4Dp
pmY2YEQFqOgIF7SBSQLZw0MiwoYvCAIrcWjUHlQApgMk4AS0zKU2t8nNbirFD1zAwxv00AUghWQF
o5PDDaxghS984Qqh3EMiSGC6A1hCiGdaAQr2EP++Axjgn8gaDrO8SdCCGvSgNfGSAdgwzpqxYQAu
kIMNCACcFHwhkl74gQ8C9gMcnEEKU9jCHbBABzrcgQ5U8IFGylCHGcwzTQiNqUxnys0CbMcAKagA
ChBXAkWogAN5hMMbhNYRKnjkB2UoIRpGAwWP0KYOAesCa0zEBUBMrXvgmxdNt8rVrt6QBnQUSJSS
1K9LKeghjtJOAeCABY00FT548MEM3kACYxHAml/0ql73ytcICsKdX2gmG9QT2A4yBAU1SMQeUJCI
FUCgBFPwwQ+40ANazcBWBnBBChiBoVkOtK+gDa1owSYIOuaBBpZTZiLk8IgWtIAAHhJLARLgIx3/
VKEMGPFBql4FhxTMJRAqRGBIJIGIB4JxtMhNrnJNJbys0CAIBYkDCtrQAg8J4BFA4NN7mNARI/SA
DlzgwhuE6q0atC6jvNWWfAzBXgjcBwEMeOBy50vf+rYpK2YIQlb2ayCw2IAMfAtPFZZQBSz4gA49
8AIB9VADMwjKL1Z9QwtrI9XwAdSaCVBAfLNp3w57+MP6cYELblCQKX3mBQIwQhT49gMrPGEGNlij
D47Qg9hwAbcU/kgI1WMDwuUVxEAOspClQxA5KCIFbXDUy7bDHthITDx22cIUZEgCOACCsv+qwqtM
VCiQsGEiHB6ymMdM5sdY6p0D0QoNtEQDt1RB/z1DM7BRocCGH0gMPlgABBu6AIUY3AFqQv0yfo5b
5kIb+tBLIbEZgLCCGgAhXIP9AhxExBqPRA2Jb5jBBlYglgOUkwtCvQMcTACxINmghoRGtKpXzWqd
WJciyHuEChjBCInZYM8nklgKSYACDoXF1wNQgYmqpsW90PAkrU62spdNEwxcaQEmOEABMnGAcb3z
CmmY2cJKsAckywFRYBAEB+LQSmIZ60skKYABbKAHPZBgBvKyIbPnTe9WP6GEVOgCFXRTmjLEykha
nIEQxJoFStVAMwdQwSL++QMbQAQMN0AWhhWgAEwkwBAa/my9N85xIWtECUNoAhurcAeOfSR7vf95
VSECC4S0EaQqujIDEoAghIIPfLEokG/Hd85zIHvkTj6wjaU/kOAZJBgOfikB0+BAgj6YwQpmsNyu
9oCACdSgD55zp68YIt3FMkLDs+y52McuWo1y4Q5luINU1VM1cgo1EnAJyWXlw5AVrIARvMJ7HRvM
WIXj9J/qPoA1A2Ncshv+8DP9s9TKwKcud+EPIXGLekhQCEaMqRIkUIAh2KApNjDk8wpaLCwDfxJ5
I/70qI8pwOCTnkjOwBCUWAELGjGAFqRAeJr6vCCSyRAaJCkOES/clwIa5tQb//i2xAJc8KCHqs3n
VSmQnR0896Cz3tFRCEhEArJSAzwe4ALCF2L/xpFP/vLbUnUnF1EJFpCAR+wgB3IQ3uxMAO2FIf2S
PcgYxpxAhClsrDwt9AbsF2/mV4AGGEYDYAA/4AclADElUAiP4AJhYAYKE15Cs0ZaxhpSZSdPMAUd
2IEbgwYlhwVosAIGUADmc4AquIIS9CWLsAIkkGlM1wIjpjMCcCAFwBtRo1sbVQVS8AQdKIJeQIL/
Qhsg8RHjVAKH4Fks2IROuDteogg4lQIoYAgLwFgpkB0qgAAMo29thQXvwRocgwVjGBISlj35g4Th
1W4mABgs8oRwGIdc8yWZsAIgsBpIYAOaYnclEAE+4F1ogAQ1RhpHwCcm5zfjZWwL4xchAQNL/9MH
egEIIGEI2JRqcniJmNgsVmADV6ApdWQFlZIFJAADOLclKVAAj1AANeADbjEHWJAGXcAGmwQX3mJX
BWAJE7EA8fUAItCLg5SJwBiM0bIH1edO0+cFfeBObKAZXCd6CZAIXrAFFzgbvIUhJ2gAKLBhliiM
3NiNoeJ7fRAIg/UgeaAeTsd1WKECB5csvSE0d3AHeIBAJkACp/iC41UCs2R63riP/AgqvvcFDmFH
HUQl2bEIcfMZtncCJ6ADWOBdZ8AF+RYShpBZ0WQHJWIiSjgI+tiPHNmRNTIQcWAGWQBNBOECjkAA
jjAAYhEAB/ADVXBv+cYD/pdvhaIHqwUG4v+iZXBQB5u0HoZgA0NiMh45lEQZIDQABnEgCBAROhmA
AinQAh3iISpwBCtmBIXoB2UAXgTEGm8QBzmwB3BRO2mAdLXjFyRQAhBQCbqoc0XZlm7pHOkYXdGl
Ap+xknvDN1bQVGPQVFTABVsgXkiEAnGQG5bGF+P1B2+hSYWwmAnwTxpWfG8ZmZLZGGqGlFlwAyoQ
B8ejCFbQS0eQBkRwBG1FBTDgBWsAJIwCIW8BCH7QfLUBAy1FeSNROP8kL4U3mbiZm4vRGQeHR3Fg
AB2SAj2wYkhQBUBgBKShb1NQY28QJFVgA+rhBXUAEjPgA33pPTglHLoYX561jbr5neBpFKT/YxVa
gRWwBRZVQGMuOYRU4AVl4AUAgwUmsAZBwxu9oWPxYQMHYEUr4p3h+Z8AWhSK0AaalQiJUBDAiTxY
sGLrUWDPyTEpVQav8prZkx4mgkA2sAIHQAAO5J8B+qEgyhPWkQME4FPZpwiPQBIf8RF2hgUZ5QM8
4BqHA0Kz0QWAMCGF8gNwUQIzwAgFcABsGaJCOqRAASVemQNtEAcHcIpaMlelmVExVB5bEBIM8gau
gaN+wRqZFGgJcAAbSaRgGqY2oR4HB5KCGTpxsCoJZgOrR4ZBYwNdAJ0BQxZwITRl8AcwJpv4IaZ8
2qcyIRBCwE4NRhARQQM2QGo/QxZYoAZU/3BJ5pVCrVEb+qM4taEHh0BDe+qnmrqpmnBmD1ED8GQH
irIHo+hmM1YFRiChh8MgkcIG7Rgh9qmEh7AAGpIAX8qpuCqkA3BkGmJeNjApA1FZSSU0KyAxhrAX
hZAIKskhB0ACXMAHMaAbLFoFKYIAYZer2CqkHUIRikADDBIIimIDJfAGWAAEbsBjulYAK8khYsEG
JFAGa4RUWCCAG1A+QZqt+AqeK4kAmWBF6pYAdmcFQAA1t5FENLQIVYRiVSQWKsAgXDCuSJehlaBV
+Vqxukk4GlAClvAlKnBrBwEEl6UHx1ozBNoG8YcdcpACVvIIg2NXhYMChZA4GFIIJgGZFv97s/0Y
S/SXeYWwAoYiBIFqBaNGV4wAf0sSkgMnmAv3FbR5JSRBAAhQCM1pCCRgEkKJs1jbkUtgBEYQo2X5
BogQKwrZADPwcGAQBFlAA5UiEGu2JQXgAiqAAhkABr71TwaALAlgAV9nAlZ4q1n7t8I4nBmRPSnl
ogHzLz3gMOjxA1dQKQwRJXiEAhxwAO1UppkBKSuSjyVTMh4KuJ6rgnsJhFHAJ1HAAyR0oVpUAmvA
ozVgB0IAXVFCEIsFEZ+qKNLkKBSrCZ37ubxbgGrwBBnzBKTRS3hgVL1UYJeFJFcArgvyR4+yT51j
KZmSZo2yAlfbu9grhzfWSGMIG5U0V+3/cVlewKPc5itfIFY4NwH71E6GZVgRARGBxITZO79N+B1l
MAXfMa+Ztirp8QaQ9wc6+gYL8wZeUI4PsQcdZHeMYAGB0kziiFpnylgSUQiCRL8WXIAm0jH7ViJw
waJS1S+F8ge24gULwgZ5xAZ6CEqBkAcfixWLcAPboQiKgC4TkXnye8E4nHowQEA7rCpJVE5loAd7
ATUfUQjHagihtwe0tja0hgKeFwctSzg/miwnkY8al8NYbHj5pqgrKlUwZlS9gUSJuRfHSgKToMR7
UAhs4HmgByk6c24ZxiK7m8V0zGymUYQlkqMTMx6LgiwroMbvZgg1EwjlYgaZIV0FkUfS/6Zu8HWv
dfzIZHci32siXiBUXmB3XyEALBBRWKFYg8qMDAEsJaYCKRovmGCzkJzK9VYGeMAaMICneFrJXQBL
tRdRz0QDffCrDJF7+6QriXADMDw3w1c+fqvKxlxvT2oXfvAWeHoiJKBO7zQufaBMipKUNIAAKGAB
NHBwmaECBzAAF/AlFCAvc3zM5kxmWnSfUdN8bwA4BwMGntNyVyCqBEEljJAIFYCLJhAHjJCZFKFu
tUnM5XzOBA1kPIAeb5CxJiDAlGdMwMxOQFAp4NorClAIEsyFDRACbSgkJmArCBBLmTvQBT3S9aVv
7xkwW/SUIqZOA3E7J5BFJVBj7zEEOP+QMWIgBmhkVHggNXrwNLYSXyQd1KrmAgwiiT69AjSYAlnB
bjJwY6vDouPxA2iUMVTNf0eDBnSgEUFDArso1F5daIVTCOiBRDMYUV8AAzLAilhAYzNQB3YmHl4w
BGhwBnfwBGhw12iwEVAwQncwLATQn18d2GKmbiqgAA0YMWxAgzcgB58BFgZwQj9QhHa2f3QwBVzw
B/CKY1jgN1MDErZSzIId2soFJgZgAUJFedF3A8TCAqCBAnszIVSgYnwCvEiTNG4hNH3Tjj7dnPQH
1KL92/PlJTe1AoeAIQShCPFDABTAWYWCqlAASeLhBGj0BO94F4DgiP6rY+oMAycwq4T+BNzgPVpf
sh0quwKGTY8GkJlx8G61MRsmpF0vaVSLqgYjpDgyxMGYTQdl4AeA0IZWeL3hHeBbZVPeDCEXqiGe
pzA9UAQdAQV/SBqVxDF4MOGFcmsfDBJ/IImJOANPEwllYIVXLOAijlCFY1H/Mim70igokEImFAVI
MAOOsAJH4AUjVEJrrWVlAHdsgHELsAIqwi0fTB+pAgOHANojfuTb5ChxQAhmsAgDYbukinSQcoIp
Wjg1cJdo0BHhMYtcZAAtW+LkExgOsAaHEBKIgORoflBPMnCUsmju5AWGgAID90eM4E9v2wFadAer
0xHx0QWFADeFgywbNgJpXugzFRAAOw==

--Boundary_(ID_pTwptlNonRIHAi3+XDVsoQ)--


--===============1439209865==
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

--===============1439209865==--




From simple-bounces@ietf.org Fri Aug 19 02:52:51 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E60kF-0003mD-B1; Fri, 19 Aug 2005 02:52:51 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E60kD-0003m8-9k
	for simple@megatron.ietf.org; Fri, 19 Aug 2005 02:52:49 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16761
	for <simple@ietf.org>; Fri, 19 Aug 2005 02:52:47 -0400 (EDT)
Received: from mgw-x3.nokia.com ([131.228.20.26])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E61K6-0006oB-6L
	for simple@ietf.org; Fri, 19 Aug 2005 03:29:55 -0400
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
	j7J6qjG02326; Fri, 19 Aug 2005 09:52:45 +0300 (EET DST)
X-Scanned: Fri, 19 Aug 2005 09:51:57 +0300 Nokia Message Protector V1.3.35
	2005042208 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j7J6pvqL026590;
	Fri, 19 Aug 2005 09:51:57 +0300
Received: from mgw-int2.ntc.nokia.com (172.21.143.97)
	by esdks001.ntc.nokia.com 00cxT8Yx; Fri, 19 Aug 2005 09:51:55 EEST
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j7J6ptO18147; Fri, 19 Aug 2005 09:51:55 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 5C54E93B6A; Fri, 19 Aug 2005 09:51:55 +0300 (EEST)
Message-ID: <4305818B.4020009@nokia.com>
Date: Fri, 19 Aug 2005 09:51:55 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: ext Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net>
	<3d2faf02c780d760f4f6947ff81ba868@softarmor.com>
In-Reply-To: <3d2faf02c780d760f4f6947ff81ba868@softarmor.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: Kelvin Porter <kelvin_r_porter@yahoo.com>, Simple WG <simple@ietf.org>,
	"Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Dean Willis wrote:

>
> I'm thinking that this message documents a relatively significant 
> problem either with XCAP or with a usage of XCAP as proposed by OMA PoC.
>
> XCAP is currently in the RFC Editor's Queue, and consequently somewhat 
> hard to change, but some changes could perhaps be made by an IESG 
> "note to the RFC editor" if needed (and approved by the IESG).
>
> I'd like to see some discussion of the severity of this problem and 
> what should be done about it -- preferability Very Soon, as OMA is 
> meeting next week.
>
> Possibilities I see:
>
> 1) Fix the XCAP spec before publication.

I would prefer this path (and also fix some nits regarding whitespace 
nodes,  ambiguity with positional constraints and some typos)

>
> 2) Obsolete the current XCAP spec and produce a new one.
>
I'll hope this can be avoided.

> 3) Define an extension to XCAP to fix the problem.

A simple extension to the base XCAP spec can solve this e.g. 
<http://www.ietf.org/mail-archive/web/simple/current/msg05710.html>. 
Certainly there could be some other needs e.g. search with XQuery, but 
this problem is imo fairly easily solved. We had some similar dispute 
when there was the last minute change of the r-uri regarding namespaces. 
Then it was decided that elements in the body use the same prefixes than 
the patched document.

Another case is that if it is not necessary for the client to use 
exactly the same prefixes, only the namespace uris have to match (within 
the body). This model is used in xml-patch-ops because it makes the 
implementation easier for the client.

> 4) Decide it's not really an XCAP problem, because OMA PoC is using 
> the protocol in a manner inconsistent with its design requirements, 
> and help OMA PoC come up with a workaround.
>
This is in principle true. However, I'll admit that beside this case, 
the patching model is somewhat challenging to implement.

> 5) Something entirely different.
>
> Thanks!
>
> -- 
> Dean WIllis
> as IETF liaison to OMA
>
> On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:

br,
Jari


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 19 05:04:56 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E62o4-0002Yc-8v; Fri, 19 Aug 2005 05:04:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E62o0-0002YR-F5
	for simple@megatron.ietf.org; Fri, 19 Aug 2005 05:04:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21385
	for <simple@ietf.org>; Fri, 19 Aug 2005 05:04:49 -0400 (EDT)
Received: from rat01038.dc-ratingen.de ([195.233.129.143])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E63Nq-0001y7-9f
	for simple@ietf.org; Fri, 19 Aug 2005 05:41:59 -0400
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26])
	by rat01038.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7J94PNA015858
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 19 Aug 2005 11:04:26 +0200 (MEST)
Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115])
	by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7J94I7I013251; Fri, 19 Aug 2005 11:04:24 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	gpsmxr04.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 19 Aug 2005 11:04:20 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] XCAP and its problem with Namespaces caused by usingonly
	the XML fragment body.
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Date: Fri, 19 Aug 2005 10:04:11 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02A41377@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: [Simple] XCAP and its problem with Namespaces caused by
	usingonly the XML fragment body.
Thread-Index: AcWkTcy2sIP9XZ1QQtKOXrhuKsLe+wATudGQ
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: "Dean Willis" <dean.willis@softarmor.com>, "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 19 Aug 2005 09:04:20.0966 (UTC)
	FILETIME=[FC98E860:01C5A49C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1
Content-Transfer-Encoding: quoted-printable
Cc: Kelvin Porter <kelvin_r_porter@yahoo.com>, "Hyttfors,
	Per" <Per.Hyttfors@sonyericsson.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

>From my point of view I don't think things are as dramatic for the usage =
of XCAP for PoC .=20

OMA uses XCAP to manipulate different types of documents:
- Presence Lists (using only the IETF namespace)
- Presence Authorisation rules (using the IETF namespace+OMA extensions =
due to the fact that there is a number of OMA defined presence elements)
- PoC conference policy documents (using OMA namespaces only)
- PoC user access documents (using OMA namespaces only)
- PoC directory (using namespaces only)

An OMA compliant PoC client needs to support all these namespaces (OMA =
and IETF defined). Therefore is a number of different approaches that =
could be used as workarounds for PoC:
=20
A) Wrap all the namespaces per application usage in one single OMA =
defined namespace=20
B) Standardise the prefixes (I think there is a small change that is =
necessary for this to work)
C) Create a document (similar to xcap-caps) per each XCAP server to =
fetch the namespace/prefix bindings

I understand that all these are not flexible enough and do not make XCAP =
a "generic" XML manipulation protocol that can handle any kind of =
namespaces, without the client's prior knowledge (but I don't think this =
was the initial requirement, as I understand it).

My vote therefore would be: stick with what we have right now (maybe =
there are couple of small changes that need to be done particularly in =
section 6.4 and some similar changes in the OMA specs to make some of =
the workarounds to be possible) and do the extensions in a separate =
track.

Best regards,
Haris

Haris Zisimopoulos
Group Research & Development - UK
Vodafone Group Services Ltd
E-mail: haris.zisimopoulos@vodafone.com=20

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf =
Of Dean Willis
Sent: 19 August 2005 00:36
To: Simple WG
Cc: Kelvin Porter; Hyttfors,Per
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by =
usingonly the XML fragment body.


I'm thinking that this message documents a relatively significant =
problem either with XCAP or with a usage of XCAP as proposed by OMA PoC.

XCAP is currently in the RFC Editor's Queue, and consequently somewhat =
hard to change, but some changes could perhaps be made by an IESG "note =
to the RFC editor" if needed (and approved by the IESG).

I'd like to see some discussion of the severity of this problem and what =
should be done about it -- preferability Very Soon, as OMA is meeting =
next week.

Possibilities I see:

1) Fix the XCAP spec before publication.

2) Obsolete the current XCAP spec and produce a new one.

3) Define an extension to XCAP to fix the problem.

4) Decide it's not really an XCAP problem, because OMA PoC is using the =
protocol in a manner inconsistent with its design requirements, and help =
OMA PoC come up with a workaround.

5) Something entirely different.

Thanks!

--
Dean WIllis
as IETF liaison to OMA

On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:

> Hello,
> =A0
> As I see it there is a major problem with retrieving elements in an=20
> XML document using XCAP. The problem has to do with that the XDM=20
> clients has to know all the namespace prefix bindings in the server=20
> document prio the fetch of an element.
> =A0
> The problem is that the current XCAP specification only mandates that=20
> a XCAP fragment body is sent between server and client when performing =

> XCAP operations. Not being an fcs document with the fragment context=20
> specification leads to problems now when the XCAP URL has been made=20
> independent of the namespaces prefixes used in the document on the=20
> server.
> =A0
> The XML data returned in the 200 OK answer on a fetch of an element=20
> will contain the exact content of that element in the XML document on=20
> the server. If this element or any child elements use namespace=20
> prefixes declared earlier in the document they will not be included in =

> the response to the client. Hence the only way to know all the=20
> prefixes is to have done a fetch of the whole document.
>
> Just to clarify the problem I have made these examples (inspiration=20
> from the XCAP specification..)
> =A0
> Bill has not fetched the whole server document, and it=A0looks like =
this:
> =A0
> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> =A0=A0 <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
> =A0=A0=A0=A0=A0 xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
> =A0=A0=A0=A0=A0 =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
> =A0=A0=A0=A0=A0 </a:list>
> =A0=A0=A0=A0=A0 <packages>
> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
> =A0=A0=A0=A0=A0 </packages>
> =A0=A0=A0 </service>
> =A0=A0 </rls-services>
> =A0
>
> Bill decides to get the service information for uri=20
> sip:marketing@example.com
> =A0
> =A0=A0 GET
> =A0=A0 /rls-services/users/bill/index/~~/rls-services/
> =A0=A0 service%5b@uri=3D%22sip:marketing@example.com%5d
> =A0=A0=A0 HTTP/1.1
> =A0
> =A0=A0 and the server responds:
> =A0
> =A0=A0 HTTP/1.1 200 OK
> =A0=A0 Etag: "ad88"
> =A0=A0 Content-Type:application/xcap-el+xml
> =A0
> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
> =A0=A0=A0=A0=A0 </a:list>
> =A0=A0=A0=A0=A0 <packages>
> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
> =A0=A0=A0=A0=A0 </packages>
> =A0=A0=A0 </service>
> =A0
> Bill is now confused as he has no idea what namespace the tags that=20
> are using the namespace prefix a: belongs to, so he has to fetch the=20
> whole document to find out....
> =A0
> =A0
> Also as disscussed earlier:=20
> =
http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html=A0the =

> XDM client has to always send the xmlns declaration with the XML=20
> elements that are sent in a PUT in order to be sure that it will be a=20
> valid part of the complete XML document on the server..
> =A0
> This would be a situation where the client would have a problem if the =

> xmlns declaration is missing in the XML fragment body:
>
> The server document looks like this:
> =A0
> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
> =A0=A0 <a:resource-lists =
xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
> =A0=A0=A0 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
> =A0=A0=A0 <a:list name=3D"close-friends">
> =A0=A0=A0=A0 <a:display-name>Close Friends</a:display-name>
> =A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com">
> =A0=A0=A0=A0=A0 <a:display-name>Joe Smith</a:display-name>
> =A0=A0=A0=A0 </a:entry>
> =A0=A0=A0 </a:list>
> =A0=A0 </a:resource-lists>
> =A0
> Bill creates an element in the resource-lists document (Section 7.4).=20
> In particular, he creates a list with an entry:
>
> =A0=A0 PUT
> =A0=A0 /services/resource-lists/users/bill/fr.xml
> =A0=A0 /~~/resource-lists/list%5b@name=3D%22friends%22%5d HTTP/1.1
> =A0=A0 Content-Type:application/xcap-el+xml
> =A0=A0 Host: xcap.example.com
>
> =A0
> =A0=A0 <list name=3D"friends">
> =A0=A0=A0=A0 <entry uri=3D"sip:bob@example.com">
> =A0=A0=A0=A0=A0=A0 <display-name>Bob Jones</display-name>
> =A0=A0=A0=A0 </entry>
> =A0=A0 </list>
> =A0
> Bill will cry as the validation of the document after the tentatively=20
> insertion will fail as this will produce a invalid XML document..
> =A0
> =A0
>
> /Per
> =A0
> Per Hyttfors
> ___________________________________________________________
> Development Engineer - Messaging Application Development Sony Ericsson =

> Mobile Communications AB
> SE-221 88 Lund, Sweden
> +46 46 2126534
> per.hyttfors@sonyericsson.com (MSN/E-mail)=20
> ___________________________________________________________
>
> The information in this email, and attachment(s) thereto, is strictly=20
> confidential and may be legally privileged. It is intended solely for=20
> the named recipient(s), and access to this e-mail, or any
> attachment(s) thereto, by anyone else is unauthorized. Violations=20
> hereof may result in legal actions. Any attachment(s) to this e-mail=20
> has been checked for viruses, but please rely on your own=20
> virus-checker and procedures. If you contact us by e-mail, we will=20
> store your name and address to facilitate communications in the matter =

> concerned. If you do not consent to us storing your name and address=20
> for above stated purpose, please notify the sender promptly. Also, if=20
> you are not the intended recipient please inform the sender by=20
> replying to this transmission, and delete the e-mail, its=20
> attachment(s), and any copies of it without, disclosing it.
> =A0_______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 19 09:03:58 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E66XO-0007Je-EH; Fri, 19 Aug 2005 09:03:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E66XK-0007IE-8q
	for simple@megatron.ietf.org; Fri, 19 Aug 2005 09:03:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01599
	for <simple@ietf.org>; Fri, 19 Aug 2005 09:03:52 -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.43)
	id 1E677F-00009x-HF
	for simple@ietf.org; Fri, 19 Aug 2005 09:41:03 -0400
Received: from sj-core-1.cisco.com (171.71.177.237)
	by sj-iport-3.cisco.com with ESMTP; 19 Aug 2005 06:03:42 -0700
X-IronPort-AV: i="3.96,124,1122879600"; 
	d="scan'208"; a="333805350:sNHT34029500"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7JD3b0J027976;
	Fri, 19 Aug 2005 06:03:38 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Fri, 19 Aug 2005 09:03:38 -0400
Received: from cisco.com ([161.44.79.143]) by xfe-rtp-201.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 19 Aug 2005 09:03:37 -0400
Message-ID: <4305D8A9.30003@cisco.com>
Date: Fri, 19 Aug 2005 09:03:37 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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: Smile Wang <wangsmile@huawei.com>
Subject: Re: [Simple] Questions regarding MSRP Relay drafts
References: <000001c5a46d$75fe2e70$b2b04c0a@china.huawei.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
X-OriginalArrivalTime: 19 Aug 2005 13:03:37.0570 (UTC)
	FILETIME=[69CCD420:01C5A4BE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA01599
Cc: 'SIMPLE' <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Smile Wang wrote:
> Hi,all
>=20
> I have a doubt about the draft-ietf-simple-msrp-relays-05.txt.
>=20
> In section 3 the second example about a message being re-chunked
>=20
> through two relays.
>=20
> Alice           a.example.org(relay1)  b.example.net(relay2)         Bo=
b
>=20
>      |                     |                    |                     |
>=20
>      |--- SEND 1-3 ------->|                    |                     |
>=20
>      |<-- 200 OK ----------|                    |  (slow link)        |
>=20
>      |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |
>=20
>      |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
>=20
>      |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
>=20
>      |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
>=20
>      |                     |                    |<-- 200 OK ----------|
>=20
>      |                     |                    |<-- REPORT 1-3 ------|
>=20
>      |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
>=20
>      |<-- REPORT 1-3 ------|                    |                 ...>|
>=20
>      |                     |                    |<-- REPORT 4-7 ----->|
>=20
>      |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
>=20
>      |<-- REPORT 4-7 ------|                    |                  ..>|
>=20
>      |                     |                    |<-- 200 OK ----------|
>=20
>      |                     |<-- REPORT done-----|<-- REPORT done -----|
>=20
>      |<-- REPORT done -----|                    |                     |
>=20
>      |                     |                    |                     |
>=20
> =20
>=20
> Why relay1 receive the part of message(1-3,4-7,8-10) not direct send to=
=20
> relay2,but re-chunked 1-5,6-10?

There is no requirement that this rechunking be done. Relay1 could, if=20
it wished, do as you suggest.

I suppose if the outbound link is congested, so that the relay receives=20
multiple chunks that it has not been able to send, it might as well=20
combine them.

> I consider that MSRP is app layer protocol which=20
> don=92t take
>=20
> into account the things that transfer layer to do.And MSRP use TCP or=20
> TSL which
>=20
> send the stream data,unlike UDP which data length exceed MTU must be sp=
lit.

Its a little more complicated than that. Several MSRP sessions may be=20
multiplexed over the same link. In that case, it may become necessary to=20
break a large message into chunks so that other messages (or parts of=20
them) may be interleaved.

	Paul

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 19 10:39:26 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E681m-00062R-SJ; Fri, 19 Aug 2005 10:39:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E681l-00062M-Cn
	for simple@megatron.ietf.org; Fri, 19 Aug 2005 10:39:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07066
	for <simple@ietf.org>; Fri, 19 Aug 2005 10:39:22 -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.43) id 1E68bf-0002sI-PU
	for simple@ietf.org; Fri, 19 Aug 2005 11:16:32 -0400
Received: from [172.17.2.252] (dsl001-129-069.dfw1.dsl.speakeasy.net
	[72.1.129.69]) (authenticated bits=0)
	by nostrum.com (8.12.11/8.12.11) with ESMTP id j7JEdApp073126
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Fri, 19 Aug 2005 09:39:12 -0500 (CDT)
	(envelope-from rjsparks@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <847a22a5960a3e95f8b37275879f7d85@nostrum.com>
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 19 Aug 2005 09:39:09 -0500
To: Simple WG <simple@ietf.org>
X-Mailer: Apple Mail (2.622)
Received-SPF: pass (nostrum.com: 72.1.129.69 is authenticated by a trusted
	mechanism)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070
Content-Transfer-Encoding: 7bit
Subject: [Simple] Fwd: SIMPLE notes
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I just noticed that this didn't get forwarded to the list while we were
at IETF. Apologies. These raw notes will be massaged into minutes
this weekend.

RjS

Begin forwarded message:

> From: Dean Willis <dean.willis@softarmor.com>
> Date: August 4, 2005 9:35:03 AM CDTSubject: SIMPLE notes
>
> SIMPLE Notes
> IETF 63
> reported by Dean Willis
>
> Topic: RPID
> Jonathan Rosenberg
> Slides presented
>
> Note: the schema needs to be updated to match what's in the SIP 
> Foundry repository.
>
> Issue 1:
> Verified/Unverified. Solution accepted as proposed. The impact of 
> GI/GO should be noted in the text, at a SHOULD rather than MUST level.
>
> Suggested text add: When you create an originally new document, it 
> must be valid. Rohan promised to send appropriate text.
>
> Issue 2:
> Aliasing. Solution accepted as proposed.
>
> Issue 2; Schema.
>  fromUntil vs sinceUntilProposal to adjust RPID schema accepted.
>
> Issue 3: Schema.  deviceID:
> Proposed to define only as a global element. Proposal accepted. Note 
> that this will change the schema in RPID.
>
> Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
> encapsulation out of data model spec. Argued that this makes for a lot 
> of documents to read in order to get an implementation. General 
> consensus on proposal.
>
>
> Topic: Presence Processing Model
> Slides presented
>
> Changes since last rev reviewed
>
> Proposed that further work here be deferred until more critical 
> documents are done and more experience gained. There was general 
> consensus on this approach.
>
>
> Topic: Presence Authorization
> Jonathan Rosenberg
> Slides presented
>
> Changes since last rev reviewed.
>
> Issue; Sphere determination.
>
> To Do: Make the hook for sphere composition more explicit.
>
>
> Topic: XCAP Diff
> Jonathan Rosenberg
> Slides presented
>
> Changes since last rev presented
>
> No known open issues except disconnection with partial publication 
> (different patch format).  many documents blocked on this.
>
> Proposed that we have review and WGLC.
>
> Noted that the impact of different patch implementation might not have 
> a dramatic impact.
>
> Suggested that we use a multipart MIME approach to  Basically, we 
> would put the metadata in an initial text data. This would prevent the 
> CDATA escaping need to handle embedded markup in the current format.
>
> Proposed: Punt and say that the xml-diff format indicates only that 
> the document has changed (notification of change by reference rather 
> than by value).
>
> AD comment: Not worthing doing this just to advise people a document 
> has changed. But the CDATA problem probably bears closer examination. 
> And this task DOES need completion, even if only a piece is split off 
> to meet the near-term requirements.
>
> Next steps; Talk to the XML folks about solving the problem, and if 
> necessary, fall back to change-by-reference.
>
>
> Topic: Partial PIDF format 04
> Jarri
> Slides Presented
>
> Noted by chair that scope of this draft seems to have expanded since 
> last rev, possibly in disagreement with consensus of last meeting.  
> This may require some examination. The authors are cautioned to inform 
> the WG if they see a future need for this sort of scope change.
>
> Noted that this approach has been implemented and seems to work.
>
> Comment: One implementor believes that this spec will be much more 
> difficult to implement than core XCAP was.
>
> Proposed: People should look a drafts using this function and see if 
> this draft has enabled a better solution, then decide.
>
> Noted that the developer of partial notify and related material has 
> found this approach very useful.
>
> Poll: How many people are actively following: Few
>
> How many are actively implementing? Even less. . .
>
> Open question: Can we produce a general XML patch mechanism? AD 
> comment: Very concerned that this may not meet the XCAP design goals. 
> If it does, then it's OK if it's also generally usable. But we have no 
> need to prove that it is a general mechanism in order to proceed.
>
> Chair comment: We can present this as specific to partial 
> notification, even if the algorithms are more useful.
>
> Proposed that we have a con-call with the XML directorate to review 
> this. The ADs will assist with scheduling and selecting the right 
> people.
>
> Proposed by Chair: This seems to be a reasonable way to move forward 
> if it works, and after review with the XML people the WG will be 
> informed.
>
>
> Topic: Common Policy
> Henning Schulzrinne
> Slides presented
>
> Current solution reviewed.
>
>
> Issue: Authenticated vs Asserted
>
> The current draft has some discussion without use cases.  Suggested 
> that this text be deleted and a richer discussion elsewhere be 
> referenced. Debate followed with no clear conclusion.
>
>
> Issue: Processing Logic
>
> Question: Allow OR conditions within various  sections? Currently 
> defined only for <identity>.
>
> Question; Allow >=1 (groups) .
>
> Discussion followed.
>
> Question: Can this accept everybody BUT a specific individual? Yes, it 
> could.
>
> Seems to be general consensus to accept proposal.
>
>
> Issue: Tel URIs;
>
> Proposal to only allow domain identifiers in <many /> clauses., and 
> non-domain identifiers in <one/> clauses.
>
> Discussion followed.
>
> Noted that tel: is not the only class of non-domain identifiers.
>
> Noted that this proposal prevents exclusions on ranges of numbers
>
> Suggested that exclude clauses be restricted to members of the 
> surrounding group element.
>
> Suggested that each rule element apply to a single URI scheme type, 
> like sip: or xmpp:.
>
> Chair comment: How long do we think it would take to navigate our way 
> through this? Would it be reasonable to plan for EGLCZ on presence 
> rules at the end of September? The sense of the room is favorable to 
> this position.
>
> Proposed that we need to do a requirements document. This proposal was 
> met with general disdain.
>
> These general discussion questions need to be raised on the mailing 
> list.
>
>
> Topic: Presence Composition
> Henning Schulzrinne
> Slides presented
>
> Previous discussions summarized.
>
> Comment: It might be nice to be able to apply credibility factors to 
> the composition. This is complicated by the lack of a source 
> attribution in each element.
>
> Issue: Source Labeling
>
> Issue; Simple Composition Policy Language
>
> Comment: Composition of "lunch" and "meeting" is difficult -- is this 
> a lunch meeting, lunch, or a meeting?
>
> Comment: Presence extrapolation is an interesting problem.
>
> Comment: This problem is similar to the configuration merging problem.
>
> Comment Yes, but presence composition errors aren't going to result in 
> device crashes or interop failures.
>
> Comment: This is a very low priority topic.
>
> Comment: A recent exercise in client-side composition revealed that 
> there are 4 or 5 categories of data, with one type of merging 
> algorithm appropriate for that data type.
>
> Comment: Conflicting information can be presented to and analyzed by 
> humans.
>
> Comment; There DOES need to be a way for the user to influence the 
> composition policy in order to get useful information in/out of a 
> system.
>
> Comment: One the things that was in the presence processing model was 
> guidance about how a user sets things.
>
> Topic: Messaging and Delivery Notfication
> Hisham Khartabil
> Slides presented
>
>
> Topic: IMDN
> Eric Burger
> Slides presented
>
> Discussion of two preceding:
>
> Comment: Recent experience with customers indicates a need to solve 
> this problem. Both drafts look like a good start but would be better 
> combined.
>
> Comment: Delivery notification would be useful for calendar 
> notifications.
>
> Discussion of XML vs not-XML inconclusive.
>
>
> Topic: Translation of Schema to WebDAV
> Rohan Mahy
> Slides presented
>
> Comment: JDR sees no value in this approach.
>
> Comment: The functionality of locking mechanism could be very useful.


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 19 11:16:49 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E68bw-0007qg-W2; Fri, 19 Aug 2005 11:16:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E68bw-0007qb-Di
	for simple@megatron.ietf.org; Fri, 19 Aug 2005 11:16:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09142
	for <simple@ietf.org>; Fri, 19 Aug 2005 11:16:45 -0400 (EDT)
Received: from hq-smtp-01.telio.no ([82.196.203.118])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E69Bn-00046M-SG
	for simple@ietf.org; Fri, 19 Aug 2005 11:53:59 -0400
Received: from office-owa-01.HQ.TELIO.NO (unknown [82.196.203.119])
	by hq-smtp-01.telio.no (Postfix) with ESMTP id 2DF2A19449B
	for <simple@ietf.org>; Fri, 19 Aug 2005 17:16:26 +0200 (CEST)
Received: from [192.168.1.17] ([192.168.1.17]) by office-owa-01.HQ.TELIO.NO
	with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 19 Aug 2005 17:22:47 +0200
Mime-Version: 1.0 (Apple Message framework v622)
Content-Transfer-Encoding: 7bit
Message-Id: <f6cc60901b65032c051c794b18b0f36f@telio.no>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: "simple@ietf.org WG" <simple@ietf.org>
From: Hisham Khartabil <hisham.khartabil@telio.no>
Date: Fri, 19 Aug 2005 17:16:29 +0200
X-Mailer: Apple Mail (2.622)
X-OriginalArrivalTime: 19 Aug 2005 15:22:47.0037 (UTC)
	FILETIME=[DA7862D0:01C5A4D1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Content-Transfer-Encoding: 7bit
Subject: [Simple] IETF 63 SIMPLE WG Meeting Minutes
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

The minutes can be found at

http://www.softarmor.com/simple/meets/ietf63/proceedings/simple63- 
minutes.html

If you have any comments, please send them in a.s.a.p as we need to  
submit the minutes as official proceedings in the very near future.

Thanks,
Hisham


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Sun Aug 21 22:30:04 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E724a-0005dX-8K; Sun, 21 Aug 2005 22:30:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E724Y-0005cg-9q
	for simple@megatron.ietf.org; Sun, 21 Aug 2005 22:30:02 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02486
	for <simple@ietf.org>; Sun, 21 Aug 2005 22:30:00 -0400 (EDT)
Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E72f0-0007xL-SD
	for simple@ietf.org; Sun, 21 Aug 2005 23:07:44 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILL003MTR780Q@szxga01-in.huawei.com> for
	simple@ietf.org; Mon, 22 Aug 2005 10:35:33 +0800 (CST)
Received: from szxml02-in ([172.24.1.6])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILL000FSR78BW@szxga01-in.huawei.com> for
	simple@ietf.org; Mon, 22 Aug 2005 10:35:32 +0800 (CST)
Received: from w39649a ([10.76.176.178])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0ILL00MQ4R9J5Q@szxml02-in.huawei.com>; Mon,
	22 Aug 2005 10:36:55 +0800 (CST)
Date: Mon, 22 Aug 2005 10:30:32 +0800
From: Smile Wang <wangsmile@huawei.com>
Subject: RE: [Simple] Questions regarding MSRP Relay drafts
In-reply-to: <4305D8A9.30003@cisco.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>
Message-id: <000001c5a6c1$786bb230$b2b04c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.6626
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: 7BIT
Cc: 'SIMPLE' <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Thank Paul.inline

Smile

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Sent: Friday, August 19, 2005 9:04 PM
> To: Smile Wang
> Cc: 'SIMPLE'
> Subject: Re: [Simple] Questions regarding MSRP Relay drafts
> 
> 
> 
> Smile Wang wrote:
> > Hi,all
> >
> > I have a doubt about the draft-ietf-simple-msrp-relays-05.txt.
> >
> > In section 3 the second example about a message being re-chunked
> >
> > through two relays.
> >
> > Alice           a.example.org(relay1)  b.example.net(relay2)         Bob
> >
> >      |                     |                    |                     |
> >
> >      |--- SEND 1-3 ------->|                    |                     |
> >
> >      |<-- 200 OK ----------|                    |  (slow link)        |
> >
> >      |--- SEND 4-7 ------->|--- SEND 1-5 ------>|                     |
> >
> >      |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->|
> >
> >      |--- SEND 8-10 ------>|--- SEND 6-10 ----->|                ....>|
> >
> >      |<-- 200 OK ----------|<-- 200 OK ---------|                  ..>|
> >
> >      |                     |                    |<-- 200 OK ----------|
> >
> >      |                     |                    |<-- REPORT 1-3 ------|
> >
> >      |                     |<-- REPORT 1-3 -----|--- SEND 4-7 ------->|
> >
> >      |<-- REPORT 1-3 ------|                    |                 ...>|
> >
> >      |                     |                    |<-- REPORT 4-7 ----->|
> >
> >      |                     |<-- REPORT 4-7 -----|--- SEND 8-10 ------>|
> >
> >      |<-- REPORT 4-7 ------|                    |                  ..>|
> >
> >      |                     |                    |<-- 200 OK ----------|
> >
> >      |                     |<-- REPORT done-----|<-- REPORT done -----|
> >
> >      |<-- REPORT done -----|                    |                     |
> >
> >      |                     |                    |                     |
> >
> >
> >
> > Why relay1 receive the part of message(1-3,4-7,8-10) not direct send to
> > relay2,but re-chunked 1-5,6-10?
> 
> There is no requirement that this rechunking be done. Relay1 could, if
> it wished, do as you suggest.
> 
> I suppose if the outbound link is congested, so that the relay receives
> multiple chunks that it has not been able to send, it might as well
> combine them.
> 
> > I consider that MSRP is app layer protocol which
> > don't take
> >
> > into account the things that transfer layer to do.And MSRP use TCP or
> > TSL which
> >
> > send the stream data,unlike UDP which data length exceed MTU must be
split.
> 
> Its a little more complicated than that. Several MSRP sessions may be
> multiplexed over the same link. In that case, it may become necessary to
> break a large message into chunks so that other messages (or parts of
> them) may be interleaved.

The mechanism of being re-chunked for MSRP is to avoid queue long time for
many users, when one user send a very large message cross a relay, the relay
can 
fragment the large message to many litte one, send some of it and deal with 
other users message. To one user is the same that can send many message at 
one time, not to wait one large message completely send out.

I thought of above. 


> 	Paul


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 22 08:16:38 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7BEE-0004XC-H7; Mon, 22 Aug 2005 08:16:38 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BED-0004X5-6j
	for simple@megatron.ietf.org; Mon, 22 Aug 2005 08:16:37 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10062
	for <simple@ietf.org>; Mon, 22 Aug 2005 08:16:33 -0400 (EDT)
Received: from seldrel01.sonyericsson.com ([212.209.106.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Boh-0006kc-I2
	for simple@ietf.org; Mon, 22 Aug 2005 08:54:22 -0400
Received: from seldrel01.sonyericsson.com(212.209.106.2) by
	seldrel01.sonyericsson.com via smtp
	id 35dd_926fe0aa_1306_11da_98e8_0002b3a9a21a;
	Mon, 22 Aug 2005 14:16:31 +0200
Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by
	seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 22 Aug 2005 14:16:12 +0200
Received: from SELDCON01.corpusers.net ([10.129.0.26]) by
	seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 22 Aug 2005 14:16:12 +0200
Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by
	SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); 
	Mon, 22 Aug 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="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
Date: Mon, 22 Aug 2005 14:16:11 +0200
Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D872D@SELDMSX01.corpusers.net>
Thread-Topic: [Simple] XCAP and its problem with Namespaces caused by using
	only the XML fragment body.
Thread-Index: AcWi7L7iZvlhczn4TTGKvOsUnSAvmwEJg60Q
From: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
To: "Jonathan Rosenberg" <jdrosen@cisco.com>
X-OriginalArrivalTime: 22 Aug 2005 12:16:12.0142 (UTC)
	FILETIME=[490838E0:01C5A713]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Content-Transfer-Encoding: quoted-printable
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Comments inline.

>
>This is clearly not optimal since it requires a full document=20
>get just to obtain the namespace bindings. However, it works=20
>with the current spec.
>

But at the same time the guidelines in 5.10 talk about the value of not
requiring a client to cache a copy of the document as well as the value
of having operations only taking a single request to perform.

So maybe not the best solution for XCAP to require clients to either
keep a cache up-to-date with the whole document or with all the
namespace bindings throughout the entire document.


>Some other thoughts are:
>
>1. an xcap extension that allowed to specifically query for=20
>the namespace bindings in scope for a particular element
>

If this can be done within the original request (is that alternative 2?)
I think it has value. In case it would require a client to make two
requests it seems to make more trouble than it solves. I suppose that
the second request also would need to be conditional to safely assure
that the data and prefixes weren't changed since the initial element
fetch.

The client could request this additional information with a special HTTP
header tag or with the Accept-header. Is there something similar
available in other areas? If we cannot reuse an existing solution we're
somehow back at the first square.

This strategy could however also help guiding clients when adding a
fragment. They could query and use prefixes already available in the
context instead of adding new xmlns declarations with every fragment
added. It would unfortunately not force them to use it.


>2. change xcap so that what is returned is an xml fragment=20
>that includes additional information on the namespace bindings in scope
>

W3C dealt with this problem years ago and came up with their XML
fragment entity. It is already a working standard and there has to be
several implementations already using this. Is there a specific reason
why the current specification requires only the fragment body and not
the fragment context specification? A look in that specification hints
that it was too verbose, giving information already available in the
URL, but you may have had other reasons too.

Another W3C standard that seems to deal with exactly the problems you
get when maintaining XML documents on a server is Exclusive XML
Canonicalization. To me this seems to be an ideal solution for us. The
fragment will simply inherit all the required namespace bindings and
include them as if it was part of the fragment. Technically this would
change the binary representation of the XML, but it helps keeping the
fragment semantically intact. The possible data overhead and the extra
processing power needed shouldn't be a problem.


>3. have the xcap server return xml data using the namespace=20
>bindings in scope for the request URI. This requires the=20
>server to modify the xml data before sending it to the client
>

Not sure if I understand this correct. Do you refer to the bindings done
already in the URI? Unfortunately they are only tracing the path to the
element and it does not include "superfluous" bindings that may be used
within the fragment received. It would not be sufficient to ignore or
remove the elements with bindings not understood as this will introduce
the risk of clients overwriting data in other namespaces on the server.=20

Also, in my opinion we should not try to add more state to the URI
itself.=20

If you weren't referring to the URL namespace bindings, maybe you were
approaching the XML Canonicalization idea.

>
>Yeah, this is another good point. This is the PUT eqiuvalent=20
>of the GET problem you describe above. Here its easier though;=20
>if the client doesn't know the namespace bindings because it=20
>doesn't have the full document, it should include the bindings=20
>in the fragment itself.
>

Easy solution but I can't help striving for perfection. Eventually the
document would be polluted with superfluous xlmns tags. An elegant
solution to this is could be, again, XML Canonicalization.

/Per



>-Jonathan R.
>--=20
>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>Director, Service Provider VoIP Architecture   Parsippany, NJ=20
>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 Mon Aug 22 18:38:44 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7KwG-0002sI-NO; Mon, 22 Aug 2005 18:38:44 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KwD-0002sB-Op
	for simple@megatron.ietf.org; Mon, 22 Aug 2005 18:38:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28217
	for <simple@ietf.org>; Mon, 22 Aug 2005 18:38:38 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Kw7-0004OZ-AC
	for simple@ietf.org; Mon, 22 Aug 2005 18:38:41 -0400
Received: from rat01047.dc-ratingen.de (rat01047_e0 [195.233.128.119])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7MMcNF1008411
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <simple@ietf.org>; Tue, 23 Aug 2005 00:38:23 +0200 (MEST)
Received: from gpsmxr04.gps.internal.vodafone.com ([195.232.231.115])
	by rat01047.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7MMcNqt005705
	for <simple@ietf.org>; Tue, 23 Aug 2005 00:38:23 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	gpsmxr04.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.1830); Tue, 23 Aug 2005 00:38:24 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Date: Mon, 22 Aug 2005 23:38:24 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02B6D7D0@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: Question on the <device-id>
Thread-Index: AcWnajSO1Aw6utzfQCq52MG6n4OSJA==
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 22 Aug 2005 22:38:24.0440 (UTC)
	FILETIME=[34D0D380:01C5A76A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Question on the <device-id>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hello,

I think there might be some problems related to the <device-id> element
in the latest versions of the PDM and RPID.
In the past the <device-id> was defined in the "rpid-tuple" namespace
and the <deviceID> in the "data-model-device" namespace.=20
Now as I see the <deviceID> is correctly transfered to the new
"data-model" namespace, but the <device-id> is missing. The data model
I-D gives examples with the <device-id> in the "data-model" namespace,
but it is not defined in the namespace itself.
On the other hand RPID-08 ignores the <device-id> from the examples
using the <deviceID> element under <tuple> instead (prefixing it based
on the PDM namespace), although it mentions the <device-id> in the
element definitions.=20
Is there something I miss here?

Best regards,
Haris

Haris Zisimopoulos
Vodafone Group Research & Development - UK

Telephone: +44 (0)7919994709
E-mail: haris.zisimopoulos@vodafone.com


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Tue Aug 23 00:25:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7QLY-0008GG-78; Tue, 23 Aug 2005 00:25:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QLW-0008GB-9s
	for simple@megatron.ietf.org; Tue, 23 Aug 2005 00:25:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28745
	for <simple@ietf.org>; Tue, 23 Aug 2005 00:25:07 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E7QLY-0006dG-4X
	for simple@ietf.org; Tue, 23 Aug 2005 00:25:13 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-1.cisco.com with ESMTP; 22 Aug 2005 21:24:58 -0700
X-IronPort-AV: i="3.96,132,1122879600"; 
	d="scan'208"; a="656107738:sNHT31108100"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7N4Otoo021342;
	Mon, 22 Aug 2005 21:24:55 -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, 23 Aug 2005 00:24:54 -0400
Received: from [192.168.1.100] ([10.86.242.34]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 23 Aug 2005 00:24:53 -0400
Message-ID: <430AA515.2080901@cisco.com>
Date: Tue, 23 Aug 2005 00:24:53 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
Subject: Re: [Simple] Question on the <device-id>
References: <6C742B4BEC7D1D4FB045E74BB625987B02B6D7D0@gpsmx11.gps.internal.vodafone.com>
In-Reply-To: <6C742B4BEC7D1D4FB045E74BB625987B02B6D7D0@gpsmx11.gps.internal.vodafone.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Aug 2005 04:24:53.0703 (UTC)
	FILETIME=[9C2E9D70:01C5A79A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

You are correct that there is a problem here. I mentioned this during 
the last IETF meeting, where I had proposed that we should define the 
<deviceID> element in common-schema.xsd. However, since the meeting I 
have realized this won't work. It would result in the <deviceID> element 
actually being defined twice, with the same local name but in two 
different namespaces - data-model and rpid. That is a recipe for disaster.

So, my proposal is to define the <deviceID> element once in the 
data-model schema, and let rpid just reuse it.

-Jonathan R.

Zisimopoulos, Haris, VF-Group wrote:
> Hello,
> 
> I think there might be some problems related to the <device-id> element
> in the latest versions of the PDM and RPID.
> In the past the <device-id> was defined in the "rpid-tuple" namespace
> and the <deviceID> in the "data-model-device" namespace. 
> Now as I see the <deviceID> is correctly transfered to the new
> "data-model" namespace, but the <device-id> is missing. The data model
> I-D gives examples with the <device-id> in the "data-model" namespace,
> but it is not defined in the namespace itself.
> On the other hand RPID-08 ignores the <device-id> from the examples
> using the <deviceID> element under <tuple> instead (prefixing it based
> on the PDM namespace), although it mentions the <device-id> in the
> element definitions. 
> Is there something I miss here?
> 
> Best regards,
> Haris
> 
> Haris Zisimopoulos
> Vodafone Group Research & Development - UK
> 
> Telephone: +44 (0)7919994709
> E-mail: haris.zisimopoulos@vodafone.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 Tue Aug 23 01:32:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7ROi-0003KH-1n; Tue, 23 Aug 2005 01:32:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ROg-0003KA-IO
	for simple@megatron.ietf.org; Tue, 23 Aug 2005 01:32:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00913
	for <simple@ietf.org>; Tue, 23 Aug 2005 01:32:29 -0400 (EDT)
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ROk-00088z-0u
	for simple@ietf.org; Tue, 23 Aug 2005 01:32:34 -0400
Received: from rtp-core-2.cisco.com (64.102.124.13)
	by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2005 01:32:20 -0400
X-IronPort-AV: i="3.96,132,1122868800"; 
	d="scan'208"; a="67483974:sNHT29506182"
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com
	[64.102.31.12])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7N5WHQl002849
	for <simple@ietf.org>; Tue, 23 Aug 2005 01:32:17 -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);
	Tue, 23 Aug 2005 01:32:17 -0400
Received: from [192.168.1.100] ([10.86.242.34]) by xfe-rtp-202.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 23 Aug 2005 01:32:17 -0400
Message-ID: <430AB4E0.2000506@cisco.com>
Date: Tue, 23 Aug 2005 01:32:16 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Simple WG <simple@ietf.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Aug 2005 05:32:17.0062 (UTC)
	FILETIME=[06363C60:01C5A7A4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
Content-Transfer-Encoding: 7bit
Subject: [Simple] updated data-model I-D
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I've submitted an update to the data-model spec, which includes 
conclusions from the last IETF meeting. Until it appears in the 
archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-04.txt

One discrepancy, however, between the minutes and my recollection. The 
minutes say:

Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
encapsulation out of data model spec. Argued that this makes for a lot 
of documents to read in order to get an implementation. General 
consensus on proposal.

I actually recall that Henning argued against this, and the conclusion 
was to just put words in. So I did. See below for the specific text.

Here are the changes:

* Added recommendation to use version 1 UUID for devices with a MAC,
version 4 UUID for those without

* added discussion of aliases as part of the section on the person
data element, as it is proposed that aliases would be a property of
the person data element.

* updated schema definition, renaming fromUntil to sinceUntil

* added text on incorporating <geopriv> objects. The text reads:

<t>
<xref target="I-D.ietf-geopriv-pidf-lo"/> defines the &lt;geopriv&gt;
XML element for conveying location information, and indicates that it
is carried as a child of the &lt;tuple&gt; element in a PIDF
document. <xref target="I-D.ietf-geopriv-pidf-lo"/> was developed
prior to this specification, and unfortunately, its recommendation to
include location objects underneath &lt;tuple&gt; runs contrary to the
recommendations here. As such, implementations based on this
specification SHOULD include &lt;geopriv&gt; location objects
as part of person and device components of the document, but SHOULD be
prepared to receive presence documents with that object as a child to
&lt;tuple&gt;.
</t>

* added text clarifiying garbage in/garbage out issue for compositors:

<t>
Presence documents created according to this model MUST be valid, with
the following exception. A compositor is permitted to create a
presence document which it cannot fully validate but which otherwise
validates when processed according to the lax processing rules allowed
by the schema of the compositor.  However, it is not expected that
entities receiving these documents would perform schema validation,
rather, they would merely access the information from the document in
the places they were expecting it to be. Implementations
SHOULD be prepared to receive documents that are not valid, and
extract whatever information from them that they can parse.
</t>


Also, as mentioned in the minutes and recently on the list, an update to 
rpid is needed to remove the <deviceID> definition and to use the new 
definition of sinceUntil.

I also checked in the schemas I used for common-schema.xsd and 
data-model.xsd into the subversion repository.

I believe we can now go to WGLC on this document.

Thanks,
Jonathan R.
-- 
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 Tue Aug 23 15:50:27 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7emx-0003id-FO; Tue, 23 Aug 2005 15:50:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7emb-0003bP-WD; Tue, 23 Aug 2005 15:50:06 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26852;
	Tue, 23 Aug 2005 15:50:03 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1E7emj-00086p-Iy; Tue, 23 Aug 2005 15:50:14 -0400
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1E7emX-00033s-To; Tue, 23 Aug 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1E7emX-00033s-To@newodin.ietf.org>
Date: Tue, 23 Aug 2005 15:50:01 -0400
X-Spam-Score: 0.4 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: simple@ietf.org
Subject: [Simple] I-D ACTION:draft-ietf-simple-presence-data-model-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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
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		: A Data Model for Presence
	Author(s)	: J. Rosenberg
	Filename	: draft-ietf-simple-presence-data-model-04.txt
	Pages		: 34
	Date		: 2005-8-23
	
This document defines the underlying presence data model and used by
   Session Initiation Protocol (SIP) for Instant Messaging Leveraging
   Presence Extensions (SIMPLE) presence agents.  The data model
   provides guidance on how to map various communications systems into
   presence documents in a consistent fashion.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-simple-presence-data-model-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-presence-data-model-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-presence-data-model-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-8-23135955.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-simple-presence-data-model-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-simple-presence-data-model-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2005-8-23135955.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 Tue Aug 23 19:37:24 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7iKa-0007CX-Rn; Tue, 23 Aug 2005 19:37:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7iKX-0007CP-Vn
	for simple@megatron.ietf.org; Tue, 23 Aug 2005 19:37:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19775
	for <simple@ietf.org>; Tue, 23 Aug 2005 19:37:18 -0400 (EDT)
Received: from dns2.tilab.com ([163.162.42.5])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7iKk-0001n1-ND
	for simple@ietf.org; Tue, 23 Aug 2005 19:37:35 -0400
Received: from iowa2k01b.cselt.it ([163.162.242.202])
	by dns2.cselt.it (PMDF V6.1 #38895)
	with ESMTP id <0ILP00G3E7MCTC@dns2.cselt.it> for simple@ietf.org; Wed,
	24 Aug 2005 01:23:01 +0200 (MEST)
Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 01:35:19 +0200
Date: Wed, 24 Aug 2005 01:37:11 +0200
From: Goix Walter <Walter.Goix@TILAB.COM>
Subject: R: [Simple] updated data-model I-D
To: Jonathan Rosenberg <jdrosen@cisco.com>, Simple WG <simple@ietf.org>
Message-id: <91C9464F6AFC0647A2D8069E25DBF496E012BC@EXC01B.cselt.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable
Importance: normal
Priority: normal
Thread-Topic: [Simple] updated data-model I-D
Thread-Index: AcWnpKPUicxZE0JqTt22igLRtgy5fAAlZCKw
Content-class: urn:content-classes:message
X-OriginalArrivalTime: 23 Aug 2005 23:35:19.0734 (UTC)
	FILETIME=[52E71560:01C5A83B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Quick comments/fixes to the new draft, mainly related to the update of =
<device-id> to <deviceID>:

- section 5, p23: "This is followed by <device-id&gt, which
   contains the URN for the device ID for this device.". "<device-id&gt" =
should probably be changed to "<deviceID>"

- example in p28 still mentions <device-id> instead of <deviceID>

Section 5.1.1 (Common XSD) is now empty. I suppose it should include the =
same content than -03.

Walter

-----Messaggio originale-----
Da: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Per conto =
di Jonathan Rosenberg
Inviato: marted=EC 23 agosto 2005 7.32
A: Simple WG
Oggetto: [Simple] updated data-model I-D

I've submitted an update to the data-model spec, which includes=20
conclusions from the last IETF meeting. Until it appears in the=20
archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-simple-presence-data-model-04.tx=
t

One discrepancy, however, between the minutes and my recollection. The=20
minutes say:

Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO=20
encapsulation out of data model spec. Argued that this makes for a lot=20
of documents to read in order to get an implementation. General=20
consensus on proposal.

I actually recall that Henning argued against this, and the conclusion=20
was to just put words in. So I did. See below for the specific text.

Here are the changes:

* Added recommendation to use version 1 UUID for devices with a MAC,
version 4 UUID for those without

* added discussion of aliases as part of the section on the person
data element, as it is proposed that aliases would be a property of
the person data element.

* updated schema definition, renaming fromUntil to sinceUntil

* added text on incorporating <geopriv> objects. The text reads:

<t>
<xref target=3D"I-D.ietf-geopriv-pidf-lo"/> defines the &lt;geopriv&gt;
XML element for conveying location information, and indicates that it
is carried as a child of the &lt;tuple&gt; element in a PIDF
document. <xref target=3D"I-D.ietf-geopriv-pidf-lo"/> was developed
prior to this specification, and unfortunately, its recommendation to
include location objects underneath &lt;tuple&gt; runs contrary to the
recommendations here. As such, implementations based on this
specification SHOULD include &lt;geopriv&gt; location objects
as part of person and device components of the document, but SHOULD be
prepared to receive presence documents with that object as a child to
&lt;tuple&gt;.
</t>

* added text clarifiying garbage in/garbage out issue for compositors:

<t>
Presence documents created according to this model MUST be valid, with
the following exception. A compositor is permitted to create a
presence document which it cannot fully validate but which otherwise
validates when processed according to the lax processing rules allowed
by the schema of the compositor.  However, it is not expected that
entities receiving these documents would perform schema validation,
rather, they would merely access the information from the document in
the places they were expecting it to be. Implementations
SHOULD be prepared to receive documents that are not valid, and
extract whatever information from them that they can parse.
</t>


Also, as mentioned in the minutes and recently on the list, an update to =

rpid is needed to remove the <deviceID> definition and to use the new=20
definition of sinceUntil.

I also checked in the schemas I used for common-schema.xsd and=20
data-model.xsd into the subversion repository.

I believe we can now go to WGLC on this document.

Thanks,
Jonathan R.
--=20
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


Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia =
S.p.A.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
MailAdmin@tilab.com. Thank you
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 24 10:44:22 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7wUI-0000hZ-B7; Wed, 24 Aug 2005 10:44:22 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wUG-0000hP-NQ
	for simple@megatron.ietf.org; Wed, 24 Aug 2005 10:44:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25176
	for <simple@ietf.org>; Wed, 24 Aug 2005 10:44:19 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wUV-0002XO-Hf
	for simple@ietf.org; Wed, 24 Aug 2005 10:44:42 -0400
Received: from heinz.vodafone-is.de (heinz_e0 [195.233.128.26])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7OEhw5k003915
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO)
	for <simple@ietf.org>; Wed, 24 Aug 2005 16:43:58 +0200 (MEST)
Received: from GPSMXR03.gps.internal.vodafone.com ([195.232.231.125])
	by heinz.vodafone-is.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7OEhtmW017538
	for <simple@ietf.org>; Wed, 24 Aug 2005 16:43:56 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	GPSMXR03.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 16:43:57 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Date: Wed, 24 Aug 2005 15:43:56 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02C7C294@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: Clarification on XCAP path seperator ~~
Thread-Index: AcWoukGo61cezHzTQPKQWWOUaED8Bg==
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 24 Aug 2005 14:43:57.0070 (UTC)
	FILETIME=[41C462E0:01C5A8BA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: quoted-printable
Subject: [Simple] Clarification on XCAP path seperator ~~
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi,

I have question regarding whether the separator "~~" in XCAP may be
escaped or not. This is important for interoperability.

It is shown in all the examples as non escaped ~~ and not escaped
(%7E%7E).

However, in security section 13, it is mentioned that XCAP documents may
be identified (e.g. by firewalls) with the presence of ~~ in the URL,
but this is just hint as URL procedures of RFC 2396 or RFC 3987 may
apply, suggesting a possibility of escaping. Specifically RFC 2396 shows
"~" as not a special character, and allows encoding (like for any other
character).

Can it be clarified if the ~~ may be escaped / percent-encoded? If so,
can it be explained directly (e.g. not by inference from security
section) and elaborated (i.e. apply URL encoding as per RFC 2396)?

Best regards,
Haris

Haris Zisimopoulos
Vodafone Group Research & Development - UK

Telephone: +44 (0)7919994709
E-mail: haris.zisimopoulos@vodafone.com


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Wed Aug 24 11:07:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E7wqC-0007T1-V2; Wed, 24 Aug 2005 11:07:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E7wqB-0007Sw-Ry
	for simple@megatron.ietf.org; Wed, 24 Aug 2005 11:06:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26717
	for <simple@ietf.org>; Wed, 24 Aug 2005 11:06:58 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7wqW-0003Ok-01
	for simple@ietf.org; Wed, 24 Aug 2005 11:07:21 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j7OF6gS0001585
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Wed, 24 Aug 2005 08:06:43 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-0-115.qualcomm.com [10.50.0.115])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7OF6euZ001262;
	Wed, 24 Aug 2005 08:06:41 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230902bf323d47adcc@[192.168.1.4]>
In-Reply-To: <6C742B4BEC7D1D4FB045E74BB625987B02C7C294@gpsmx11.gps.internal.vodafone.co
	m>
References: <6C742B4BEC7D1D4FB045E74BB625987B02C7C294@gpsmx11.gps.internal.vodafone.co
	m>
Date: Wed, 24 Aug 2005 08:06:40 -0700
To: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>,
	"Simple WG" <simple@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Simple] Clarification on XCAP path seperator ~~
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

At 3:43 PM +0100 8/24/05, Zisimopoulos, Haris, VF-Group wrote:
>Hi,
>
>I have question regarding whether the separator "~~" in XCAP may be
>escaped or not. This is important for interoperability.
>
>It is shown in all the examples as non escaped ~~ and not escaped
>(%7E%7E).
>
>However, in security section 13, it is mentioned that XCAP documents may
>be identified (e.g. by firewalls) with the presence of ~~ in the URL,
>but this is just hint as URL procedures of RFC 2396 or RFC 3987 may
>apply, suggesting a possibility of escaping. Specifically RFC 2396 shows
>"~" as not a special character, and allows encoding (like for any other
>character).

The percent-encoded form would be just as identifiable; how would
this help?
		regards,
			Ted

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 25 09:53:32 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8IAe-00085O-3Q; Thu, 25 Aug 2005 09:53:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAd-00085H-2Q
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 09:53:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18341
	for <simple@ietf.org>; Thu, 25 Aug 2005 09:53:28 -0400 (EDT)
Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IB8-0003v8-Cn
	for simple@ietf.org; Thu, 25 Aug 2005 09:54:03 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] Clarification on XCAP path seperator ~~
Date: Thu, 25 Aug 2005 16:49:22 +0300
Message-ID: <8E5AB0A04458904BB9B079055261033CE8D09F@mail.followap.com>
Thread-Topic: [Simple] Clarification on XCAP path seperator ~~
Thread-Index: AcWovu6zE6H6Lvf7RuSE2tySCxE2jgAuzWrQ
From: "Fridy Sharon-Fridman" <Fridy.Sharon-Fridman@followap.com>
To: "Ted Hardie" <hardie@qualcomm.com>, <jdrosen@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Content-Transfer-Encoding: quoted-printable
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Hi Ted,=20

It helps as it clarifies one can use percent-encoded and get translation
that will lead correctly to the XCAP resource. It was an issue of
interoperability between XDMS (OMA XCAP Servers) and clients vendors, in
latest OMA Fest 9.5.

Would you consider, at this RFC queue stage of XCAP, clarifying this
within XCAP I/D, explicitly? (now it appears as a possible consequence
from chapter 13 security discussion, and here in your E-Mail...)

Thanks,
--Fridy / Followap

-----Original Message-----
From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf
Of Ted Hardie
Sent: Wednesday, August 24, 2005 11:07 AM
To: Zisimopoulos, Haris, VF-Group; Simple WG
Subject: Re: [Simple] Clarification on XCAP path seperator ~~

At 3:43 PM +0100 8/24/05, Zisimopoulos, Haris, VF-Group wrote:
>Hi,
>
>I have question regarding whether the separator "~~" in XCAP may be
>escaped or not. This is important for interoperability.
>
>It is shown in all the examples as non escaped ~~ and not escaped
>(%7E%7E).
>
>However, in security section 13, it is mentioned that XCAP documents
may
>be identified (e.g. by firewalls) with the presence of ~~ in the URL,
>but this is just hint as URL procedures of RFC 2396 or RFC 3987 may
>apply, suggesting a possibility of escaping. Specifically RFC 2396
shows
>"~" as not a special character, and allows encoding (like for any other
>character).

The percent-encoded form would be just as identifiable; how would
this help?
		regards,
			Ted

_______________________________________________
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 25 12:55:16 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8L0W-0000Ck-6i; Thu, 25 Aug 2005 12:55:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L0U-0000Cd-GO
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 12:55:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29820
	for <simple@ietf.org>; Thu, 25 Aug 2005 12:55:11 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8L12-0001Lr-57
	for simple@ietf.org; Thu, 25 Aug 2005 12:55:49 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148])
	by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j7PGsqS0002449
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL);
	Thu, 25 Aug 2005 09:54:52 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-0-71.qualcomm.com [10.50.0.71])
	by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j7PGsnuZ024826;
	Thu, 25 Aug 2005 09:54:50 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230905bf33a81f1c00@[192.168.1.4]>
In-Reply-To: <8E5AB0A04458904BB9B079055261033CE8D09F@mail.followap.com>
References: <8E5AB0A04458904BB9B079055261033CE8D09F@mail.followap.com>
Date: Thu, 25 Aug 2005 09:54:47 -0700
To: "Fridy Sharon-Fridman" <Fridy.Sharon-Fridman@followap.com>,
	<jdrosen@cisco.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: RE: [Simple] Clarification on XCAP path seperator ~~
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

At 4:49 PM +0300 8/25/05, Fridy Sharon-Fridman wrote:
>Hi Ted,
>
>It helps as it clarifies one can use percent-encoded and get translation
>that will lead correctly to the XCAP resource. It was an issue of
>interoperability between XDMS (OMA XCAP Servers) and clients vendors, in
>latest OMA Fest 9.5.
>
>Would you consider, at this RFC queue stage of XCAP, clarifying this
>within XCAP I/D, explicitly? (now it appears as a possible consequence
>from chapter 13 security discussion, and here in your E-Mail...)
>
>Thanks,
>--Fridy / Followap

Clarifying text can be added during AUTH48 if it implies no normative
change.  Do you have suggested text?
			regards,
				Ted Hardie



_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 25 13:01:34 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8L6c-0002B5-3W; Thu, 25 Aug 2005 13:01:34 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L6a-0002Ar-57
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 13:01:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00175
	for <simple@ietf.org>; Thu, 25 Aug 2005 13:01:29 -0400 (EDT)
Received: from seldrel01.sonyericsson.com ([212.209.106.2])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8L76-0001Vy-7o
	for simple@ietf.org; Thu, 25 Aug 2005 13:02:07 -0400
Received: from seldrel01.sonyericsson.com(212.209.106.2) by
	seldrel01.sonyericsson.com via smtp
	id 593c_e034e166_1589_11da_868c_0002b3a9a21a;
	Thu, 25 Aug 2005 19:01:28 +0200
Received: from seldrel01-i.sonyericsson.com ([212.209.106.2]) by
	seldrel01.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 25 Aug 2005 19:01:11 +0200
Received: from SELDCON01.corpusers.net ([10.129.0.26]) by
	seldrel01-i.sonyericsson.com with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 25 Aug 2005 19:01:11 +0200
Received: from SELDMSX01.corpusers.net ([10.129.0.161]) by
	SELDCON01.corpusers.net with Microsoft SMTPSVC(6.0.3790.211); 
	Thu, 25 Aug 2005 19:00:36 +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] XCAP and its problem with Namespaces caused by usingonly
	the XML fragment body.
Date: Thu, 25 Aug 2005 19:00:36 +0200
Message-ID: <1AF90E65795A3D45AA116B9264B4DAAF029D875A@SELDMSX01.corpusers.net>
Thread-Topic: [Simple] XCAP and its problem with Namespaces caused by
	usingonly the XML fragment body.
Thread-Index: AcWkTcy2sIP9XZ1QQtKOXrhuKsLe+wATudGQAT5eT2A=
From: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
To: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>,
	"Dean Willis" <dean.willis@softarmor.com>, "Simple WG" <simple@ietf.org>
X-OriginalArrivalTime: 25 Aug 2005 17:00:36.0711 (UTC)
	FILETIME=[838C0F70:01C5A996]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 410b68b37343617c6913e76d02180b14
Content-Transfer-Encoding: quoted-printable
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.com>,
	Kelvin Porter <kelvin_r_porter@yahoo.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I hope that many with me agree that the best alternative is to solve =
this XCAP issue within the IETF.

As I wrote in my response to Rosenberg, W3C has dealt with this problem =
years ago and has come up with both XML fragment context specification =
and canonicalization. They are working standards and there has to be =
several implementations already using this.

But you are right, as your suggestions on workarounds show, this problem =
could probably be avoided by OMA PoC with some changes in the current =
OMA specifications, some more dramatic than others. I would personally =
like to see that a client is able to fetch a part of a document without =
having to do multiple requests, or having to maintain one more document, =
with all the problems this could cause. The suggested solution A and B =
allows for this, but there is a trade-off as it limits or complicates =
extensibility in future versions and the possibility to use proprietary =
extensions etc.

/Per=20

>-----Original Message-----
>From: Zisimopoulos, Haris, VF-Group=20
>[mailto:Haris.Zisimopoulos@vodafone.com]=20
>Sent: fredag den 19 augusti 2005 11:04
>To: Dean Willis; Simple WG
>Cc: Kelvin Porter; Hyttfors, Per
>Subject: RE: [Simple] XCAP and its problem with Namespaces=20
>caused by usingonly the XML fragment body.
>
>From my point of view I don't think things are as dramatic for=20
>the usage of XCAP for PoC .=20
>
>OMA uses XCAP to manipulate different types of documents:
>- Presence Lists (using only the IETF namespace)
>- Presence Authorisation rules (using the IETF namespace+OMA=20
>extensions due to the fact that there is a number of OMA=20
>defined presence elements)
>- PoC conference policy documents (using OMA namespaces only)
>- PoC user access documents (using OMA namespaces only)
>- PoC directory (using namespaces only)
>
>An OMA compliant PoC client needs to support all these=20
>namespaces (OMA and IETF defined). Therefore is a number of=20
>different approaches that could be used as workarounds for PoC:
>=20
>A) Wrap all the namespaces per application usage in one single=20
>OMA defined namespace
>B) Standardise the prefixes (I think there is a small change=20
>that is necessary for this to work)
>C) Create a document (similar to xcap-caps) per each XCAP=20
>server to fetch the namespace/prefix bindings
>
>I understand that all these are not flexible enough and do not=20
>make XCAP a "generic" XML manipulation protocol that can=20
>handle any kind of namespaces, without the client's prior=20
>knowledge (but I don't think this was the initial requirement,=20
>as I understand it).
>
>My vote therefore would be: stick with what we have right now=20
>(maybe there are couple of small changes that need to be done=20
>particularly in section 6.4 and some similar changes in the=20
>OMA specs to make some of the workarounds to be possible) and=20
>do the extensions in a separate track.
>
>Best regards,
>Haris
>
>Haris Zisimopoulos
>Group Research & Development - UK
>Vodafone Group Services Ltd
>E-mail: haris.zisimopoulos@vodafone.com=20
>
>-----Original Message-----
>From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org]=20
>On Behalf Of Dean Willis
>Sent: 19 August 2005 00:36
>To: Simple WG
>Cc: Kelvin Porter; Hyttfors,Per
>Subject: Re: [Simple] XCAP and its problem with Namespaces=20
>caused by usingonly the XML fragment body.
>
>
>I'm thinking that this message documents a relatively=20
>significant problem either with XCAP or with a usage of XCAP=20
>as proposed by OMA PoC.
>
>XCAP is currently in the RFC Editor's Queue, and consequently=20
>somewhat hard to change, but some changes could perhaps be=20
>made by an IESG "note to the RFC editor" if needed (and=20
>approved by the IESG).
>
>I'd like to see some discussion of the severity of this=20
>problem and what should be done about it -- preferability Very=20
>Soon, as OMA is meeting next week.
>
>Possibilities I see:
>
>1) Fix the XCAP spec before publication.
>
>2) Obsolete the current XCAP spec and produce a new one.
>
>3) Define an extension to XCAP to fix the problem.
>
>4) Decide it's not really an XCAP problem, because OMA PoC is=20
>using the protocol in a manner inconsistent with its design=20
>requirements, and help OMA PoC come up with a workaround.
>
>5) Something entirely different.
>
>Thanks!
>
>--
>Dean WIllis
>as IETF liaison to OMA
>
>On Aug 10, 2005, at 6:32 AM, Hyttfors, Per wrote:
>
>> Hello,
>> =A0
>> As I see it there is a major problem with retrieving elements in an=20
>> XML document using XCAP. The problem has to do with that the XDM=20
>> clients has to know all the namespace prefix bindings in the server=20
>> document prio the fetch of an element.
>> =A0
>> The problem is that the current XCAP specification only=20
>mandates that=20
>> a XCAP fragment body is sent between server and client when=20
>performing=20
>> XCAP operations. Not being an fcs document with the fragment context=20
>> specification leads to problems now when the XCAP URL has been made=20
>> independent of the namespaces prefixes used in the document on the=20
>> server.
>> =A0
>> The XML data returned in the 200 OK answer on a fetch of an element=20
>> will contain the exact content of that element in the XML=20
>document on=20
>> the server. If this element or any child elements use namespace=20
>> prefixes declared earlier in the document they will not be=20
>included in=20
>> the response to the client. Hence the only way to know all the=20
>> prefixes is to have done a fetch of the whole document.
>>
>> Just to clarify the problem I have made these examples (inspiration=20
>> from the XCAP specification..)
>> =A0
>> Bill has not fetched the whole server document, and it=A0looks=20
>like this:
>> =A0
>> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>> =A0=A0 <rls-services xmlns=3D"urn:ietf:params:xml:ns:rls-services"
>> =A0=A0=A0=A0=A0 xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
>> =A0=A0=A0=A0=A0 =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
>> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
>> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
>> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
>> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
>> =A0=A0=A0=A0=A0 </a:list>
>> =A0=A0=A0=A0=A0 <packages>
>> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
>> =A0=A0=A0=A0=A0 </packages>
>> =A0=A0=A0 </service>
>> =A0=A0 </rls-services>
>> =A0
>>
>> Bill decides to get the service information for uri=20
>> sip:marketing@example.com
>> =A0
>> =A0=A0 GET
>> =A0=A0 /rls-services/users/bill/index/~~/rls-services/
>> =A0=A0 service%5b@uri=3D%22sip:marketing@example.com%5d
>> =A0=A0=A0 HTTP/1.1
>> =A0
>> =A0=A0 and the server responds:
>> =A0
>> =A0=A0 HTTP/1.1 200 OK
>> =A0=A0 Etag: "ad88"
>> =A0=A0 Content-Type:application/xcap-el+xml
>> =A0
>> =A0=A0=A0 <service uri=3D"sip:marketing@example.com">
>> =A0=A0=A0=A0=A0 <a:list name=3D"marketing">
>> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com"/>
>> =A0=A0=A0=A0=A0=A0=A0 <a:entry uri=3D"sip:sudhir@example.com"/>
>> =A0=A0=A0=A0=A0 </a:list>
>> =A0=A0=A0=A0=A0 <packages>
>> =A0=A0=A0=A0=A0=A0=A0 <package>presence</package>
>> =A0=A0=A0=A0=A0 </packages>
>> =A0=A0=A0 </service>
>> =A0
>> Bill is now confused as he has no idea what namespace the tags that=20
>> are using the namespace prefix a: belongs to, so he has to fetch the=20
>> whole document to find out....
>> =A0
>> =A0
>> Also as disscussed earlier:=20
>>=20
>http://www1.ietf.org/mail-archive/web/simple/current/msg04937.html=A0the=
=20
>> XDM client has to always send the xmlns declaration with the XML=20
>> elements that are sent in a PUT in order to be sure that it=20
>will be a=20
>> valid part of the complete XML document on the server..
>> =A0
>> This would be a situation where the client would have a=20
>problem if the=20
>> xmlns declaration is missing in the XML fragment body:
>>
>> The server document looks like this:
>> =A0
>> =A0=A0 <?xml version=3D"1.0" encoding=3D"UTF-8"?>
>> =A0=A0 <a:resource-lists =
xmlns:a=3D"urn:ietf:params:xml:ns:resource-lists"
>> =A0=A0=A0 xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance">
>> =A0=A0=A0 <a:list name=3D"close-friends">
>> =A0=A0=A0=A0 <a:display-name>Close Friends</a:display-name>
>> =A0=A0=A0=A0 <a:entry uri=3D"sip:joe@example.com">
>> =A0=A0=A0=A0=A0 <a:display-name>Joe Smith</a:display-name>
>> =A0=A0=A0=A0 </a:entry>
>> =A0=A0=A0 </a:list>
>> =A0=A0 </a:resource-lists>
>> =A0
>> Bill creates an element in the resource-lists document=20
>(Section 7.4).=20
>> In particular, he creates a list with an entry:
>>
>> =A0=A0 PUT
>> =A0=A0 /services/resource-lists/users/bill/fr.xml
>> =A0=A0 /~~/resource-lists/list%5b@name=3D%22friends%22%5d HTTP/1.1
>> =A0=A0 Content-Type:application/xcap-el+xml
>> =A0=A0 Host: xcap.example.com
>>
>> =A0
>> =A0=A0 <list name=3D"friends">
>> =A0=A0=A0=A0 <entry uri=3D"sip:bob@example.com">
>> =A0=A0=A0=A0=A0=A0 <display-name>Bob Jones</display-name>
>> =A0=A0=A0=A0 </entry>
>> =A0=A0 </list>
>> =A0
>> Bill will cry as the validation of the document after the=20
>tentatively=20
>> insertion will fail as this will produce a invalid XML document..
>> =A0
>> =A0
>>
>> /Per
>> =A0
>> Per Hyttfors
>> ___________________________________________________________
>> Development Engineer - Messaging Application Development=20
>Sony Ericsson=20
>> Mobile Communications AB
>> SE-221 88 Lund, Sweden
>> +46 46 2126534
>> per.hyttfors@sonyericsson.com (MSN/E-mail)=20
>> ___________________________________________________________
>>
>> The information in this email, and attachment(s) thereto, is=20
>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=20
>> hereof may result in legal actions. Any attachment(s) to this e-mail=20
>> has been checked for viruses, but please rely on your own=20
>> virus-checker and procedures. If you contact us by e-mail, we will=20
>> store your name and address to facilitate communications in=20
>the matter=20
>> concerned. If you do not consent to us storing your name and address=20
>> for above stated purpose, please notify the sender promptly.=20
>Also, if=20
>> you are not the intended recipient please inform the sender by=20
>> replying to this transmission, and delete the e-mail, its=20
>> attachment(s), and any copies of it without, disclosing it.
>> =A0_______________________________________________
>> 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 Aug 25 13:24:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8LSm-0008BF-Eu; Thu, 25 Aug 2005 13:24:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8LSk-0008B2-Pw
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 13:24:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01205
	for <simple@ietf.org>; Thu, 25 Aug 2005 13:24:23 -0400 (EDT)
Received: from rat01037.dc-ratingen.de ([195.233.129.142])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8LTE-00029V-Kw
	for simple@ietf.org; Thu, 25 Aug 2005 13:25:02 -0400
Received: from rat01047.dc-ratingen.de (rat01047_e0 [195.233.128.119])
	by rat01037.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7PHO4kR006448
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Thu, 25 Aug 2005 19:24:04 +0200 (MEST)
Received: from GPSMXR03.gps.internal.vodafone.com ([195.232.231.125])
	by rat01047.dc-ratingen.de (Switch-3.1.4/Switch-3.1.0) with ESMTP id
	j7PHO4Rr020496; Thu, 25 Aug 2005 19:24:04 +0200 (MEST)
Received: from gpsmx11.gps.internal.vodafone.com ([145.230.1.15]) by
	GPSMXR03.gps.internal.vodafone.com with Microsoft
	SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 19:24:14 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53
Subject: RE: [Simple] Question on simple-event-list-07
Date: Thu, 25 Aug 2005 18:24:03 +0100
Message-ID: <6C742B4BEC7D1D4FB045E74BB625987B02D080A1@gpsmx11.gps.internal.vodafone.com>
Thread-Topic: [Simple] Question on simple-event-list-07
Thread-Index: AcWkGE6Lp70hARmESJeEGYOaU+xxKwFf65ZQ
From: "Zisimopoulos, Haris, VF-Group" <Haris.Zisimopoulos@vodafone.com>
To: "Adam Roach" <adam@nostrum.com>, <simple@ietf.org>
X-OriginalArrivalTime: 25 Aug 2005 17:24:14.0739 (UTC)
	FILETIME=[D0C1F630:01C5A999]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: quoted-printable
Cc: 
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Adam,

Thanks for the clarification. What I am worried about related to that is
also the fact a very large RLMI document can become an overkill for
wireless terminals memory, UI processing etc. Taking into account that
the "resource list" can potentially be "shared document" manipulated
also with XCAP by multiple clients this can also be a kind of DoS attack
for example in open chat group situations (with some mobile terminals).
Therefore I was wondering if there is any alternative to transfer the
whole rlmi in one single NOTIFY as recommended in the last paragraph of
section 4.5? Can it be the case that for the "non-performed" back end
subscriptions you send them in a separate NOTIFY or you don't send them
at all?=20
Any ideas?

Best regards,
Haris

-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]=20
Sent: 18 August 2005 18:14
To: Zisimopoulos, Haris, VF-Group
Cc: simple@ietf.org
Subject: Re: [Simple] Question on simple-event-list-07

Zisimopoulos, Haris, VF-Group wrote:

>In section 4.5 of draft-ietf-simple-event-list-07 it is stated that:=20
>
>"The "state" attribute of each instance of a resource in the meta-=20
>information is set according to the state of the virtual subscription.
>The meanings of the "state" attribute are described in RFC 3265 [2]"
>
>Does this means that there is 1-to-1 mapping between the=20
>"Subscription-state" header of the NOTIFY request of the back-end=20
>subscription and the "state" attribute of the RLMI?
>

They are semantically equivalent. This isn't quite the same thing as
having a one-to-one mapping, since back-end subscriptions can take the
form of any arbitrary protocol (not just SIP). In any case, the actual
linkage between any back end subscriptions -- even if they are SIP --
and the resource list subscription is a matter of implementation, not
standardization. It is certainly *sensible* that you would simply pass
these states through, but there may be other reasonable things to do as
well.

>In that case how will be handled back-end subscriptions that do never
get a NOTIFY?
>

The  most reasonable thing to do would be to return an RLMI document in
which the "<resource>" element corresponding to that failed subscription
contains no "<instance>" elements. See, for example, the entries for
"sip:ed@dallas.example.com" and "sip:adam-friends@stockholm.example.com"

in step 3 of the example in section 6.

/a

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 25 15:26:55 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8NNH-0000PV-Sp; Thu, 25 Aug 2005 15:26:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NNG-0000PQ-Id
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 15:26:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10240
	for <simple@ietf.org>; Thu, 25 Aug 2005 15:26:52 -0400 (EDT)
Received: from mail1.followap.com ([194.90.96.46] helo=mail.followap.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8NNo-0006Hx-4t
	for simple@ietf.org; Thu, 25 Aug 2005 15:27:30 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Simple] Clarification on XCAP path seperator ~~
Date: Thu, 25 Aug 2005 22:21:51 +0300
Message-ID: <8E5AB0A04458904BB9B079055261033CE8D19E@mail.followap.com>
Thread-Topic: [Simple] Clarification on XCAP path seperator ~~
Thread-Index: AcWplhgKIGHyKE2uQtGt5ae7BRa1bgAAtmQw
From: "Fridy Sharon-Fridman" <Fridy.Sharon-Fridman@followap.com>
To: "Ted Hardie" <hardie@qualcomm.com>, <jdrosen@cisco.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Content-Transfer-Encoding: quoted-printable
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org


At 4:49 PM +0300 8/25/05, Fridy Sharon-Fridman wrote:
>Hi Ted,
>
>It helps as it clarifies one can use percent-encoded and get
translation
>that will lead correctly to the XCAP resource. It was an issue of
>interoperability between XDMS (OMA XCAP Servers) and clients vendors,
in
>latest OMA Fest 9.5.
>
>Would you consider, at this RFC queue stage of XCAP, clarifying this
>within XCAP I/D, explicitly? (now it appears as a possible consequence
>from chapter 13 security discussion, and here in your E-Mail...)
>
>Thanks,
>--Fridy / Followap

Clarifying text can be added during AUTH48 if it implies no normative
change.  Do you have suggested text?
			regards,
				Ted Hardie


[Fridy] :-) Yes. Please see below local text as option 1. It may require
a global text - See option 2. The 3rd option seems unnecessary but more
"aligned" with section 6 overview.

(1)

6.  URI Construction

   In order to manipulate an XCAP resource, the data must be represented
   by an HTTP URI.  XCAP defines a specific naming convention for
   constructing these URIs.  The URI is constructed by concatenating the
   XCAP root with the document selector with the path separator with a
   escape coded form of the node selector.  This is followed by an
   optional query component that defines namespace bindings used in
   evaluating the URI.  The XCAP root is the enclosing context in which
   all XCAP resources live.  The document selector is a path that
   identifies a document within the XCAP root.  The path separator is a
   path segment with a value of double tilde ("~~")

<<Start of new Text>>
   , and MAY be percent encoded as defined in [RFC3986].
<<End of new text>>

   It is piece of
   syntactic sugar that separates the document selector from the node
   selector.  The node selector is an expression that identifies an XML
   element within a document.

BTW RFC 2396 is referenced (and then the term is called "escape") but
not the newer RFC 3986. It may be needed to replace the reference above
or add a reference, and update [RFC3986] above to the relevant number.

(2)

6.  URI Construction

   In order to manipulate an XCAP resource, the data must be represented
   by an HTTP URI.  XCAP defines a specific naming convention for
   constructing these URIs.  The URI is constructed by concatenating the
   XCAP root with the document selector with the path separator with a
   escape coded form of the node selector.  This is followed by an
   optional query component that defines namespace bindings used in
   evaluating the URI.  The XCAP root is the enclosing context in which
   all XCAP resources live.  The document selector is a path that
   identifies a document within the XCAP root.  The path separator is a
   path segment with a value of double tilde ("~~").  It is piece of
   syntactic sugar that separates the document selector from the node
   selector.  The node selector is an expression that identifies an XML
   element within a document.

<<Start of new Text>>
   The HTTP URI MAY be percent encoded as defined in [RFC3986].
<<End of new text>>

   The sections below describe these components in more detail.

(3)

Add a section between 6.2 and 6.3 (and change numbers and toc)

	"6.2"		Path Separator

	The path separator is a path segment with a value of double
tilde 	("~~"), and MAY be percent encoded as defined in [RFC3986]. =20
	It is piece of syntactic sugar that separates the document
selector 	from the node selector. =20

And=20

<<Remove from 6 this "It is piece of syntactic sugar that separates the
document selector from the node selector.">>

Cheers,
--Fridy / Followap

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 25 16:16:35 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8O9L-0004EK-1f; Thu, 25 Aug 2005 16:16:35 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8O9I-0004Dm-HZ
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 16:16:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16316
	for <simple@ietf.org>; Thu, 25 Aug 2005 16:16:30 -0400 (EDT)
Received: from nylon.softarmor.com ([66.135.38.164])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8O9s-0000qW-Qr
	for simple@ietf.org; Thu, 25 Aug 2005 16:17:09 -0400
Received: from [10.10.3.135] ([142.131.68.142]) (authenticated bits=0)
	by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j7PKKeHO001820
	(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO);
	Thu, 25 Aug 2005 15:20:41 -0500
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <4a74898e5c312ea17070aac9d5147a5a@softarmor.com>
Content-Transfer-Encoding: 7bit
From: Dean Willis <dean.willis@softarmor.com>
Date: Thu, 25 Aug 2005 15:16:22 -0500
To: Simple WG <simple@ietf.org>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Content-Transfer-Encoding: 7bit
Cc: Tao Haukka <tao.haukka@NOKIA.COM>
Subject: [Simple] XCAP Question on Response Code for Insert
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Here's the question as it was asked me:

"Problem Summary:
In the document: "The Extensible Markup Language (XML)Configuration 
Access Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 is 
unclear regarding a server response to a PUT request.

Problem Text:
In the document: "The Extensible Markup Language (XML)Configuration
Access Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 
states "If the creation or insertion was successful, and the resource 
interdependencies are resolved, the server returns a 200 OK or 201 
Created, as appropriate."

What is the appropriate response when inserting an element or attribute 
into a pre-existing document?"


-------


My read:

A 200 is returned on a successful creation.

A 201 is returned on a successful insertion, and a diff with a single 
document element and before-and-after etags is returned.

This suggests that the answer to the above question is "A 201 response".

Section 7.4 of XCAP (Insertion) says:

    Once the client constructs the URI, it invokes the HTTP PUT method.
    If the client is creating a new element, it SHOULD include
    "application/xcap-diff+xml" in the Accept header field of the
    request.  This allows the server to return an XCAP Diff document in a
    201 response code, and is useful for subsequent conditional
    operations, as described in Section 7.10.  The content in the request
    MUST be an XML element.  Specifically, it contains the element,
    starting with the opening bracket for the begin tag for that element,
    including the attributes and content of that element (whether it be
    text or other child elements), and ending with the closing bracket
    for the end tag for that element.  The MIME type in the request MUST
    be "application/xcap-el+xml", defined in Section 14.2.1.  If the node
    selector, when evaluated against the current document, results in a
    no-match, the server performs a creation operation.  If the node
    selector, when evaluated against the current document, is a match for
    an element in the current document, the server replaces it with the
    content of the PUT request.  This replacement is complete; that is,
    the old element (including its attributes and content) are removed,
    and the new one, including its attributes and content, is put in its
    place.

Does that sound right?

--
Dean


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Thu Aug 25 17:31:33 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8PJt-0003yJ-Ng; Thu, 25 Aug 2005 17:31:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PJs-0003yE-A4
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 17:31:32 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21355
	for <simple@ietf.org>; Thu, 25 Aug 2005 17:31:30 -0400 (EDT)
Received: from ithilien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8PKT-000305-Ce
	for simple@ietf.org; Thu, 25 Aug 2005 17:32:09 -0400
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149])
	by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j7PLVCSJ016659; Thu, 25 Aug 2005 14:31:13 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-0-63.qualcomm.com [10.50.0.63])
	by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id
	j7PLV8Np013571; Thu, 25 Aug 2005 14:31:10 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0623090bbf33e73f30c9@[192.168.1.4]>
In-Reply-To: <8E5AB0A04458904BB9B079055261033CE8D19E@mail.followap.com>
References: <8E5AB0A04458904BB9B079055261033CE8D19E@mail.followap.com>
Date: Thu, 25 Aug 2005 14:31:06 -0700
To: "Fridy Sharon-Fridman" <Fridy.Sharon-Fridman@followap.com>,
	<jdrosen@cisco.com>
From: Ted Hardie <hardie@qualcomm.com>
Subject: RE: [Simple] Clarification on XCAP path seperator ~~
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

At 10:21 PM +0300 8/25/05, Fridy Sharon-Fridman wrote:
>6.  URI Construction
>
>   In order to manipulate an XCAP resource, the data must be represented
>   by an HTTP URI.  XCAP defines a specific naming convention for
>   constructing these URIs.  The URI is constructed by concatenating the
>   XCAP root with the document selector with the path separator with a
>   escape coded form of the node selector.  This is followed by an
>   optional query component that defines namespace bindings used in
>   evaluating the URI.  The XCAP root is the enclosing context in which
>   all XCAP resources live.  The document selector is a path that
>   identifies a document within the XCAP root.  The path separator is a
>   path segment with a value of double tilde ("~~")
>
><<Start of new Text>>
>   , and MAY be percent encoded as defined in [RFC3986].
><<End of new text>>
>
>   It is piece of
>   syntactic sugar that separates the document selector from the node
>   selector.  The node selector is an expression that identifies an XML
>   element within a document.

Actually, rereading 3986, Section 2.3, I find this (note that ~ is an
unreserved character):

   URIs that differ in the replacement of an unreserved character with
   its corresponding percent-encoded US-ASCII octet are equivalent: they
   identify the same resource.  However, URI comparison implementations
   do not always perform normalization prior to comparison (see Section
   6).  For consistency, percent-encoded octets in the ranges of ALPHA
   (%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
   underscore (%5F), or tilde (%7E) should not be created by URI
   producers and, when found in a URI, should be decoded to their
   corresponding unreserved characters by URI normalizers.

So it looks like the advice should be "SHOULD NOT be percent-encoded,
as advised in Section 2.3 of RFC 3986.  URIs containing %7E%7E should
be normalized to ~~ for comparison; they are equivalent.".

Haris's original mail referenced 2396 which might be ambiguous.  I believe 3986
is pretty clear here, though, and updating the reference to 3986 and adding
this clarification looks like it removes any ambiguity.

Does this make sense, or am I missing something here?
			regards,
				Ted Hardie









>BTW RFC 2396 is referenced (and then the term is called "escape") but
>not the newer RFC 3986. It may be needed to replace the reference above
>or add a reference, and update [RFC3986] above to the relevant number.
>
>(2)
>
>6.  URI Construction
>
>   In order to manipulate an XCAP resource, the data must be represented
>   by an HTTP URI.  XCAP defines a specific naming convention for
>   constructing these URIs.  The URI is constructed by concatenating the
>   XCAP root with the document selector with the path separator with a
>   escape coded form of the node selector.  This is followed by an
>   optional query component that defines namespace bindings used in
>   evaluating the URI.  The XCAP root is the enclosing context in which
>   all XCAP resources live.  The document selector is a path that
>   identifies a document within the XCAP root.  The path separator is a
>   path segment with a value of double tilde ("~~").  It is piece of
>   syntactic sugar that separates the document selector from the node
>   selector.  The node selector is an expression that identifies an XML
>   element within a document.
>
><<Start of new Text>>
>   The HTTP URI MAY be percent encoded as defined in [RFC3986].
><<End of new text>>
>
>   The sections below describe these components in more detail.
>
>(3)
>
>Add a section between 6.2 and 6.3 (and change numbers and toc)
>
>	"6.2"		Path Separator
>
>	The path separator is a path segment with a value of double
>tilde	("~~"), and MAY be percent encoded as defined in [RFC3986]. 
>	It is piece of syntactic sugar that separates the document
>selector	from the node selector. 
>
>And
>
><<Remove from 6 this "It is piece of syntactic sugar that separates the
>document selector from the node selector.">>
>
>Cheers,
>--Fridy / Followap
>
>_______________________________________________
>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 25 22:14:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8TjJ-0003Ti-Mu; Thu, 25 Aug 2005 22:14:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8TjG-0003TX-T3
	for simple@megatron.ietf.org; Thu, 25 Aug 2005 22:14:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08223
	for <simple@ietf.org>; Thu, 25 Aug 2005 22:14:00 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Tjt-0003lF-KE
	for simple@ietf.org; Thu, 25 Aug 2005 22:14:42 -0400
Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net
	[141.153.174.94]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j7Q2DtQO028100
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Thu, 25 Aug 2005 22:13:56 -0400 (EDT)
Message-ID: <430E7AE3.1000706@cs.columbia.edu>
Date: Thu, 25 Aug 2005 22:13:55 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
	<42FA44FE.7020703@cisco.com> <42FCE04A.80901@nokia.com>
	<42FCFEFB.6040502@cisco.com>
In-Reply-To: <42FCFEFB.6040502@cisco.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: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: 7bit
Cc: Aki Niemi <aki.niemi@nokia.com>, simple@ietf.org
Subject: [Simple] Common policy: domain matching (was: tel URIs)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

I agree with Jonathan that there doesn't seem to be a simple solution to 
the tel problem and that we might want to defer this.

However, we still need some agreement on the domain matching issue 
raised below.

My inclination, based on what I'd users expect to see happen, is to either

- treat domain.com as allowing *.domain.com and assume that the need to 
restrict matching for policy reasons in the manner Paul described is 
sufficiently unlikely;

- adopt a convention that .cisco.com (not leading dot) allows 
*.cisco.com, while cisco.com does not.

I just can't see having a flag or similar mechanism to further 
complicate the matching rules for rather odd corner cases.

Henning

Paul Kyzivat wrote:
> 

> Well, suppose there is a domain called cisco.com. NAPTR and SRV entries 
> map this to phones.cisco.com - a sip server for corporate addresses at 
> Cisco. There may be another domain - test.cisco.com with NAPTR and SRV 
> entries mapping to test-phones.cisco.com. Those servers are under 
> independent administration.
> 
> My decision about whether to authorize users from sip:cisco.com is 
> independent of whether to authorize users from sip:test.cisco.com. It is 
> especially the case that authorizing sip:paul@cisco.com and 
> sip:paul@test.cisco.com needs to be independent.
> 
> Now I indeed MAY want to authorize all domains ending in cisco.com. But 
> that needs to be a choice that I can make or not as I prefer.
> 
>     Paul


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 26 00:10:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8VXg-0008I0-9Q; Fri, 26 Aug 2005 00:10:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8VXd-0008Hc-7T
	for simple@megatron.ietf.org; Fri, 26 Aug 2005 00:10:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11677
	for <simple@ietf.org>; Fri, 26 Aug 2005 00:10:06 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8VYG-0006Xz-UB
	for simple@ietf.org; Fri, 26 Aug 2005 00:10:50 -0400
Received: from sj-core-5.cisco.com (171.71.177.238)
	by sj-iport-5.cisco.com with ESMTP; 25 Aug 2005 21:10:00 -0700
X-IronPort-AV: i="3.96,142,1122879600"; 
	d="scan'208"; a="207719577:sNHT31688596"
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7Q49soq020783;
	Thu, 25 Aug 2005 21:09:56 -0700 (PDT)
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Thu, 25 Aug 2005 21:09:56 -0700
Received: from cisco.com ([10.89.16.93]) by xfe-sjc-211.amer.cisco.com with
	Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 21:09:56 -0700
Message-ID: <430E9613.1030805@cisco.com>
Date: Fri, 26 Aug 2005 00:09:55 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
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 <hgs@cs.columbia.edu>
References: <42F61879.1000207@cs.columbia.edu> <42F9CF66.2070604@nokia.com>
	<42FA44FE.7020703@cisco.com> <42FCE04A.80901@nokia.com>
	<42FCFEFB.6040502@cisco.com> <430E7AE3.1000706@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2005 04:09:56.0231 (UTC)
	FILETIME=[047C8170:01C5A9F4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Content-Transfer-Encoding: 7bit
Cc: Aki Niemi <aki.niemi@nokia.com>, simple@ietf.org
Subject: [Simple] Re: Common policy: domain matching (was: tel URIs)
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org



Henning Schulzrinne wrote:
> I agree with Jonathan that there doesn't seem to be a simple solution to 
> the tel problem and that we might want to defer this.
> 
> However, we still need some agreement on the domain matching issue 
> raised below.
> 
> My inclination, based on what I'd users expect to see happen, is to either
> 
> - treat domain.com as allowing *.domain.com and assume that the need to 
> restrict matching for policy reasons in the manner Paul described is 
> sufficiently unlikely;
> 
> - adopt a convention that .cisco.com (not leading dot) allows 
> *.cisco.com, while cisco.com does not.

I would be ok with .cisco.com, or *.cisco.com.
I'd be less happy with not allowing the option.

	Paul

> I just can't see having a flag or similar mechanism to further 
> complicate the matching rules for rather odd corner cases.
> 
> Henning
> 
> Paul Kyzivat wrote:
> 
>>
> 
>> Well, suppose there is a domain called cisco.com. NAPTR and SRV 
>> entries map this to phones.cisco.com - a sip server for corporate 
>> addresses at Cisco. There may be another domain - test.cisco.com with 
>> NAPTR and SRV entries mapping to test-phones.cisco.com. Those servers 
>> are under independent administration.
>>
>> My decision about whether to authorize users from sip:cisco.com is 
>> independent of whether to authorize users from sip:test.cisco.com. It 
>> is especially the case that authorizing sip:paul@cisco.com and 
>> sip:paul@test.cisco.com needs to be independent.
>>
>> Now I indeed MAY want to authorize all domains ending in cisco.com. 
>> But that needs to be a choice that I can make or not as I prefer.
>>
>>     Paul
> 
> 

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 26 04:12:15 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8ZJv-0003h3-ED; Fri, 26 Aug 2005 04:12:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ZJt-0003g3-Di
	for simple@megatron.ietf.org; Fri, 26 Aug 2005 04:12:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04102
	for <simple@ietf.org>; Fri, 26 Aug 2005 04:12:11 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8ZKZ-0004ly-Vs
	for simple@ietf.org; Fri, 26 Aug 2005 04:12:56 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id
	j7Q8BcPO003404; Fri, 26 Aug 2005 11:11:41 +0300
Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 26 Aug 2005 11:12:09 +0300
Received: from [127.0.0.1] ([172.17.166.87]) by esebh002.NOE.Nokia.com with
	Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Aug 2005 11:12:08 +0300
Message-ID: <430ECED6.5080705@nokia.com>
Date: Fri, 26 Aug 2005 11:12:06 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 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: Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Simple] XCAP Question on Response Code for Insert
References: <4a74898e5c312ea17070aac9d5147a5a@softarmor.com>
In-Reply-To: <4a74898e5c312ea17070aac9d5147a5a@softarmor.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 26 Aug 2005 08:12:08.0933 (UTC)
	FILETIME=[DAA6D950:01C5AA15]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Dean:

I guess you swapped the semantics of 200 and 201 in your post.

A 200 is returned as a successful replacement

A 201 is returned as a succesful creation of a new resource (including 
the xca-diff document)

In my opinion XCAP is clear if you consider the normative dependency to 
RFC 2616.

/Miguel

Dean Willis wrote:

> Here's the question as it was asked me:
> 
> "Problem Summary:
> In the document: "The Extensible Markup Language (XML)Configuration 
> Access Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 is 
> unclear regarding a server response to a PUT request.
> 
> Problem Text:
> In the document: "The Extensible Markup Language (XML)Configuration
> Access Protocol, (XCAP), draft-ietf-simple-xcap-07" section 8.2.6 states 
> "If the creation or insertion was successful, and the resource 
> interdependencies are resolved, the server returns a 200 OK or 201 
> Created, as appropriate."
> 
> What is the appropriate response when inserting an element or attribute 
> into a pre-existing document?"
> 
> 
> -------
> 
> 
> My read:
> 
> A 200 is returned on a successful creation.
> 
> A 201 is returned on a successful insertion, and a diff with a single 
> document element and before-and-after etags is returned.
> 
> This suggests that the answer to the above question is "A 201 response".
> 
> Section 7.4 of XCAP (Insertion) says:
> 
>    Once the client constructs the URI, it invokes the HTTP PUT method.
>    If the client is creating a new element, it SHOULD include
>    "application/xcap-diff+xml" in the Accept header field of the
>    request.  This allows the server to return an XCAP Diff document in a
>    201 response code, and is useful for subsequent conditional
>    operations, as described in Section 7.10.  The content in the request
>    MUST be an XML element.  Specifically, it contains the element,
>    starting with the opening bracket for the begin tag for that element,
>    including the attributes and content of that element (whether it be
>    text or other child elements), and ending with the closing bracket
>    for the end tag for that element.  The MIME type in the request MUST
>    be "application/xcap-el+xml", defined in Section 14.2.1.  If the node
>    selector, when evaluated against the current document, results in a
>    no-match, the server performs a creation operation.  If the node
>    selector, when evaluated against the current document, is a match for
>    an element in the current document, the server replaces it with the
>    content of the PUT request.  This replacement is complete; that is,
>    the old element (including its attributes and content) are removed,
>    and the new one, including its attributes and content, is put in its
>    place.
> 
> Does that sound right?
> 
> -- 
> Dean
> 
> 
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Fri Aug 26 08:33:42 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E8dOw-0007PJ-5x; Fri, 26 Aug 2005 08:33:42 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dOu-0007PE-6m
	for simple@megatron.ietf.org; Fri, 26 Aug 2005 08:33:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15404
	for <simple@ietf.org>; Fri, 26 Aug 2005 08:33:38 -0400 (EDT)
Received: from mgw-x1.nokia.com ([131.228.20.21])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8dPa-0004eD-3B
	for simple@ietf.org; Fri, 26 Aug 2005 08:34:25 -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
	j7QCXXF05466; Fri, 26 Aug 2005 15:33:33 +0300 (EET DST)
X-Scanned: Fri, 26 Aug 2005 15:33:13 +0300 Nokia Message Protector V1.3.35
	2005042208 - RELEASE
Received: (from root@localhost)
	by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j7QCXDfQ010407;
	Fri, 26 Aug 2005 15:33:13 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96)
	by esdks001.ntc.nokia.com 00rCgGv6; Fri, 26 Aug 2005 15:33:08 EEST
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13])
	by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id
	j7QCX7K22593; Fri, 26 Aug 2005 15:33:07 +0300 (EET DST)
Received: from [172.21.34.145] (hed034-145.research.nokia.com [172.21.34.145])
	by kusti.research.nokia.com (Postfix) with ESMTP
	id 2AE0493B6A; Fri, 26 Aug 2005 15:33:07 +0300 (EEST)
Message-ID: <430F0C03.2050605@nokia.com>
Date: Fri, 26 Aug 2005 15:33:07 +0300
From: Jari Urpalainen <jari.urpalainen@nokia.com>
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "ext Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by usingonly
	the XML fragment body.
References: <1AF90E65795A3D45AA116B9264B4DAAF029D875A@SELDMSX01.corpusers.net>
In-Reply-To: <1AF90E65795A3D45AA116B9264B4DAAF029D875A@SELDMSX01.corpusers.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Content-Transfer-Encoding: 7bit
Cc: "Gulin, Jens" <Jens.Gulin@sonyericsson.com>,
	Kelvin Porter <kelvin_r_porter@yahoo.com>, Simple WG <simple@ietf.org>,
	Dean Willis <dean.willis@softarmor.com>
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

ext Hyttfors, Per wrote:

>I hope that many with me agree that the best alternative is to solve this XCAP issue within the IETF.
>
>As I wrote in my response to Rosenberg, W3C has dealt with this problem years ago and has come up with both XML fragment context specification and canonicalization. They are working standards and there has to be several implementations already using this.
>
>But you are right, as your suggestions on workarounds show, this problem could probably be avoided by OMA PoC with some changes in the current OMA specifications, some more dramatic than others. I would personally like to see that a client is able to fetch a part of a document without having to do multiple requests, or having to maintain one more document, with all the problems this could cause. The suggested solution A and B allows for this, but there is a trade-off as it limits or complicates extensibility in future versions and the possibility to use proprietary extensions etc.
>
>/Per 
>  
>
Per, if I have understood correctly, you might be satisfied with Accept: 
application/xcap-el-efb+xml where the body would be expressed with the 
exclusive xml canonical format ? If so, why don't you (or someone) write 
an XCAP extension i-d about it ? I.e. imo this looks more like a new 
feature than a bug. Secondly, besides some added complexity there's also 
added verbosity involved with this approach. So imo both models could be 
allowed.
br,
Jari

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Sun Aug 28 19:51:12 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E9Wvf-0006pF-V6; Sun, 28 Aug 2005 19:51:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E9Wve-0006pA-Gy
	for simple@megatron.ietf.org; Sun, 28 Aug 2005 19:51:10 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18283
	for <simple@ietf.org>; Sun, 28 Aug 2005 19:51:09 -0400 (EDT)
Received: from jalapeno.cc.columbia.edu ([128.59.29.5] ident=cu41754)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9Wws-0002MV-1l
	for simple@ietf.org; Sun, 28 Aug 2005 19:52:27 -0400
Received: from [192.168.0.31] (pool-141-153-174-94.mad.east.verizon.net
	[141.153.174.94]) (user=hgs10 mech=PLAIN bits=0)
	by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id
	j7SNp5nF015350
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Sun, 28 Aug 2005 19:51:05 -0400 (EDT)
Message-ID: <43124DEF.6050003@cs.columbia.edu>
Date: Sun, 28 Aug 2005 19:51:11 -0400
From: Henning Schulzrinne <hgs@cs.columbia.edu>
Organization: Columbia University
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@cisco.com>
Subject: Re: [Simple] updated data-model I-D
References: <430AB4E0.2000506@cisco.com>
In-Reply-To: <430AB4E0.2000506@cisco.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: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

Jonathan Rosenberg wrote:

> Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
> encapsulation out of data model spec. Argued that this makes for a lot 
> of documents to read in order to get an implementation. General 
> consensus on proposal.
> 
> I actually recall that Henning argued against this, and the conclusion 
> was to just put words in. So I did. See below for the specific text.

Indeed - the wording of the minutes makes little sense, as the second 
sentence directly contradicts the first one.

I think the full discussion went something like this:

- We need to tell people how to use PIDF-LO within the data model, as 
the current PIDF-LO draft is silent on this topic and only defines its 
position by example - which unfortunately puts it exactly in the wrong 
place by the logic of the data model. (PIDF-LO predates the data model 
work although it hasn't emerged from AUTH48, apparently.)

- We could write another draft that just addressed this question.

- But that would add yet another document that an implementor has to 
find and read [while the data model document currently serves as a good 
first document and substitutes for an architecture document].


> * added text on incorporating <geopriv> objects. The text reads:
> 
> <t>
> <xref target="I-D.ietf-geopriv-pidf-lo"/> defines the &lt;geopriv&gt;
> XML element for conveying location information, and indicates that it
> is carried as a child of the &lt;tuple&gt; element in a PIDF
> document. <xref target="I-D.ietf-geopriv-pidf-lo"/> was developed
> prior to this specification, and unfortunately, its recommendation to
> include location objects underneath &lt;tuple&gt; runs contrary to the
> recommendations here. As such, implementations based on this
> specification SHOULD include &lt;geopriv&gt; location objects
> as part of person and device components of the document, but SHOULD be
> prepared to receive presence documents with that object as a child to
> &lt;tuple&gt;.
> </t>
> 


_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple



From simple-bounces@ietf.org Mon Aug 29 06:19:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1E9gjS-0006ue-Qo; Mon, 29 Aug 2005 06:19:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gjR-0006uZ-Gp
	for simple@megatron.ietf.org; Mon, 29 Aug 2005 06:19:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28414
	for <simple@ietf.org>; Mon, 29 Aug 2005 06:19:11 -0400 (EDT)
Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9gkj-0002Fh-RW
	for simple@ietf.org; Mon, 29 Aug 2005 06:20:35 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILZ007QFBNU75@szxga02-in.huawei.com> for
	simple@ietf.org; Mon, 29 Aug 2005 18:26:18 +0800 (CST)
Received: from szxml01-in ([172.24.1.3])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0ILZ008CABNUVV@szxga02-in.huawei.com> for
	simple@ietf.org; Mon, 29 Aug 2005 18:26:18 +0800 (CST)
Received: from w39649a ([10.76.176.178])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0ILZ0063WBT1IT@szxml01-in.huawei.com> for
	simple@ietf.org; Mon, 29 Aug 2005 18:29:25 +0800 (CST)
Date: Mon, 29 Aug 2005 18:19:41 +0800
From: Smile Wang <wangsmile@huawei.com>
To: "'SIMPLE'" <simple@ietf.org>
Message-id: <000001c5ac83$2b22ee90$b2b04c0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.4 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Subject: [Simple] A question for draft-ietf-simple-filter-format-05
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1458850076=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1458850076==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_+F55IyGEO2+c5SCwHrzAog)"

This is a multi-part message in MIME format.

--Boundary_(ID_+F55IyGEO2+c5SCwHrzAog)
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7BIT

Hi,All:

         I'm doubt for the description of draft-ietf-simple-filter-format-05
in the 3.4  The <filter> Element

     

 

         --When a filter is disabled by setting the 'enabled'

   attribute to "false", the <what> and <trigger> elements MAY be

   omitted.  Similarily, when a filter is re-enabled by setting the

   'enabled' attribute to "true", the <what> and <trigger> elements MAY

   be omitted.--

 

         Set  the 'enabled' "true" or "false",the result is same.There maybe
some

   problem?

 

Smile

 


--Boundary_(ID_+F55IyGEO2+c5SCwHrzAog)
Content-type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	text-align:justify;
	text-justify:inter-ideograph;
	font-size:10.5pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:windowtext;}
 /* Page Definitions */
 @page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=ZH-CN link=blue vlink=purple style='text-justify-trim:punctuation'>

<div class=Section1>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>Hi,All:</span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I&#8217;m
doubt for the description of draft-ietf-simple-filter-format-05 in the </span></font><b><font
size=2 color="#000032" face="Courier New"><span lang=EN-US style='font-size:
10.0pt;font-family:"Courier New";color:#000032;font-weight:bold'>3.4&nbsp; The
&lt;filter&gt; Element</span></font></b></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal align=left style='text-align:left;text-autospace:none'><font
size=1 face=Arial><span lang=EN-US style='font-size:9.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; --</span></font><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>When a filter is disabled by setting the
'enabled'</span></font></p>

<p class=MsoNormal align=left style='text-align:left;text-autospace:none'><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>&nbsp;&nbsp; attribute to
&quot;false&quot;, the &lt;what&gt; and &lt;trigger&gt; elements MAY be</span></font></p>

<p class=MsoNormal align=left style='text-align:left;text-autospace:none'><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>&nbsp;&nbsp; omitted.&nbsp; Similarily,
when a filter is re-enabled by setting the</span></font></p>

<p class=MsoNormal align=left style='text-align:left;text-autospace:none'><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>&nbsp;&nbsp; 'enabled' attribute to
&quot;true&quot;, the &lt;what&gt; and &lt;trigger&gt; elements MAY</span></font></p>

<p class=MsoNormal align=left style='text-align:left;text-autospace:none'><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>&nbsp;&nbsp; be omitted.--</span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; S</span></font><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>et</span></font><font size=1 face=Arial><span
lang=EN-US style='font-size:9.0pt;font-family:Arial'> &nbsp;the </span></font><font
size=2 color=black face="Courier New"><span lang=EN-US style='font-size:10.0pt;
font-family:"Courier New";color:black'>'enabled' &#8220;true&#8221; or &#8220;false&#8221;,the
result is same.There maybe some</span></font></p>

<p class=MsoNormal><font size=2 color=black face="Courier New"><span
lang=EN-US style='font-size:10.0pt;font-family:"Courier New";color:black'>&nbsp;&nbsp;
problem?</span></font></p>

<p class=MsoNormal><font size=1 face=Arial><span lang=EN-US style='font-size:
9.0pt;font-family:Arial'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US
style='font-size:10.0pt'>Smile</span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span lang=EN-US>&nbsp;</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_+F55IyGEO2+c5SCwHrzAog)--


--===============1458850076==
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

--===============1458850076==--




From simple-bounces@ietf.org Tue Aug 30 10:57:06 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EA7Xu-0002sO-83; Tue, 30 Aug 2005 10:57:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EA7Xs-0002sF-44
	for simple@megatron.ietf.org; Tue, 30 Aug 2005 10:57:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17347
	for <simple@ietf.org>; Tue, 30 Aug 2005 10:57:01 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA7ZO-0003PS-8k
	for simple@ietf.org; Tue, 30 Aug 2005 10:58:41 -0400
Received: by zproxy.gmail.com with SMTP id 12so765744nzp
	for <simple@ietf.org>; Tue, 30 Aug 2005 07:56:52 -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=Nnnu9dzkFmJtXRUaukBBmalYQ2A3/eTeMDiMUoUnCYxt4c2kAZG1WrNG6UjMp+rTjYxEdHaH0CPsQkKEp6f425M/wSJmX6Ymav1iLWnPLjTSCC1gsSHAQGe/wLDia6mB281SWsdTkkL/z6r2W5HaunqhvfiwvbWgLWWEP6kHOjo=
Received: by 10.37.12.70 with SMTP id p70mr529256nzi;
	Tue, 30 Aug 2005 07:56:51 -0700 (PDT)
Received: by 10.36.59.3 with HTTP; Tue, 30 Aug 2005 07:56:51 -0700 (PDT)
Message-ID: <29ac328c05083007565bf8baa9@mail.gmail.com>
Date: Tue, 30 Aug 2005 22:56:51 +0800
From: Cheney Stallman <zodist@gmail.com>
To: simple@ietf.org
Mime-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [Simple] Does IMS must using IPv6?
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0589196152=="
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

--===============0589196152==
Content-Type: multipart/alternative; 
	boundary="----=_Part_3238_17281191.1125413811543"

------=_Part_3238_17281191.1125413811543
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

This problem puzzled me, Does IMS must using IPv6, or paritial using IPv6,
or some other restriction?
 Thanks in advanced.

------=_Part_3238_17281191.1125413811543
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

<div>This&nbsp;problem puzzled me,&nbsp;Does IMS must using IPv6, or pariti=
al using IPv6,</div>
<div>or some other restriction?<br>&nbsp;</div>
<div>Thanks in advanced.<br>&nbsp;</div>

------=_Part_3238_17281191.1125413811543--


--===============0589196152==
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

--===============0589196152==--




From simple-bounces@ietf.org Tue Aug 30 11:31:21 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EA853-0002ck-Pf; Tue, 30 Aug 2005 11:31:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EA852-0002cf-AU
	for simple@megatron.ietf.org; Tue, 30 Aug 2005 11:31:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18885
	for <simple@ietf.org>; Tue, 30 Aug 2005 11:31:17 -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.43)
	id 1EA86a-0004G8-J3
	for simple@ietf.org; Tue, 30 Aug 2005 11:32:57 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-2.cisco.com with ESMTP; 30 Aug 2005 08:31:09 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com
	[64.102.31.102])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7UFUZQm012041;
	Tue, 30 Aug 2005 08:31:07 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by
	xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Tue, 30 Aug 2005 11:31:05 -0400
Received: from [192.168.1.105] ([10.86.242.104]) by xfe-rtp-201.amer.cisco.com
	with Microsoft SMTPSVC(6.0.3790.211); 
	Tue, 30 Aug 2005 11:31:05 -0400
Message-ID: <43147BB9.5070507@cisco.com>
Date: Tue, 30 Aug 2005 11:31:05 -0400
From: Jonathan Rosenberg <jdrosen@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.7.8) Gecko/20050511
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Henning Schulzrinne <hgs@cs.columbia.edu>
Subject: Re: [Simple] updated data-model I-D
References: <430AB4E0.2000506@cisco.com> <43124DEF.6050003@cs.columbia.edu>
In-Reply-To: <43124DEF.6050003@cs.columbia.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Aug 2005 15:31:05.0438 (UTC)
	FILETIME=[D61597E0:01C5AD77]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a
Content-Transfer-Encoding: 7bit
Cc: Simple WG <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
	<simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>,
	<mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org

So, given that we are agreed on adding some text, does the text below 
work for you?

-Jonathan R.

Henning Schulzrinne wrote:

> Jonathan Rosenberg wrote:
> 
>> Issue 4: PIDF-LO integration: Proposal to keep definition of PIDF-LO 
>> encapsulation out of data model spec. Argued that this makes for a lot 
>> of documents to read in order to get an implementation. General 
>> consensus on proposal.
>>
>> I actually recall that Henning argued against this, and the conclusion 
>> was to just put words in. So I did. See below for the specific text.
> 
> 
> Indeed - the wording of the minutes makes little sense, as the second 
> sentence directly contradicts the first one.
> 
> I think the full discussion went something like this:
> 
> - We need to tell people how to use PIDF-LO within the data model, as 
> the current PIDF-LO draft is silent on this topic and only defines its 
> position by example - which unfortunately puts it exactly in the wrong 
> place by the logic of the data model. (PIDF-LO predates the data model 
> work although it hasn't emerged from AUTH48, apparently.)
> 
> - We could write another draft that just addressed this question.
> 
> - But that would add yet another document that an implementor has to 
> find and read [while the data model document currently serves as a good 
> first document and substitutes for an architecture document].
> 
> 
>> * added text on incorporating <geopriv> objects. The text reads:
>>
>> <t>
>> <xref target="I-D.ietf-geopriv-pidf-lo"/> defines the &lt;geopriv&gt;
>> XML element for conveying location information, and indicates that it
>> is carried as a child of the &lt;tuple&gt; element in a PIDF
>> document. <xref target="I-D.ietf-geopriv-pidf-lo"/> was developed
>> prior to this specification, and unfortunately, its recommendation to
>> include location objects underneath &lt;tuple&gt; runs contrary to the
>> recommendations here. As such, implementations based on this
>> specification SHOULD include &lt;geopriv&gt; location objects
>> as part of person and device components of the document, but SHOULD be
>> prepared to receive presence documents with that object as a child to
>> &lt;tuple&gt;.
>> </t>
>>
> 

-- 
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